कॅसांड्रा. जर तुम्हाला फक्त ओरॅकल माहित असेल तर कसे मरणार नाही

अहो हब्र.

माझे नाव मिशा बुट्रिमोव्ह आहे, मी तुम्हाला कॅसॅंड्राबद्दल थोडेसे सांगू इच्छितो. ज्यांना कधीही NoSQL डेटाबेसेसचा सामना करावा लागला नाही त्यांच्यासाठी माझी कथा उपयुक्त ठरेल - त्यात बरीच अंमलबजावणी वैशिष्ट्ये आणि त्रुटी आहेत ज्याबद्दल तुम्हाला माहिती असणे आवश्यक आहे. आणि जर तुम्ही ओरॅकल किंवा इतर कोणत्याही रिलेशनल डेटाबेसशिवाय दुसरे काहीही पाहिले नसेल तर या गोष्टी तुमचे जीवन वाचवतील.

Cassandra बद्दल इतके चांगले काय आहे? हा एक NoSQL डेटाबेस आहे जो अपयशाच्या एका बिंदूशिवाय डिझाइन केलेला आहे जो चांगल्या प्रकारे मोजतो. तुम्हाला काही डेटाबेससाठी दोन टेराबाइट्स जोडण्याची आवश्यकता असल्यास, तुम्ही फक्त रिंगमध्ये नोड्स जोडता. ते दुसर्‍या डेटा सेंटरमध्ये विस्तृत करायचे? क्लस्टरमध्ये नोड्स जोडा. प्रक्रिया केलेले आरपीएस वाढवायचे? क्लस्टरमध्ये नोड्स जोडा. हे उलट दिशेने देखील कार्य करते.

तिला आणखी काय चांगले आहे? हे बर्याच विनंत्या हाताळण्याबद्दल आहे. पण भरपूर किती आहे? 10, 20, 30, 40 हजार विनंत्या प्रति सेकंद जास्त नाहीत. रेकॉर्डिंगसाठी प्रति सेकंद 100 हजार विनंत्या - खूप. अशा कंपन्या आहेत ज्यांनी सांगितले की ते प्रति सेकंद 2 दशलक्ष विनंत्या ठेवतात. त्यांना कदाचित यावर विश्वास ठेवावा लागेल.

आणि तत्वतः, कॅसॅन्ड्राला रिलेशनल डेटापेक्षा एक मोठा फरक आहे - तो त्यांच्यासारखाच नाही. आणि हे लक्षात ठेवणे फार महत्वाचे आहे.

सारखी दिसणारी प्रत्येक गोष्ट सारखीच चालत नाही

एकदा एक सहकारी माझ्याकडे आला आणि विचारले: “ही CQL कॅसॅन्ड्रा क्वेरी भाषा आहे, आणि त्यात एक निवडक विधान आहे, त्यात कुठे आहे, आहे आणि आहे. मी पत्र लिहितो आणि ते काम करत नाही. का?". कॅसॅन्ड्राला रिलेशनल डेटाबेसप्रमाणे वागवणे हा हिंसक आत्महत्या करण्याचा योग्य मार्ग आहे. आणि मी त्याचा प्रचार करत नाही, ते रशियामध्ये प्रतिबंधित आहे. आपण फक्त काहीतरी चुकीचे डिझाइन कराल.

उदाहरणार्थ, एक ग्राहक आमच्याकडे येतो आणि म्हणतो: “चला टीव्ही मालिकांसाठी डेटाबेस किंवा रेसिपी निर्देशिकेसाठी डेटाबेस तयार करू. आमच्याकडे तिथे खाद्यपदार्थ असतील किंवा टीव्ही मालिका आणि कलाकारांची यादी असेल. आम्ही आनंदाने म्हणतो: "चला जाऊया!" फक्त दोन बाइट्स, दोन चिन्हे पाठवा आणि तुमचे काम पूर्ण होईल, सर्वकाही खूप जलद आणि विश्वासार्हपणे कार्य करेल. आणि ग्राहक येईपर्यंत सर्व काही ठीक आहे आणि म्हणते की गृहिणी देखील उलट समस्या सोडवत आहेत: त्यांच्याकडे उत्पादनांची यादी आहे आणि त्यांना कोणती डिश शिजवायची आहे हे त्यांना जाणून घ्यायचे आहे. तू मेला आहेस.

