क्लाइंट-सर्वर डेटाबेस को सिंक्रनाइज़ करना

Question 1

मैं क्लाइंट अनुप्रयोगों के साथ केंद्रीय सर्वर पर डेटा को सिंक्रनाइज़ करने के लिए कुछ सामान्य रणनीतियों की तलाश कर रहा हूं जो हमेशा ऑनलाइन नहीं होती हैं।

मेरे विशेष मामले में, मेरे पास एक sqlite डेटाबेस के साथ एक एंड्रॉइड फोन एप्लिकेशन और एक MySQL डेटाबेस के साथ PHP वेब एप्लिकेशन है।

उपयोगकर्ता फोन एप्लिकेशन और वेब एप्लिकेशन पर जानकारी जोड़ और संपादित कर सकेंगे। मुझे यह सुनिश्चित करने की ज़रूरत है कि एक जगह किए गए परिवर्तन तब भी हर जगह परिलक्षित होते हैं, जब फोन सर्वर से तुरंत संवाद करने में सक्षम नहीं होता है।

मुझे इस बात से कोई सरोकार नहीं है कि फोन से डेटा को सर्वर में कैसे ट्रांसफर किया जाए या इसके विपरीत। मैं अपनी विशेष तकनीकों का उल्लेख केवल इसलिए कर रहा हूं क्योंकि मैं उदाहरण के लिए, MySQL के लिए उपलब्ध प्रतिकृति सुविधाओं का उपयोग नहीं कर सकता।

मुझे पता है कि क्लाइंट-सर्वर डेटा सिंक्रोनाइज़ेशन समस्या एक लंबे, लंबे समय के लिए आसपास रही है और समस्या से निपटने के लिए पैटर्न के बारे में जानकारी - लेख, किताबें, सलाह, आदि पसंद करेंगे। मैं ताकत, कमजोरियों और व्यापार-नापसंद की तुलना करने के लिए सिंक्रनाइज़ेशन से निपटने के लिए सामान्य रणनीतियों के बारे में जानना चाहता हूं।

Question 2

पहली चीज़ जो आपको तय करनी है, वह एक सामान्य नीति है जिसके बारे में परस्पर विरोधी परिवर्तनों के मामले में किस पक्ष को "आधिकारिक" माना जाता है।

Ie: मान लीजिए कि रिकॉर्ड # 125 को सर्वर पर 5 जनवरी को रात 10 बजे और उसी रिकॉर्ड को एक फोन पर बदल दिया जाता है (चलो इसे क्लाइंट ए कहते हैं) 5 जनवरी को 11 बजे। लास्ट सेंचुरी 3 जनवरी को थी। फिर उपयोगकर्ता फिर से कहता है, कहते हैं, 8 जनवरी।

यह समझने की आवश्यकता है कि किस चीज़ को बदलना आसान है, इस अर्थ में कि क्लाइंट और सर्वर दोनों को अंतिम सिंक्रोनाइज़ की तारीख पता है, इसलिए किसी भी चीज़ को बनाया या अपडेट किया गया है (इस बारे में अधिक जानकारी के लिए नीचे देखें) क्योंकि आखिरी सिंक को समेटने की आवश्यकता है।

तो, मान लीजिए कि केवल परिवर्तित रिकॉर्ड # 125 है। आप या तो यह तय करते हैं कि दो में से एक स्वचालित रूप से "जीतता है" और दूसरे को अधिलेखित करता है, या आपको एक सामंजस्यपूर्ण चरण का समर्थन करने की आवश्यकता है जहां उपयोगकर्ता यह तय कर सकता है कि कौन सा संस्करण (सर्वर या क्लाइंट) सही है, दूसरे को अधिलेखित करना।

यह निर्णय बेहद महत्वपूर्ण है और आपको ग्राहकों की "भूमिका" का वजन करना चाहिए। विशेष रूप से यदि क्लाइंट और सर्वर के बीच न केवल एक संभावित संघर्ष है, लेकिन यदि अलग-अलग क्लाइंट एक ही रिकॉर्ड को बदल सकते हैं।

