कैसंड्रा। यदि आप केवल Oracle जानते हैं तो कैसे न मरें

हे हबर।

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

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

वह और किसमें अच्छी है? यह बहुत सारे अनुरोधों को संभालने के बारे में है। लेकिन कितना बहुत है? प्रति सेकंड 10, 20, 30, 40 हजार अनुरोध ज्यादा नहीं हैं। रिकॉर्डिंग के लिए प्रति सेकंड 100 हजार अनुरोध - भी। ऐसी कंपनियाँ हैं जिन्होंने कहा कि वे प्रति सेकंड 2 मिलियन अनुरोध रखती हैं। उन्हें शायद इस पर विश्वास करना होगा.

और सिद्धांत रूप में, कैसंड्रा में संबंधपरक डेटा से एक बड़ा अंतर है - यह बिल्कुल भी उनके समान नहीं है। और ये याद रखना बहुत जरूरी है.

एक जैसी दिखने वाली हर चीज़ एक जैसी काम नहीं करती

एक बार एक सहकर्मी मेरे पास आया और पूछा: "यहां एक सीक्यूएल कैसेंड्रा क्वेरी भाषा है, और इसमें एक चयन कथन है, इसमें कहां है, इसमें और है। मैं पत्र लिखता हूं और यह काम नहीं करता. क्यों?"। कैसंड्रा को एक रिलेशनल डेटाबेस की तरह मानना ​​हिंसक आत्महत्या करने का सही तरीका है। और मैं इसका प्रचार नहीं कर रहा हूं, यह रूस में प्रतिबंधित है। आप बस कुछ ग़लत डिज़ाइन करेंगे।

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

ऐसा इसलिए है क्योंकि कैसेंड्रा एक हाइब्रिड डेटाबेस है: यह एक साथ एक महत्वपूर्ण मान प्रदान करता है और डेटा को विस्तृत कॉलम में संग्रहीत करता है। जावा या कोटलिन में, इसे इस प्रकार वर्णित किया जा सकता है:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

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

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

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

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

इस मामले में प्राथमिक कुंजी में एक कॉलम होता है, और यह विभाजन कुंजी भी है।

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

चयन करें: कब अनुमति दें फ़िल्टरिंग पूर्ण स्कैन में बदल जाती है, या क्या नहीं करना है

आइए कुछ चुनिंदा कथन लिखें: select * from users where, userid = . यह ओरेकल की तरह निकलता है: हम चयन लिखते हैं, शर्तें निर्दिष्ट करते हैं और सब कुछ काम करता है, उपयोगकर्ताओं को यह मिलता है। लेकिन यदि आप, उदाहरण के लिए, एक निश्चित जन्म वर्ष वाले उपयोगकर्ता का चयन करते हैं, तो कैसेंड्रा शिकायत करती है कि वह अनुरोध पूरा नहीं कर सकती है। क्योंकि वह इस बारे में कुछ भी नहीं जानती है कि हम जन्म के वर्ष के बारे में डेटा कैसे वितरित करते हैं - उसके पास कुंजी के रूप में केवल एक कॉलम दर्शाया गया है। फिर वह कहती है, “ठीक है, मैं अब भी यह अनुरोध पूरा कर सकती हूं। फ़िल्टरिंग की अनुमति जोड़ें।" हम निर्देश जोड़ते हैं, सब कुछ काम करता है। और इसी क्षण कुछ भयानक घटित होता है।

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

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

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

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

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

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

हम छँटाई निर्धारित करते हैं और प्रतिबंध लगाते हैं

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

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

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

किसी भी अस्पष्ट स्थिति में, एक नई तालिका बनाएं

यदि हम आईडी, उम्र या वेतन के आधार पर उपयोगकर्ताओं को लक्षित करने में सक्षम होना चाहते हैं, तो हमें क्या करना चाहिए? कुछ नहीं। बस दो तालिकाओं का उपयोग करें. यदि आपको तीन अलग-अलग तरीकों से उपयोगकर्ताओं तक पहुंचने की आवश्यकता है, तो तीन तालिकाएँ होंगी। वे दिन गए जब हम स्क्रू पर जगह बचाते थे। यह सबसे सस्ता संसाधन है. इसकी लागत प्रतिक्रिया समय से बहुत कम है, जो उपयोगकर्ता के लिए हानिकारक हो सकता है। उपयोगकर्ता के लिए 10 मिनट की तुलना में एक सेकंड में कुछ प्राप्त करना अधिक सुखद है।

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

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

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

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

क्लस्टरिंग कुंजी निर्माण चरण में एक बार सॉर्टिंग का चयन किया जाता है। यदि इसे बदलने की आवश्यकता है, तो हमें अपनी तालिका को एक अलग कुंजी के साथ अद्यतन करना होगा।

और सबसे महत्वपूर्ण बात: यदि हमें एक ही डेटा को 100 अलग-अलग तरीकों से पुनर्प्राप्त करने की आवश्यकता है, तो हमारे पास 100 अलग-अलग तालिकाएँ होंगी।

स्रोत: www.habr.com