याचे कारण असे की कॅसॅंड्रा हा एक संकरित डेटाबेस आहे: तो एकाच वेळी मुख्य मूल्य प्रदान करतो आणि विस्तृत स्तंभांमध्ये डेटा संग्रहित करतो. जावा किंवा कोटलिनमध्ये, त्याचे वर्णन असे केले जाऊ शकते:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

म्हणजेच, एक नकाशा ज्यामध्ये क्रमवारी लावलेला नकाशा देखील असतो. या नकाशाची पहिली की रो की किंवा विभाजन की - विभाजन की. दुसरी की, जी आधीपासून क्रमवारी लावलेल्या नकाशाची की आहे, क्लस्टरिंग की आहे.

डेटाबेसचे वितरण स्पष्ट करण्यासाठी, तीन नोड्स काढू. आता तुम्हाला नोड्समध्ये डेटा कसा विघटित करायचा हे समजून घेणे आवश्यक आहे. कारण जर आपण सर्व काही एकामध्ये क्रॅम केले (तसे, हजार, दोन हजार, पाच असू शकतात - आपल्या आवडीनुसार), हे खरोखर वितरणाबद्दल नाही. म्हणून, आपल्याला एक गणितीय कार्य आवश्यक आहे जे संख्या परत करेल. फक्त एक संख्या, एक लांब इंट जी काही श्रेणीत येईल. आणि आमच्याकडे एका श्रेणीसाठी जबाबदार एक नोड असेल, दुसऱ्यासाठी दुसरा, nth साठी nth.

हा नंबर हॅश फंक्शन वापरून घेतला जातो, ज्याला आपण विभाजन की म्हणतो. हा तो स्तंभ आहे जो प्राथमिक की निर्देशामध्ये निर्दिष्ट केला आहे आणि हा स्तंभ आहे जो नकाशाची पहिली आणि सर्वात मूलभूत की असेल. कोणत्या नोडला कोणता डेटा मिळेल हे ते ठरवते. कॅसॅन्ड्रामध्ये एसक्यूएल प्रमाणेच जवळजवळ समान वाक्यरचना असलेली टेबल तयार केली आहे:

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

)

या प्रकरणात प्राथमिक की मध्ये एक स्तंभ असतो, आणि ती विभाजन की देखील असते.

आमचे वापरकर्ते कसे कार्य करतील? काही एका नोडवर जातील, काही दुसऱ्याकडे आणि काही तिसऱ्याकडे. परिणाम म्हणजे एक सामान्य हॅश टेबल, ज्याला नकाशा म्हणून देखील ओळखले जाते, ज्याला Python मध्ये डिक्शनरी म्हणून देखील ओळखले जाते किंवा एक साधी की मूल्य रचना आहे ज्यातून आपण सर्व मूल्ये वाचू शकतो, की द्वारे वाचू आणि लिहू शकतो.

निवडा: जेव्हा फिल्टरिंग पूर्ण स्कॅनमध्ये बदलते किंवा काय करू नये

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

जेव्हा आम्ही चाचणी डेटावर चालतो तेव्हा सर्वकाही ठीक असते. आणि जेव्हा आपण उत्पादनामध्ये क्वेरी कार्यान्वित करता, जिथे आमच्याकडे, उदाहरणार्थ, 4 दशलक्ष रेकॉर्ड आहेत, तेव्हा सर्वकाही आमच्यासाठी चांगले नसते. कारण अनुमती फिल्टरिंग हे एक निर्देश आहे जे Cassandra ला या टेबलमधील सर्व डेटा सर्व नोड्स, सर्व डेटा सेंटर्स (जर या क्लस्टरमध्ये बरेच असतील तर) गोळा करू शकतात आणि त्यानंतरच ते फिल्टर करू शकतात. हा फुल स्कॅनचा एक अॅनालॉग आहे, आणि क्वचितच कोणालाही त्याचा आनंद होईल.

