2013-01-18 41 views
13

यह एक वैचारिक प्रश्न है जो किसी भी विशिष्ट तकनीकों के लिए जरूरी नहीं है। आइए कहें कि आपको सर्वर पर कुछ डेटाबेस मिला है, कुछ आरईएसटी/जेएसओएन एपीआई उस डेटाबेस में सामग्री तक पहुंचने के लिए और कुछ मोबाइल क्लाइंट एपीआई के माध्यम से डेटा पुनर्प्राप्त कर रहा है।सर्वर से क्लाइंट तक आंशिक डेटाबेस मॉडल सिंक्रनाइज़ करना

क्लाइंट पर कुछ कैशिंग तंत्र होना अच्छा होगा और जब तक क्लाइंट केवल पढ़ रहा हो तब तक डेटा तक ऑफलाइन पहुंच को सक्षम करने में सक्षम होना चाहिए (मेरे मामले में ऑफ़लाइन क्लाइंट तक पहुंच पहुंच को अस्वीकार करना ठीक है हो सकता है कि उन सभी बुरा संघर्षों का प्रबंधन करने से बचें)।

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

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

अब एक कार्यान्वयन के नजरिए से ... एक हाथ पर यह जोड़ी सर्वर क्लाइंट डेटाबेस वे भिन्न विक्रेताओं से हो सकता है के रूप में करने के लिए सीधे डेटाबेस के लिए एक बुरा विचार की तरह लगता है। मुझे लगता है कि कम से कम डेटाबेस कार्यान्वयन दोनों के ऊपर एक विक्रेता स्वतंत्र मॉडल होने की आवश्यकता होगी। दूसरी तरफ, सर्वर डेटाबेस से डेटा को कुछ परिवहन प्रारूप में बदलना और इसे क्लाइंट डेटाबेस में वापस डालने से बहुत अधिक ओवरहेड लगता है।

किसी भी सुझाव को एक सुरुचिपूर्ण और रखरखाव तरीके से कैसे हल किया जाए?

उत्तर

10

मैं एक ऐप्लिकेशन है जो स्थानीय स्तर पर हैंडसेट पर एक बड़ा डेटाबेस के छोटे हिस्से को सिंक करता है पर काम कर रहा हूँ। एक प्रारंभिक प्रीलोड है जो हैंडसेट पर होना पड़ता है लेकिन इसके बाद अपडेट पृष्ठभूमि में असीमित रूप से होते हैं।

सबसे पहले, सर्वर और हैंडसेट decoupling JSON या XML का उपयोग कर अत्यधिक की सलाह दी है। एक तकनीक में लॉक करना हमेशा मुद्दों का कारण बनता है क्योंकि प्लेटफॉर्म पर ध्यान दिए बिना आपको उसी तकनीक का उपयोग करने के लिए मजबूर होना पड़ता है। यही है, यदि आप अन्य प्लेटफार्मों (वेब, आईओएस, आदि ..) में विस्तार करने की योजना बना रहे हैं तो आपको सर्वर द्वारा निर्धारित प्रारूप का उपयोग करने के लिए मजबूर होना पड़ता है।एक सामान्य प्रारूप का चयन करना लंबे समय तक इतना आसान बना देगा। हकीकत में जेएसओएन पढ़ने/लिखने वाले सार्वजनिक पुस्तकालयों की मात्रा एक मामूली मामला है।

डेटा को सिंक करने के लिए हम दो तरीके हैं जिनका उपयोग हम करते हैं;

1. AlarmManager

हम अनुसूची AlarmManager एक नियमित समय पर wakeup के लिए एक सेवा को गति प्रदान करने (कहते हैं कि हर 6 घंटे की सुविधा देता है)। जागरूकता पृष्ठभूमि सेवा शुरू करती है जो सर्वर से संपर्क करती है, जेएसओएन में परिवर्तन डाउनलोड करती है और स्थानीय SQLite डीबी अपडेट करती है। यदि कोई कनेक्शन नहीं है, तो अद्यतन छोड़ दिया गया है और अगले wakeup के लिए निर्धारित किया गया है। कनेक्शन पुनर्स्थापित होने पर हम सिंक को स्वचालित रूप से पुनरारंभ करने के लिए कनेक्टिविटी चेंज रिसीवर जोड़ते हैं।

2. GCM

यह एक छोटे से अधिक काम है, लेकिन अगर आप केवल स्थानीय डेटाबेस अद्यतन है जब वहाँ परिवर्तन कर रहे हैं बैटरी और डेटा उपयोग का एक बहुत बचाता है। Google क्लाउड मैसेजिंग डिवाइस पर एक वेकअप संदेश भेज सकता है और सिंक सेवा शुरू करने के लिए कह सकता है। सिंक सेवा उपरोक्त AlarmManager विधि के समान ही चलती है।

हम ऊपर दिए गए दोनों तरीकों का संयोजन करते हैं, इस पर निर्भर करता है कि आपको "ताजा" डेटा की आवश्यकता होती है और यह कितनी बार बदलती है। आरएसएस फ़ीड की तरह कुछ शायद हर 30min को अद्यतन किया जाना चाहिए जबकि मौसम डेटा को हर 4 घंटे से अधिक अद्यतन करने की आवश्यकता नहीं हो सकती है।

तो डेटाबेस सिंक चलाने के लिए हम उपयोग करते हैं;

रिसीवर -, JSON डाउनलोड> सर्वर से कनेक्ट और SQLite प्रदाताओं प्रदाता अद्यतन - -> डेटाबेस में रिकॉर्ड डालने और ContentObservers ContentObservers करने के लिए सामग्री परिवर्तन प्रसारित> प्रणाली की घटनाओं के लिए सुनने और गति प्रदान सेवा सेवाएँ - > जब एप्लिकेशन चल रहा है, ContentObservers नए डेटा

