कैसंड्रा की आंखों में कैसे देखें और नॉटएसक्यूएल में डेटा, स्थिरता और विश्वास खो दें

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

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

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

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

तो, यहाँ अनुभव ने हमें क्या दिया

हां, दुर्घटनाग्रस्त नोड कोई त्रासदी नहीं है। यह कैसंड्रा की गलती सहिष्णुता का सार है। लेकिन नोड लाइव हो सकता है और एक ही समय में प्रदर्शन पर शिथिलता शुरू हो सकती है । जैसा कि यह निकला, यह तुरंत पूरे क्लस्टर के प्रदर्शन को प्रभावित करता है।

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

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

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

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

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

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

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

हमने कैसे तय किया

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

इसलिए, हम डेटाबेस में तर्क की उम्मीद नहीं रखते हैं। एप्लिकेशन डेवलपर्स relearn और अपने स्वयं के कोड में सक्रिय रूप से सुरक्षित करने के लिए शुरू करते हैं। डाटा स्टोरेज और प्रोसेसिंग का सही क्लियर सेपरेशन।

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

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

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

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

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

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

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

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

परिणामस्वरूप, इस समय हम रिकॉर्ड EACH_QUORUM, पढ़ने के लिए - LOCAL_QUORUM के लिए संगतता के स्तर पर रुक गए

संक्षिप्त इंप्रेशन और निष्कर्ष

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

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

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

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

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

उदाहरण के लिए, समय-समय पर कैसेंड्रा को अपडेट का ट्रैक रखें , क्योंकि काफी कुछ समस्याएं जो हमें प्राप्त हुई थीं, वे पहले से ही ज्ञात और सही थीं।

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

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

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

टीटीएल को तुरंत माउंट करने और आउटडेटेड डेटा को साफ करने के लिए यह एक अच्छा विचार है ।

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

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

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

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