आम्हाला फक्त आयडीद्वारे वापरकर्त्यांची आवश्यकता असल्यास, आम्ही यासह चांगले असू. परंतु कधीकधी आपल्याला इतर प्रश्न लिहावे लागतात आणि निवडीवर इतर निर्बंध लादावे लागतात. म्हणून, आम्हाला आठवते: हा सर्व नकाशा आहे ज्यामध्ये विभाजन की आहे, परंतु त्यामध्ये एक क्रमवारी लावलेला नकाशा आहे.

आणि तिच्याकडे एक की देखील आहे, ज्याला आपण क्लस्टरिंग की म्हणतो. ही की, ज्यामध्ये, आम्ही निवडलेल्या स्तंभांचा समावेश होतो, ज्याच्या मदतीने कॅसॅन्ड्राला समजते की त्याचा डेटा भौतिकरित्या कसा क्रमवारी लावला जातो आणि प्रत्येक नोडवर स्थित असेल. म्हणजेच, काही विभाजन की साठी, क्लस्टरिंग की तुम्हाला या ट्रीमध्ये डेटा कसा ढकलायचा, ते तेथे कोणते स्थान घेईल हे सांगेल.

हे खरोखर एक झाड आहे, एक तुलनाकर्ता तेथे फक्त म्हणतात, ज्यावर आपण ऑब्जेक्टच्या स्वरूपात स्तंभांचा एक विशिष्ट संच जातो आणि तो स्तंभांची सूची म्हणून देखील निर्दिष्ट केला जातो.

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 मिनिटांपेक्षा सेकंदात काहीतरी प्राप्त करणे अधिक आनंददायी आहे.

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

आम्ही तुमच्या विनंतीनुसार सर्वकाही डिझाइन करतो. मुख्य गोष्ट डेटा नाही, परंतु अनुप्रयोग त्याच्यासह कसे कार्य करणार आहे. जर त्याला भिन्न डेटा वेगवेगळ्या मार्गांनी किंवा समान डेटा वेगवेगळ्या प्रकारे प्राप्त करण्याची आवश्यकता असेल, तर आम्ही तो अनुप्रयोगासाठी सोयीस्कर पद्धतीने ठेवला पाहिजे. अन्यथा, आम्ही पूर्ण स्कॅनमध्ये अयशस्वी होऊ आणि Cassandra आम्हाला कोणताही फायदा देणार नाही.

डेटाचे सामान्यीकरण करणे हे सर्वसामान्य प्रमाण आहे. आम्ही सामान्य फॉर्म विसरतो, आमच्याकडे यापुढे रिलेशनल डेटाबेस नाहीत. जर आपण एखादी गोष्ट 100 वेळा खाली ठेवली तर ती 100 वेळा पडेल. हे थांबण्यापेक्षा अजूनही स्वस्त आहे.

आम्ही विभाजनासाठी की निवडतो जेणेकरून ते सामान्यपणे वितरित केले जातील. आमच्या चाव्यांचा हॅश एका अरुंद श्रेणीत येऊ नये असे आम्हाला वाटते. म्हणजेच वरील उदाहरणातील जन्म वर्ष हे वाईट उदाहरण आहे. अधिक तंतोतंत, आमचे वापरकर्ते सामान्यतः जन्माच्या वर्षानुसार वितरीत केले असल्यास ते चांगले आहे आणि जर आम्ही 5 व्या वर्गाच्या विद्यार्थ्यांबद्दल बोलत असाल तर ते वाईट आहे - तेथील विभाजन फार चांगले होणार नाही.

क्लस्टरिंग की निर्मिती स्टेजवर एकदा क्रमवारी निवडली जाते. जर ते बदलायचे असेल तर, आम्हाला आमची टेबल वेगळ्या कीसह अपडेट करावी लागेल.

आणि सर्वात महत्वाची गोष्ट: जर आपल्याला समान डेटा 100 वेगवेगळ्या प्रकारे पुनर्प्राप्त करायचा असेल तर आपल्याकडे 100 भिन्न टेबल्स असतील.

स्त्रोत: www.habr.com