तकनीकी जानकारी का एक बहुत ऊपर घटकों में से प्रत्येक में नहीं है, लेकिन है कि एक स्थानीय के साथ सर्वर डेटा सिंक्रनाइज़ करने के लिए एक बहुत मजबूत वास्तुकला के साथ आप प्रदान करना चाहिए साथ यूआई अद्यतन db।

+0

मैं जॉन द्वारा ऊपर वर्णित 2 विकल्पों में से एक का दृढ़ता से सुझाव देता हूं। एंड्रॉइड में जिस तरह से बनाया गया है, उसके कारण जीसीएम को प्राथमिकता दी जाती है। लेकिन अगर आपकी परियोजना की जरूरतें जीसीएम मार्ग को पूरा नहीं कर पाती हैं, तो पहला विकल्प बनी हुई है। –

+0

मुझे पहले विकल्प पसंद नहीं हैं क्योंकि इससे डेटा अपडेट करने का परिणाम हो सकता है जिसे उपयोगकर्ता कभी नहीं देख सकता है। जीसीएम मैं हल्के नोटिफिकेशन के लिए शामिल करने की योजना बना रहा हूं लेकिन इसके माध्यम से डेटाबेस अपडेट ट्रिगर करना मेरे मामले में बहुत अपमानजनक हो सकता है। साथ ही मुझे यकीन नहीं है कि यह मोबाइल फोन प्लेटफ़ॉर्म पर कितनी अच्छी तरह से काम करेगा क्योंकि उन पुश सेवाओं को विक्रेता विशिष्ट दिखता है। इस तीसरे विकल्प के बारे में आप क्या सोचते हैं? उपयोग के आधार पर स्थानीय डेटाबेस अद्यतन करें। जब डेटा को स्थानीय रूप से एक्सेस किया जाता है तो स्थानीय परिणाम तुरंत लौटाया जा सकता है लेकिन सर्वर के लिए अनुरोध एक ही डेटा के लिए भेजा जाता है – mibollma

5

मैं ऐसी परियोजना पर काम कर रहा हूं जिसमें समान आवश्यकताएं हैं। हम किसी सर्वर पर कहीं भी एक बड़ा, उपलब्ध डेटाबेस रखना चाहते हैं और उसके बाद मोबाइल डिवाइस जो डेटा प्राप्त करते हैं। यदि डिवाइस ऑफ़लाइन जाते हैं तो यह ठीक है क्योंकि उन्होंने स्थानीय रूप से डेटा की अपनी प्रतियां सहेजी हैं।

हम मोबाइल उपकरणों पर BigCouch (अपाचे CouchDB का कांटा का समर्थन करता है कि क्लस्टरिंग) सर्वर प्रौद्योगिकी के रूप में और फिर काउचबेस मोबाइल उपयोग करने के लिए तय कर लिया है। (एंड्रॉइड के लिए टच डीबी एक नोट के रूप में कॉचबेस मोबाइल को प्रतिस्थापित करेगा, लेकिन यह अभी तक स्थिर नहीं है।)

सोफे * प्रौद्योगिकियों के साथ जाने का कारण यह है कि सोफे पर HTTP पर अच्छी प्रतिकृति है। आप मोबाइल डिवाइस पर प्रोग्रामेटिक रूप से सिंक ईवेंट शुरू कर सकते हैं और यह आपके लिए सभी आवेषण, अपडेट और डिलीट को दोहराएगा। यह मोबाइल डिवाइस पर अपने स्वयं के एम्बेडेड कॉच डीबी पर जानकारी संग्रहीत करता है, इसलिए इसे ऑफ़लाइन पढ़ा जा सकता है।

आप काउच सड़क के नीचे जाने के लिए नहीं करना चाहता था, तो आप बस SQLlite की तरह कुछ अपने बाकी/API कॉल के परिणाम स्टोर करने के लिए इस्तेमाल कर सकते हैं। तब जब आप मोबाइल डिवाइस ऑफलाइन हो जाते हैं और फिर वापस आते हैं तो आपको अपना खुद का प्रतिकृति तर्क लिखना होगा। ऐसा करने के रचनात्मक तरीके हैं, तो शायद यह एक विकल्प है।

+0

कॉचबेस मोबाइल द्वारा क्या आपका मतलब है कि गिटूब पर एंड्रॉइड-कोचबेस और टच डीबी द्वारा आपका मतलब है कि टिथबीबी-एंड्रॉइड जीथ्यूब पर? बस सोच रहा है क्योंकि उनमें से दोनों काफी समय से काम नहीं कर रहे हैं जो मुझे आश्चर्यचकित करता है कि उनमें से कोई भी किसी उत्पादक वातावरण के लिए उपयुक्त होगा। – mibollma

+1

हाँ। उन दोनों का मतलब था जो मेरा मतलब था। आप सही हैं कि दोनों परियोजनाएं काफी हद तक मर चुकी हैं। वास्तव में कॉचबेस मोबाइल आधिकारिक तौर पर मृत है। टच डीबी आईओएस संस्करण का एक बंदरगाह है (जो बहुत स्थिर है और बहुत काम करता है), लेकिन यह पूरा नहीं हुआ है। एंड्रॉइड के लिए हम समय के लिए कॉचबेस मोबाइल के साथ जा रहे हैं। कोड मर चुका है, लेकिन यह काम करता है। हमारी आशा यह है कि सोफे के लोगों को अब टच डीबी पोर्ट पर ध्यान केंद्रित करने का समय होगा क्योंकि कॉचबेस 2.0 जारी किया गया है। यह वास्तव में एक गणना जोखिम है इसलिए हमें स्क्रैच से प्रतिकृति लिखना नहीं है। – ryan1234

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^