[यह मानते हुए कि # 125 को एक दूसरे क्लाइंट (क्लाइंट B) द्वारा संशोधित किया जा सकता है, एक मौका है कि क्लाइंट B, जो अभी तक सिंक नहीं किया गया है, एक ही रिकॉर्ड का एक और संस्करण प्रदान करेगा, जो पिछले संघर्ष रिज़ॉल्यूशन को मूट बनाता है]

ऊपर " बनाया या अपडेट किया गया " बिंदु के बारे में ... आप किसी रिकॉर्ड को ठीक से कैसे पहचान सकते हैं यदि यह किसी एक क्लाइंट पर उत्पन्न हुआ है (यह मानते हुए कि यह आपकी समस्या डोमेन में है)? मान लीजिए कि आपका ऐप व्यावसायिक संपर्कों की सूची का प्रबंधन करता है। यदि क्लाइंट ए कहता है कि आपको एक नए बनाए गए जॉन स्मिथ को जोड़ना है, और क्लाइंट के पास क्लाइंट डी द्वारा कल बनाया गया जॉन स्मिथ है ... क्या आप दो रिकॉर्ड बनाते हैं क्योंकि आप निश्चित नहीं हो सकते कि वे अलग-अलग व्यक्ति नहीं हैं? क्या आप उपयोगकर्ता से इस संघर्ष को भी समेटने के लिए कहेंगे?

क्या ग्राहकों के पास डेटा के सबसेट का "स्वामित्व" है? I यदि क्लाइंट B क्षेत्र # 5 के लिए डेटा पर "प्राधिकरण" होने के लिए सेटअप है, तो क्या क्लाइंट # क्षेत्र # 5 के लिए रिकॉर्ड संशोधित / बना सकता है या नहीं? (यह कुछ संघर्ष समाधान को आसान बना देगा, लेकिन आपकी स्थिति के लिए प्रतिकूल साबित हो सकता है)।

यह योग करने के लिए मुख्य समस्याएं हैं:

"पहचान" को कैसे परिभाषित किया जाए, यह देखते हुए कि अलग किए गए क्लाइंट ने नया रिकॉर्ड बनाने से पहले सर्वर तक नहीं पहुंचाया होगा।
पिछली स्थिति, कोई फर्क नहीं पड़ता कि समाधान कितना परिष्कृत है, जिसके परिणामस्वरूप डेटा दोहराव हो सकता है, इसलिए आपको समय-समय पर इनका समाधान करना चाहिए और ग्राहकों को कैसे सूचित करना चाहिए कि उन्हें "रिकॉर्ड # 675" के रूप में क्या माना जाता है, वास्तव में / सुपारे के साथ विलय कर दिया गया है रिकॉर्ड # 543
तय करें कि यदि संघर्षों को fiat द्वारा हल किया जाएगा (उदाहरण के लिए "सर्वर संस्करण हमेशा क्लाइंट को ट्रम्प करता है यदि पिछले सिंक के बाद पूर्व को अपडेट किया गया है") या मैनुअल हस्तक्षेप से
फिएट के मामले में , खासकर यदि आप तय करते हैं कि ग्राहक पूर्वता लेता है, तो आपको इस बात का भी ध्यान रखना होगा कि अन्य लोगों के साथ कैसे व्यवहार किया जाए, न कि अभी तक सिंक किए गए ग्राहकों के लिए जिनमें कुछ और बदलाव आ सकते हैं।
पिछले आइटम आपके डेटा की बारीकियों को ध्यान में नहीं रखते हैं (क्रम में चीजों को सरल बनाने के लिए)। यह कहने के लिए पर्याप्त है कि "रिकॉर्ड" स्तर पर तर्क करने के बजाय, जैसा कि मेरे उदाहरण में, आपको फ़ील्ड स्तर पर रिकॉर्ड परिवर्तन करने के लिए अधिक उपयुक्त मिल सकता है, बजाय। या अपने समुच्चय को "मेटा रिकॉर्ड" के एक प्रकार के रूप में मानते हुए एक समय में रिकॉर्ड के एक सेट (जैसे व्यक्ति रिकॉर्ड + पता रिकॉर्ड + संपर्क रिकॉर्ड) पर काम करना।

ग्रंथ सूची:

इस पर अधिक, निश्चित रूप से, विकिपीडिया पर ।
Vdirsyncer के लेखक द्वारा एक सरल तुल्यकालन एल्गोरिथ्म
डेटा सिंक पर ओबीजेसी लेख
SyncML®: अपने मोबाइल डेटा को सिंक्रनाइज़ करना और प्रबंधित करना (ओ'रेली सफारी पर बुक करें)
Con ﬂ ict-free प्रतिकृति डेटा प्रकार
आशावादी प्रतिकृति YASUSHI SAITO (HP Laboratories) और MARC SHAPIRO (Microsoft Research Ltd.) - ACM कम्प्यूटिंग सर्वे, वॉल्यूम। वी, नंबर एन, 3 2005।
अलेक्जेंडर ट्रुड, जुएरगेन नागलर-इहलीन, फ्रैंक कर्गल और माइकल वेबर। 2008. पुनरावर्तक SyncML के माध्यम से चक्रीय डेटा तुल्यकालन। मोबाइल डेटा प्रबंधन (MDM '08) पर नौवें अंतर्राष्ट्रीय सम्मेलन की कार्यवाही में। आईईईई कंप्यूटर सोसायटी, वाशिंगटन, डीसी, यूएसए, 165-172। DOI = 10.1109 / MDM.2008.10 http://dx.doi.org/10.1109/MDM.2008.10
Lam, F., Lam, N., और Wong, R. 2002. मोबाइल XML डेटा के लिए कुशल सिंक्रनाइज़ेशन। सूचना और ज्ञान प्रबंधन पर ग्यारहवें अंतर्राष्ट्रीय सम्मेलन की कार्यवाही में (मैकलीन, वर्जीनिया, संयुक्त राज्य अमेरिका, 04 नवंबर - 09, 2002)। CIKM '02। एसीएम, न्यूयॉर्क, एनवाई, 153-160। डीओआई = http://doi.acm.org/10.1145/584792.584820
कुन्हा, पीआर और माईबूम, टीएस 1981। संसाधन और संतुलन; सार डेटा प्रकार + तुल्यकालन - संदेश उन्मुख प्रोग्रामिंग के लिए एक पद्धति -। सॉफ्टवेयर इंजीनियरिंग पर 5 वें अंतरराष्ट्रीय सम्मेलन की कार्यवाही में (सैन डिएगो, कैलिफोर्निया, संयुक्त राज्य अमेरिका, 09 मार्च - 12, 1981)। सॉफ्टवेयर इंजीनियरिंग पर अंतर्राष्ट्रीय सम्मेलन। आईईईई प्रेस, पिसकटावे, एनजे, 263-272।

(अंतिम तीन एसीएम डिजिटल लाइब्रेरी से हैं, कोई भी विचार नहीं है कि क्या आप सदस्य हैं या यदि आप अन्य चैनलों के माध्यम से प्राप्त कर सकते हैं)।

से Dr.Dobbs साइट:

बिल वैगनर 19 मई, 2004 तक एसक्यूएल सर्वर सीई और एसक्यूएल आरडीए के साथ ऐप बनाना

Arxiv.org से:

एक संघर्ष-मुक्त प्रतिकृति JSON डेटाटाइप - कागज एक JSON CRDT कार्यान्वयन का वर्णन करता है (संघर्ष-मुक्त प्रतिकृति डेटाैटिप्स - CRDTs - डेटा संरचनाओं का एक परिवार है जो समवर्ती संशोधन का समर्थन करता है और इस तरह के समवर्ती अपडेट की गारंटी देता है)।

Question 3

मैं आपको सलाह दूंगा कि आपके पास हर टेबल में टाइमस्टैम्प कॉलम हो और हर बार जब आप डालें या अपडेट करें, प्रत्येक प्रभावित पंक्ति के टाइमस्टैम्प मान को अपडेट करें। फिर, यदि आप गंतव्य डेटाबेस में आपके पास मौजूद टाइमस्टैम्प से नए हैं, तो आप सभी तालिकाओं की पुनरावृति करते हैं। यदि यह नया है, तो जाँच करें कि आपको सम्मिलित करना है या अद्यतन करना है।

अवलोकन 1: भौतिक डिलीट के बारे में पता होना चाहिए क्योंकि पंक्तियाँ स्रोत db से हटा दी जाती हैं और आपको सर्वर db पर भी ऐसा ही करना होता है। आप टाइमस्टैम्प के साथ तालिका में हर डिलीट को भौतिक रूप से हटाने या लॉग करने से इसे हल कर सकते हैं। कुछ इस तरह: DeletedRows = (id, table_name, pk_column, pk_column_value, timestamp)तो, आपको DeletedRows तालिका की सभी नई पंक्तियों को पढ़ना होगा और तालिका_नाम, pk_column और pk_column_value का उपयोग करते हुए सर्वर पर एक डिलीट को निष्पादित करना होगा।

अवलोकन 2: एक तालिका में डेटा सम्मिलित करने के बाद से FK के बारे में पता होना चाहिए कि किसी अन्य तालिका से संबंधित असफल हो सकता है। डेटा सिंक्रनाइज़ेशन से पहले आपको हर एफके को निष्क्रिय करना चाहिए।

Question 4

अगर कोई भी समान डिज़ाइन समस्या से निपट रहा है और मुझे कई Android उपकरणों में परिवर्तनों को सिंक्रनाइज़ करने की आवश्यकता है, जो मैं Google क्लाउड मैसेजिंग को Android (GCM) के लिए जाँचने की सलाह देता हूँ ।

मैं एक समाधान पर काम कर रहा हूं, जहां एक ग्राहक पर किए गए बदलावों को अन्य ग्राहकों के लिए प्रचारित किया जाना चाहिए। और मैंने अभी अवधारणा कार्यान्वयन (सर्वर और क्लाइंट) का प्रमाण लागू किया है और यह एक आकर्षण की तरह काम करता है।

मूल रूप से, प्रत्येक क्लाइंट सर्वर को डेल्टा परिवर्तन भेजता है। ईजी रिसोर्स आईडी ABCD1234 मान 100 से बदलकर 99 हो गया है।

सर्वर अपने डेटाबेस के खिलाफ इन डेल्टा परिवर्तनों को मान्य करता है और या तो परिवर्तन को मंजूरी देता है (क्लाइंट सिंक में है) और अपने डेटाबेस को अपडेट करता है या परिवर्तन को अस्वीकार करता है (क्लाइंट सिंक से बाहर है)।

यदि परिवर्तन सर्वर, सर्वर द्वारा अनुमोदित है, तो GCM के माध्यम से अन्य क्लाइंट (डेल्टा परिवर्तन को भेजने वाले को छोड़कर) को सूचित करता है और उसी डेल्टा परिवर्तन को ले जाने वाला मल्टीकास्ट संदेश भेजता है। ग्राहक इस संदेश को संसाधित करते हैं और अपने डेटाबेस को अपडेट करते हैं।

कूल बात यह है कि इन परिवर्तनों को लगभग तुरंत प्रचारित किया जाता है !!! यदि वे उपकरण ऑनलाइन हैं। और मुझे उन ग्राहकों पर कोई मतदान तंत्र लागू करने की आवश्यकता नहीं है।

ध्यान रखें कि यदि कोई उपकरण बहुत लंबा ऑफ़लाइन है और डिलीवरी के लिए GCM कतार में 100 से अधिक संदेश प्रतीक्षा कर रहे हैं, तो GCM उन संदेशों को छोड़ देगा और एक विशेष संदेश भेजेगा जब उपकरण ऑनलाइन वापस हो जाएंगे। उस स्थिति में क्लाइंट को सर्वर के साथ पूर्ण सिंक करना होगा।

CGM क्लाइंट कार्यान्वयन के साथ आरंभ करने के लिए इस ट्यूटोरियल को भी देखें ।

Question 5

यह उत्तर डेवलपर्स जो Xamarin ढांचे का उपयोग कर रहे हैं ( /programming/40156342/sync-online-offline-data देखें )

Xamarin ढांचे के साथ इसे प्राप्त करने का एक बहुत ही सरल तरीका है Azure के ऑफ़लाइन डेटा सिंक का उपयोग करना क्योंकि यह सर्वर से डेटा को मांग पर धक्का और खींचने की अनुमति देता है। पढ़ें ऑपरेशन स्थानीय स्तर पर किए जाते हैं, और लिखने के संचालन को मांग पर धकेल दिया जाता है; यदि नेटवर्क कनेक्शन टूट जाता है, तो लेखन कार्यों को तब तक कतारबद्ध किया जाता है जब तक कनेक्शन बहाल नहीं हो जाता है, तब निष्पादित किया जाता है।

कार्यान्वयन सरल है:

1) azure पोर्टल में एक मोबाइल ऐप बनाएं (आप इसे यहां मुफ्त में आज़मा सकते हैं https://tryappservice.azure.com/ )

2) अपने क्लाइंट को मोबाइल ऐप से कनेक्ट करें। https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-xamarin-forms-get-started/

3) अपने स्थानीय रिपॉजिटरी को सेटअप करने के लिए कोड:

const string path = "localrepository.db";

//Create our azure mobile app client
this.MobileService = new MobileServiceClient("the api address as setup on Mobile app services in azure");

//setup our local sqlite store and initialize a table
var repository = new MobileServiceSQLiteStore(path);

// initialize a Foo table
store.DefineTable<Foo>();

// init repository synchronisation
await this.MobileService.SyncContext.InitializeAsync(repository);
var fooTable = this.MobileService.GetSyncTable<Foo>();

4) फिर अपने डेटा को पुश करने और खींचने के लिए सुनिश्चित करें कि हमारे पास नवीनतम परिवर्तन हैं:

