NoSQL में डेटा, स्थिरता और विश्वास खोए बिना कैसेंड्रा की आँखों में कैसे देखें

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

मैं आपको कैसेंड्रा डीबीएमएस पर आधारित समाधान लागू करने में हमारे अनुभव के बारे में बताऊंगा: हमें क्या सामना करना पड़ा, हम कठिन परिस्थितियों से कैसे बाहर निकले, क्या हम NoSQL का उपयोग करने से लाभ उठाने में सक्षम थे और हमें कहां अतिरिक्त प्रयास/धन का निवेश करना पड़ा .
प्रारंभिक कार्य एक ऐसी प्रणाली का निर्माण करना है जो किसी प्रकार के भंडारण में कॉल को रिकॉर्ड करे।

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

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

तो, अनुभव ने हमें यही दिया है

हाँ, एक विफल नोड कोई त्रासदी नहीं है। यह कैसेंड्रा की दोष सहनशीलता का सार है। लेकिन एक नोड जीवित हो सकता है और साथ ही उसके प्रदर्शन में दिक्कत आनी शुरू हो सकती है. जैसा कि यह निकला, यह तुरंत पूरे क्लस्टर के प्रदर्शन को प्रभावित करता है।

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

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

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

हमें परीक्षण क्षेत्रों में डेटा स्थानांतरित करने में समस्या का सामना करना पड़ा (परीक्षण में 5 नोड्स बनाम प्रोम में 20)। इस स्थिति में, डंप का उपयोग नहीं किया जा सकता.

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

सम्मिलित करते समय टाइमआउट. कैसेंड्रा रिकॉर्डिंग में सुंदर है, लेकिन कभी-कभी आने वाला प्रवाह उसे काफी परेशान कर सकता है. ऐसा तब होता है जब एप्लिकेशन कई रिकॉर्ड्स के इर्द-गिर्द घूमना शुरू कर देता है जिन्हें किसी कारण से सम्मिलित नहीं किया जा सकता है। और हमें एक वास्तविक डीबीए की आवश्यकता होगी जो धीमी क्वेरी के लिए जीसी.लॉग, सिस्टम और डीबग लॉग, लंबित कॉम्पैक्शन पर मेट्रिक्स की निगरानी करेगा।

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

हमने कैसे निर्णय लिया

नोड को डूबने से बचाने के लिए, SWAP को अक्षम कर दिया गया था. और अब, यदि स्मृति की कमी है, तो नोड को नीचे जाना चाहिए और बड़े जीसी विराम नहीं बनाने चाहिए।

इसलिए, अब हम डेटाबेस में तर्क पर भरोसा नहीं करते हैं। एप्लिकेशन डेवलपर स्वयं को पुनः प्रशिक्षित कर रहे हैं और अपने कोड में सक्रिय रूप से सावधानी बरतना शुरू कर रहे हैं। डेटा भंडारण और प्रसंस्करण का आदर्श स्पष्ट पृथक्करण।

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

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

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

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

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

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

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

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

परिणामस्वरूप, अभी के लिए EACH_QUORUM लिखने के लिए संगति स्तर पर, पढ़ने के लिए - LOCAL_QUORUM पर रुका

संक्षिप्त प्रभाव और निष्कर्ष

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

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

जैसा कि आप देख सकते हैं, प्रदर्शनों की सूची विस्तृत और विविध है। और यदि हम NoSQL के समर्थकों/विरोधियों का खेमा चुनते हैं, तो हम समर्थकों में शामिल हो जाएंगे, क्योंकि हमें अपने फायदे मिले हैं, और ठीक वहीं जहां हमें उम्मीद थी।

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

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

उदाहरण के लिए, कैसेंड्रा के अपडेट पर समय पर नज़र रखेंक्योंकि हमें जो समस्याएँ मिलीं उनमें से बहुत सी समस्याओं के बारे में पहले से ही पता था और उन्हें ठीक कर दिया गया था।

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

परियोजना परीक्षण चरण में निगरानी और परिचालन क्षमता में सुधार करें। प्रारंभ में, हमारे समाधान के सभी संभावित उपभोक्ताओं को यथासंभव ध्यान में रखें, क्योंकि डेटाबेस संरचना अंततः इसी पर निर्भर करेगी।

संभावित अनुकूलन के लिए परिणामी सर्किट को कई बार घुमाएँ। चुनें कि कौन से फ़ील्ड को क्रमबद्ध किया जा सकता है। समझें कि सबसे सही ढंग से और सर्वोत्तम तरीके से ध्यान में रखने के लिए हमें कौन सी अतिरिक्त तालिकाएँ बनानी चाहिए, और फिर अनुरोध पर आवश्यक जानकारी प्रदान करें (उदाहरण के लिए, यह मानकर कि हम एक ही डेटा को अलग-अलग तालिकाओं में संग्रहीत कर सकते हैं, अलग-अलग ब्रेकडाउन को ध्यान में रखते हुए) विभिन्न मानदंड, हम पढ़ने के अनुरोधों के लिए महत्वपूर्ण रूप से CPU समय बचा सकते हैं)।

बुरा नहीं है टीटीएल संलग्न करने और पुराने डेटा को साफ करने के लिए तुरंत प्रावधान करें।

कैसेंड्रा से डेटा डाउनलोड करते समय एप्लिकेशन लॉजिक को FETCH सिद्धांत पर काम करना चाहिए, ताकि सभी पंक्तियों को एक ही बार में मेमोरी में लोड न किया जाए, बल्कि बैचों में चुना जाए।

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

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

छह महीने के जीवन के बाद कैसेंड्रा का क्या होता है? सामान्य तौर पर, कोई अनसुलझी समस्याएँ नहीं हैं। हमने कोई गंभीर दुर्घटना या डेटा हानि भी नहीं होने दी। हां, हमें कुछ समस्याओं की भरपाई के बारे में सोचना पड़ा जो पहले उत्पन्न नहीं हुई थीं, लेकिन अंत में इसने हमारे वास्तुशिल्प समाधान को बहुत प्रभावित नहीं किया। यदि आप चाहते हैं और कुछ नया आज़माने से डरते नहीं हैं, और साथ ही बहुत निराश भी नहीं होना चाहते हैं, तो इस तथ्य के लिए तैयार हो जाइए कि कुछ भी मुफ़्त नहीं है। आपको पुराने लीगेसी समाधान की तुलना में दस्तावेज़ को समझना होगा, उसमें गहराई से जाना होगा और अपने स्वयं के व्यक्तिगत रेक को इकट्ठा करना होगा, और कोई भी सिद्धांत आपको पहले से नहीं बताएगा कि कौन सा रेक आपका इंतजार कर रहा है।

स्रोत: www.habr.com