रीक उपयोग पैटर्न

Riak एक NoSQL समाधान है, ईमानदार DHT (कुंजी / मूल्य भंडारण) संघर्षों को हल करने के लिए अतिरिक्त क्षमताओं के साथ।

एक वितरित हैश तालिका में पेशेवरों और विपक्ष दोनों हैं। DHT अच्छी तरह से मापता है, लेकिन विवाद के कारण डेटा हानि हो सकती है, निम्न उदाहरण पर विचार करें:

client a: def o-value = DHT.get("some-key");
client a: def a-value = changeValue(o-value);
client b: def o-value = DHT.get("some-key");
client a: DHT.put("some-key", a-value);
client b: def b-value = changeValue(o-value);
client b: DHT.put("some-key", b-value);

यह पता चला कि क्लाइंट बी ने ग्राहक के डेटा को फिर से लिखा है और कोई भी इसके बारे में नहीं जानता है (न तो ए, न ही बी, और न ही जो इस कुंजी पर डेटा पढ़ता है)।

चूंकि कई NoSQL डेटाबेस में मूल रूप से DHT होता है, इसलिए यह देखना दिलचस्प है कि वे समवर्ती पहुंच की समस्या को हल करने का प्रयास कैसे करते हैं।

उदाहरण के लिए, MongoDB एक तुलना-और-स्वैप रणनीति का उपयोग करता है: प्रत्येक दस्तावेज़ (मान) के साथ इसका संस्करण संग्रहीत किया जाता है, जब अद्यतन किया जाता है, तो परिवर्तित दस्तावेज़ के "पूर्वज" के संस्करण को इंगित किया जाता है, यदि अद्यतन करने के समय पूर्वज डेटाबेस में संग्रहीत होता है, तो अद्यतन पास होता है, यदि नहीं, तो: अद्यतनकर्ता संदेश प्राप्त करता है, और फिर से अपग्रेड करने की कोशिश करता है - एसटीएम का एक एनालॉग। यह दृष्टिकोण शार्क के साथ अच्छी तरह से काम करता है, लेकिन खराब प्रतिकृति के साथ।

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

Riak अधिक विकास की स्थिति को लागू करता है, लेकिन बड़ी मात्रा में जानकारी के साथ काम करते समय डेटा की मापनीयता और विश्वसनीयता प्रदान करता है। यह आलेख वर्णन करेगा कि ठेठ वेब अनुप्रयोगों को विकसित करते समय रिआक की सीमाओं के आसपास कैसे प्राप्त करें।

ब्लॉग

रिआक के आधार पर लागू किए गए पहले आदिम पर विचार करें - छोटे आकार की केवल एक सूची।