await this.MobileService.SyncContext.PushAsync();
await this.saleItemsTable.PullAsync("allFoos", fooTable.CreateQuery());

https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-xamarin-forms-get-started-offline-data/

Question 6

मेरा सुझाव है कि आप भी Symmetricds पर एक नज़र डालें । यह एंड्रॉइड सिस्टम के लिए उपलब्ध SQLite प्रतिकृति लाइब्रेरी है। आप इसका उपयोग अपने क्लाइंट और सर्वर डेटाबेस को सिंक्रनाइज़ करने के लिए कर सकते हैं, मैं प्रत्येक क्लाइंट के लिए सर्वर पर अलग-अलग डेटाबेस रखने का भी सुझाव देता हूं। एक mysql डेटाबेस में सभी उपयोगकर्ताओं के डेटा को रखने की कोशिश करना हमेशा सबसे अच्छा विचार नहीं होता है। विशेष रूप से अगर उपयोगकर्ता डेटा तेजी से बढ़ने वाला है।

Question 7

आओ हम इसे CUDR सिंक समस्या कहते हैं (मुझे CRUD पसंद नहीं है - क्योंकि Create / Update / Delete लिखा जाता है और इसे एक साथ जोड़ा जाना चाहिए)

समस्या को राइट-ऑफली-फर्स्ट या राइट-ऑनलाइन-प्रथम परिप्रेक्ष्य से भी देखा जा सकता है। राइट-ऑफलाइन-अप्रोच में अद्वितीय पहचानकर्ता संघर्ष के साथ एक समस्या है, और एक ही लेनदेन के लिए कई नेटवर्क कॉल बढ़ते जोखिम (या लागत) ...

