एक-शॉट प्रतिकृति बनाम निरंतर प्रतिकृतियों की लागत (टच डीबी और क्लाउडेंट का उपयोग करके)

Question

हमारे पास एक ऐप है जो क्लाउडेंट को रिमोट सर्वर के रूप में उपयोग करता है। फिर भी, क्लाउडेंट पिछले अनुभव से टच डीबी की निरंतर प्रतिकृतियों के साथ पूरी तरह से संगत नहीं है। तो अब हमारे लिए एक निश्चित आवृत्ति पर मैन्युअल रूप से एक-शॉट प्रतिकृति ट्रिगर करना है। फिर भी, हम जानना चाहते हैं कि उस दृष्टिकोण को निरंतर प्रतिकृतियों से अधिक पैसा खर्च करने जा रहा है, क्योंकि निरंतर प्रतिकृतियां लंबी अवधि का उपयोग करती हैं और अक्सर सर्वर से पूछताछ करने की आवश्यकता नहीं होती है। दूसरे शब्दों में, क्या क्लाउडेंट के साथ एक-शॉट पुल प्रतिकृतियां लक्ष्य के रूप में हमें एक अनुरोध प्राप्त करती हैं?

धन्यवाद, पॉल

Answer 1

मुझे लगता है कि इस मुद्दे को आप [1] है का संदर्भ लें। क्लाउडेंट की प्रतिकृति कॉच डीबी के साथ 100% संगत है। इस उदाहरण में, टच डीबी के लॉग इंगित करते हैं कि आईओएस नेटवर्क स्टैक को अधूरा JSON पर TouchDB पर पास किया गया है। यह स्पष्ट नहीं है कि प्रतिकृति विफलता के लिए इस मामले में को दोषी ठहराया गया था।

[1] https://github.com/couchbaselabs/TouchDB-iOS/issues/241

लागत प्रश्न के लिए, एक शॉट के पुल प्रतिकृति _changes फ़ीड हर बार ऐसा होता है, साथ ही अन्य को दोहराने के लिए आवश्यक अनुरोध करने के लिए किसी GET का परिणाम देगा। यह _changes अनुरोध आपके क्लाउडेंट खाते के विरुद्ध एक प्रकाश HTTP अनुरोध के रूप में गिना जाएगा।

हालांकि, कि क्या यह अधिक या कम अनुरोध समग्र के रूप में बाहर काम करता है दूरस्थ सर्वर से नीचे आ रहा परिवर्तन की संख्या पर निर्भर करता है।

यह भी याद रखना कि _changes कॉल की संख्या रहे हैं अन्य शामिल कॉल की संख्या (उदाहरण के लिए, परिवर्तन की सामग्री हो रही कई संलग्नक देखते हैं खुद को और विशेष रूप से अगर) करने के लिए बहुत छोटे रिश्तेदार महत्वपूर्ण है।

हालांकि इस सवाल TouchDB के लिए विशिष्ट है, और मुझे लगता है कि codebase के विशिष्ट व्यवहार का उल्लेख है, अनुरोध के साथ यह उत्तर सौदों प्रतिकृति में किसी भी दो प्रणालियों CouchDB प्रतिकृति प्रोटोकॉल बोलने के बीच शामिल [2]।

[2] http://www.dataprotocols.org/en/latest/couchdb_replication.html

के एक काल्पनिक उदाहरण लेते हैं: 1 प्रति अद्यतन 10 सेकंड विंडो पर प्रतिकृति है, जहां एक TouchDB डेटाबेस लक्ष्य है के लिए स्रोत डेटाबेस। आइए 5 मिनट के मतदान बनाम निरंतर प्रतिकृति लें। कॉल-गिनती की सादगी के लिए, चलिए चित्र से अनुलग्नक भी लेते हैं। हम यह भी मान लेंगे कि डिवाइस का निरंतर नेटवर्क कनेक्शन है।

निरंतर मामले के लिए, प्रत्येक 10s टच डीबी _changes फ़ीड में एक अपडेट प्राप्त करेगा। इससे longpoll कनेक्शन बंद हो जाता है। टच डीबी स्रोत डेटाबेस से अद्यतनों का अनुरोध करते हुए परिवर्तनों के माध्यम से चलता है; दूरस्थ सर्वर पर एक या अधिक GET अनुरोध। जबकि यह हो रहा है, टच डीबी को longpoll अनुरोध _changes पर खोलना है।तो पांच मिनट की अवधि में, आप शायद 30 कॉलों को _changes के साथ समाप्त कर देंगे, साथ ही दस्तावेज़ों को प्राप्त करने के लिए सभी कॉल और चेकपॉइंट रिकॉर्ड करें।

हर पांच मिनट में एक शॉट शॉट प्रतिकृति के साथ इसकी तुलना करें। आप एक _changes फ़ीड कॉल में 30 अपडेट की अधिसूचना प्राप्त करेंगे। TouchDB एक अनुकूलन लागू करता है [3] जिससे यह _all_docs फोन, 1- revs के लिए अद्यतन दस्तावेज प्राप्त करने के लिए ताकि आप ऊपर एक भी कॉल के साथ सभी 30 दस्तावेजों ( के रूप में निरंतर मामले में संभव नहीं पाने के लिए खत्म हो सकता है आप एक ही परिवर्तन प्राप्त हुआ है)। फिर आपके पास रिकॉर्ड करने के लिए चेकपॉइंट दस्तावेज़ है। 5 से कम HTTP कॉल पर, के लगभग तीसरे हिस्से में निरंतर मामला है क्योंकि आपने अतिरिक्त _changes अनुरोधों से परहेज किया है।

[3] https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm#performance

यह अपडेट की बारंबारता आप स्रोत डेटाबेस की उम्मीद करने के लिए नीचे आता है। एक-शॉट प्रतिकृति एक चिकनी कीमत वक्र प्रदान करने की संभावना है क्योंकि आप अपने द्वारा किए गए अनुरोधों की संख्या के बेहतर नियंत्रण में हैं।

एक और सवाल यह है कि नेटवर्क डिस्कनेक्ट की वजह से कनेक्शन कितनी बार गिर जाएगा जो नियमित रूप से मोबाइल उपकरणों के साथ होता है। टच डीबी की निरंतर प्रतिकृतियां प्रत्येक बार उपयोगकर्ता लाइन पर आती हैं (अगर _replicator डेटाबेस के माध्यम से जोड़ा जाता है) वापस आ जाएगा। यह अप्रत्याशित लागत का और स्रोत है।

हालांकि, परिवर्तनों की अधिक तत्काल दृश्यता से लाभ निश्चित रूप से अनिश्चितता के लायक हो सकते हैं।