कल्पना कीजिए कि हम एक ब्लॉग लिख रहे हैं, जिसमें से प्रत्येक पोस्ट के लिए बहुत सारी टिप्पणियां नहीं होंगी और जोड़ने के बाद टिप्पणी को बदला नहीं जा सकता है। इस मामले में, पूरे पोस्ट को एक मूल्य के रूप में टिप्पणियों के साथ संग्रहीत करना उचित है, इसलिए रीड ऑपरेशन ओ (1) से गुजरेगा। आइए डेटा के लिए योजना का वर्णन करें:

 public class Post { public static class Comment implements Comparable<Comment> { public String text; public int ts; //timestamp /* equals, hashCode, compareTo*/ } public String text; public List<Comment> comments; } 

अब कल्पना कीजिए कि दो उपयोगकर्ताओं ने "एक साथ" एक टिप्पणी जोड़ी:

client a: def o-post = DHT.get("post/13");
client a: def a-post = addComment(o-value, " , ");
client b: def o-post = DHT.get("some-key");
client a: DHT.put("post/13", a-post);
client b: def b-post = addComment(o-post, " ");
client b: DHT.put("post/13", b-post);

अब डेटाबेस में दो प्रविष्टियां आईडी "पोस्ट / 13" के साथ संग्रहीत की जाती हैं; और इस कुंजी के लिए आवेदन करने वाले पहले दोनों को प्राप्त होगा और उन्हें अपने दम पर गला घोंटना होगा। सादगी के लिए, मान लीजिए कि पोस्ट को संपादित नहीं किया जा सकता है, इसलिए किसी भी "शाखा" से एक पोस्ट उपयुक्त है, और चूंकि टिप्पणियां केवल जोड़ी जा सकती हैं, दोनों पोस्ट के लिए टिप्पणी सूची में एक सामान्य उपसर्ग है, इसलिए, आपको इसे चुनने और उपसर्ग से एक नई सूची बनाने की आवश्यकता है, यह पहली सूची में परिवर्धन और दूसरी सूची में इसके अतिरिक्त। मर्ज ऑपरेशन निम्नानुसार होगा:

 public static Post merge(Post a, Post b) { Post c = new Post(); c.text = a.text; c.comments = Mergers.mergeLists(a.comments, b.comments); return c; } 

मर्जलिस्ट को इस प्रकार परिभाषित किया गया है:

 public static <T extends Comparable<T>> List<T> mergeLists(List<T> a, List<T> b) { List<T> result = new ArrayList<T>(); List<T> rest = new ArrayList<T>(); int max = Math.min(a.size(), b.size()); int i=0; //    for(;i<max && a.get(i).equals(b.get(i));i++) { result.add(a.get(i)); } //   for(int j=i;j<a.size();j++) { rest.add(a.get(j)); } for(int j=i;j<b.size();j++) { rest.add(b.get(j)); } //   Collections.sort(rest); //   for(T item : rest) { result.add(item); } return result; } 

जाहिर है, मर्जलिस्टर्स सेट के एक संघ के समान है, और इसलिए, यदि कुछ तत्व एक या बी में था, तो यह परिणामी सूची में भी होगा, इसलिए, जब विलय होता है, तो कोई डेटा हानि नहीं होती है। यह पता चला है कि अब हमने प्रतिस्पर्धी पहुंच की समस्याओं से बचते हुए रिआक में सूची लिखना सीख लिया है।

यदि आपको कई पदों को डगमगाने की आवश्यकता है, तो फोल्ड कॉम्बिनेटर के अंदर मर्ज का उपयोग करें।

अलर्ट (संदेश, अपडेट)

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

सभी प्रकार की सूचनाएं इस आदिम पर अच्छी तरह से गिरती हैं। सबसे पहले, घटना की तुलना में घटना की सूचना बहुत कम महत्वपूर्ण है; दूसरे, यह संभावना नहीं है कि उपयोगकर्ता एक पुरानी घटना के बारे में एक अधिसूचना देखना चाहता है यदि उसने लंबे समय तक लॉग इन नहीं किया है; तीसरा, यदि उपयोगकर्ता पहले से ही घटना के बारे में जानकारी का अध्ययन कर रहा है, तो अधिसूचना को हटा दिया जाना चाहिए।

पिछली योजना के विपरीत, जहां वस्तुओं की एक सूची को एक मूल्य के रूप में संग्रहीत किया गया था, दो सूचियों को यहां संग्रहीत किया जाएगा: "सूचना" की एक सूची और हटाए गए "सूचना" की सूची। मर्ज की स्थिति में, संबंधित सूचियों को मर्ज किया जाएगा और, इस प्रकार, हटाए गए ऑब्जेक्ट हटाए गए ऑब्जेक्ट की सूची में रहेंगे, और एक जोड़े गए लोगों की सूची में जोड़ा जाएगा (स्वाभाविक रूप से, विलय के बाद, हटाए गए लोगों को घटाया जाना होगा)। हम और अधिक औपचारिक रूप से लिखते हैं:



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



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

सूची की लंबाई से लेखन त्रुटियों का प्रतिशत

ग्राफ सूची परिवर्तनों के प्रतिशत को दर्शाता है, जिसके बाद सूची में मौजूद तत्वों की अधिकतम संख्या के आधार पर, रिमोट "अलर्ट" नए के रूप में फिर से प्रकट होता है। मुख्य पैरामीटर तय किया गया था (0.8 और 2), जो प्रति सेकंड लगभग 8 अनुरोधों और प्रति सेकंड 20 अनुरोधों से मेल खाता है। नीचे लिखा होगा कि यह उतना छोटा नहीं है जितना लगता है।

कुंजी पैरामीटर से लेखन त्रुटियों का प्रतिशत

ग्राफ एक निश्चित सूची लंबाई (क्रमशः 30 और 130 तत्वों) के साथ प्रमुख पैरामीटर के आधार पर त्रुटियों के प्रतिशत की गतिशीलता को दर्शाता है।

1% त्रुटि क्षेत्र

मुख्य पैरामीटर को एब्सिस्सा के साथ प्लॉट किया जाता है, लाल रेखा मान 1 के लिए जिम्मेदार है; समन्वय सूची की लंबाई है; लाल रेखाएं 100, 200 और 300 तत्वों के लिए जिम्मेदार हैं। काला मापदंडों का क्षेत्र चिह्नित करता है जिसके लिए त्रुटि 1% से कम है।



क्यों प्रति सेकंड 10 अनुरोध उतना छोटा नहीं है जितना लगता है। सबसे पहले, केवल लिखने के अनुरोधों को ध्यान में रखा जाता है, और दूसरी बात, यह अनुरोधों की कुल संख्या नहीं है, बल्कि एक वस्तु के लिए अनुरोधों की संख्या है। यदि हम उदाहरण के लिए, Google + डिज़ाइन करते हैं, तो प्रति सेकंड 10 अनुरोध सभी Google को कॉल की संख्या नहीं है, लेकिन एक रिकॉर्ड पर टिप्पणियों की अनुमानित आवृत्ति।

स्ट्रीम (ट्विटर पर VKontakte या टेप पर दीवार)

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

यह आदिम ट्विटर पर फ़ीड के साथ-साथ सामाजिक नेटवर्क पर दीवारों का अच्छी तरह से वर्णन करता है, लेकिन आप इसके लिए अन्य उपयोगों के बारे में सोच सकते हैं।

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

 class Info { public String key; public String prefix; public int lastChunk = 0; public String getChunkKey(int chunk) { return prefix + chunk; } public Info mergeWith(Info brother) { Info info = new Info(); info.key = key; info.prefix = prefix; info.lastChunk = Math.max(lastChunk, brother.lastChunk); return info; } } class Chunk<T extends Comparable<T>> { public String key; List<T> added = new ArrayList<T>(); List<T> deleted = new ArrayList<T>(); public void add(T obj) { added.add(obj); } public void delete(T obj) { deleted.add(obj); } public Iterable<T> getData() { List<T> data = new ArrayList<T>(added); data.removeAll(deleted); return data; } public Chunk<T> mergeWith(Chunk<T> brother) { Chunk<T> chunk = new Chunk(); chunk.key = key; chunk.added = mergeLists(added, brother.added); chunk.deleted = mergeLists(deleted, brother.deleted); return chunk; } } 

मुझे लगता है कि ऑपरेशन स्पष्ट हैं। यदि आप सूची में कोई आइटम जोड़ना चाहते हैं:

• हमें वह जानकारी मिलती है जो प्रत्येक सूची से मेल खाती है
• निर्धारित करें और अंतिम हिस्सा प्राप्त करें
• अगर यह पूरा नहीं हुआ है तो रिकॉर्ड जोड़ें और चंक को बचाएं
• अन्यथा, एक नया हिस्सा बनाएं, एक रिकॉर्ड जोड़ें और इसे बचाएं; इसके अलावा, हम "पॉइंटर" को सूचना के अंतिम भाग में संपादित करते हैं और सहेजते हैं

चूंकि प्रवाह को क्रमिक रूप से बाईपास किया जाता है (ट्विटर, दीवार ...) चंक द्वारा चंक किया जाता है, अक्सर हटाने के साथ खाली विखंडों को ढूंढना संभव है; फिर आपको डेटा वापस करने के लिए अगला हिस्सा (या निम्न) लेने की आवश्यकता है। यह पता चला है कि एक बहुत ही लगातार विलोपन के साथ, डेटा अधिग्रहण ऑपरेशन की अवधि का अनुमान नहीं लगाया जा सकता है, लेकिन एक दुर्लभ विलोपन के साथ, यह ओ (1) है।

निष्कर्ष

जैसा कि आप लेख से देख सकते हैं, Riak पर आप डेटा योजनाओं को वेब में सामान्य रूप से रख सकते हैं और बाद में कई नोड्स में इन डेटा का दर्द रहित वितरण प्राप्त कर सकते हैं। यह रेकिट प्रोग्रामर को प्रदान करने वाले प्राइमेट के सेट के कारण हासिल किया जाता है।

संघर्ष के संकल्प के प्रति पारदर्शी दृष्टिकोण और प्रत्येक अनुरोध के लिए प्रतिबंध (CAP) चुनने में लचीलापन के कारण मुझे Riak दृष्टिकोण पसंद आया।