मुझे व्यक्तिगत रूप से लिखना-ऑनलाइन-पहला दृष्टिकोण प्रबंधित करना आसान है (इसलिए यह सत्य का एकल स्रोत होगा - जहां से बाकी सब सिंक किया गया है)। लिखने-ऑनलाइन-दृष्टिकोण के लिए उपयोगकर्ताओं को पहले ऑफ़लाइन लिखने की अनुमति नहीं देनी होगी - वे ऑनलाइन प्रतिक्रिया लिखकर ओके प्रतिक्रिया फॉर्म प्राप्त करके ऑफ़लाइन लिखेंगे।

वह पहले ऑफ़लाइन पढ़ सकता है और जैसे ही नेटवर्क उपलब्ध होता है ऑनलाइन से डेटा प्राप्त करता है और स्थानीय डेटाबेस को अपडेट करता है और फिर ui को अपडेट करता है ...।

विशिष्ट पहचानकर्ता संघर्ष से बचने का एक तरीका यह होगा कि आप अद्वितीय उपयोगकर्ता आईडी + टेबल नाम या टेबल आईडी + पंक्ति आईडी (साइक्लाइट द्वारा निर्मित) के संयोजन का उपयोग करें ... और फिर इसके साथ सिंक किए गए बूलियन ध्वज स्तंभ का उपयोग करें .. लेकिन फिर भी यूनिक आईडी प्राप्त करने के लिए पहले ऑनलाइन पंजीकरण करना पड़ता है, जिस पर अन्य सभी आईडी जेनरेट की जाएंगी ... यहां मुद्दा यह भी होगा कि क्या घड़ियों को सिंक नहीं किया गया है - जो किसी ने ऊपर उल्लेख किया है ...