🥇 क्यासान्ड्रा। Oracle थाहा भएमा कसरी मर्नु हुँदैन

हेर Habr.

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

क्यासान्ड्राको बारेमा के राम्रो छ? यो एक NoSQL डाटाबेस हो जुन असफलताको एकल बिन्दु बिना डिजाइन गरिएको हो जुन राम्रो मापन गर्दछ। यदि तपाइँ केहि डाटाबेसको लागि केहि टेराबाइटहरू थप्न आवश्यक छ भने, तपाइँ केवल रिंगमा नोडहरू थप्नुहोस्। यसलाई अर्को डाटा सेन्टरमा विस्तार गर्ने हो? क्लस्टरमा नोडहरू थप्नुहोस्। प्रशोधित RPS बढाउनुहोस्? क्लस्टरमा नोडहरू थप्नुहोस्। उल्टो दिशामा पनि काम गर्छ ।

उनी अरू केमा राम्रो छिन्? यो धेरै अनुरोधहरू ह्यान्डल गर्ने बारे हो। तर धेरै कति हो? प्रति सेकेन्ड १०, २०, ३०, ४० हजार रिक्वेस्ट धेरै होइन । रेकर्डिङको लागि प्रति सेकेन्ड 10 हजार अनुरोधहरू - पनि। त्यहाँ कम्पनीहरू छन् कि उनीहरूले प्रति सेकेन्ड 20 मिलियन अनुरोधहरू राख्छन्। तिनीहरूले सायद यो विश्वास गर्नुपर्छ।

र सिद्धान्तमा, क्यासान्ड्रासँग सम्बन्धित डेटाबाट एउटा ठूलो भिन्नता छ - यो तिनीहरूसँग समान छैन। र यो सम्झना धेरै महत्त्वपूर्ण छ।

उस्तै देखिने सबै काम उस्तै हुँदैन

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

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

यो किनभने क्यासान्ड्रा एक हाइब्रिड डाटाबेस हो: यसले एकै साथ कुञ्जी मान प्रदान गर्दछ र फराकिलो स्तम्भहरूमा डाटा भण्डारण गर्दछ। जाभा वा कोटलिनमा, यसलाई यसरी वर्णन गर्न सकिन्छ:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

अर्थात्, एउटा नक्सा जसमा क्रमबद्ध नक्सा पनि हुन्छ। यो नक्साको पहिलो कुञ्जी पङ्क्ति कुञ्जी वा विभाजन कुञ्जी हो - विभाजन कुञ्जी। दोस्रो कुञ्जी, जुन पहिले नै क्रमबद्ध गरिएको नक्साको कुञ्जी हो, क्लस्टरिङ कुञ्जी हो।

डाटाबेसको वितरणलाई चित्रण गर्न, तीनवटा नोडहरू कोरौं। अब तपाईंले नोडहरूमा डाटा कसरी विघटन गर्ने भनेर बुझ्न आवश्यक छ। किनकि यदि हामीले सबै कुरालाई एउटैमा क्र्याम गर्छौं (तर, त्यहाँ हजार, दुई हजार, पाँच हुन सक्छ - तपाईलाई मनपर्ने धेरै), यो वास्तवमा वितरणको बारेमा होइन। त्यसकारण, हामीलाई एउटा गणितीय प्रकार्य चाहिन्छ जसले संख्या फर्काउँछ। केवल एउटा संख्या, लामो int जुन केही दायरामा पर्नेछ। र हामीसँग एउटा दायराको लागि जिम्मेवार एउटा नोड हुनेछ, दोस्रोको लागि दोस्रो, 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 मिलियन रेकर्डहरू छन्, त्यसपछि सबै कुरा हाम्रो लागि धेरै राम्रो छैन। किनभने अनुमति दिनुहोस् फिल्टरिङ एउटा निर्देशन हो जसले क्यासान्ड्रालाई यो तालिकाबाट सबै नोडहरू, सबै डाटा केन्द्रहरू (यदि यस क्लस्टरमा धेरै छन् भने) सबै डाटा सङ्कलन गर्न अनुमति दिन्छ, र त्यसपछि मात्र फिल्टर गर्नुहोस्। यो पूर्ण स्क्यान को एक एनालग हो, र सायद कोही यो संग खुशी छ।

यदि हामीलाई ID द्वारा मात्र प्रयोगकर्ताहरू चाहिन्छ भने, हामी यससँग ठीक हुनेछौं। तर कहिलेकाहीँ हामीले अन्य प्रश्नहरू लेख्न र चयनमा अन्य प्रतिबन्धहरू लगाउन आवश्यक छ। त्यसकारण, हामी सम्झन्छौं: यो सबै नक्सा हो जसमा विभाजन कुञ्जी छ, तर यो भित्र क्रमबद्ध नक्सा छ।

र उनीसँग एउटा कुञ्जी पनि छ, जसलाई हामी क्लस्टरिङ कुञ्जी भन्छौँ। यो कुञ्जी, जुन, बारीमा, हामीले चयन गर्ने स्तम्भहरू समावेश गर्दछ, जसको मद्दतले क्यासान्ड्राले बुझ्छ कि कसरी यसको डेटा भौतिक रूपमा क्रमबद्ध छ र प्रत्येक नोडमा अवस्थित हुनेछ। त्यो हो, केही विभाजन कुञ्जीका लागि, क्लस्टरिङ कुञ्जीले तपाईंलाई यो रूखमा डाटा कसरी पुश गर्ने, त्यहाँ कुन ठाउँमा लैजान्छ भन्ने कुरा बताउनेछ।

यो साँच्चै एक रूख हो, एक तुलनाकर्तालाई त्यहाँ भनिन्छ, जसमा हामी वस्तुको रूपमा स्तम्भहरूको निश्चित सेट पास गर्छौं, र यसलाई स्तम्भहरूको सूचीको रूपमा पनि निर्दिष्ट गरिएको छ।

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

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

हामीले क्रमबद्ध र प्रतिबन्धहरू सेट गर्छौं

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

हामीले हाम्रो तालिका प्रयोगकर्ताहरूले भर्यौं र देख्यौं कि तिनीहरू एक औंठीमा परेका थिए, पहिले जन्मको वर्षद्वारा, र त्यसपछि तलब र प्रयोगकर्ता ID द्वारा प्रत्येक नोडमा भित्र। अब हामी प्रतिबन्ध लगाएर चयन गर्न सक्छौं।

हाम्रो काम गर्ने एक फेरि देखा पर्यो where, and, र हामी प्रयोगकर्ताहरू पाउँछौं, र सबै कुरा फेरि ठीक छ। तर यदि हामीले क्लस्टरिङ कुञ्जीको केही अंश मात्र प्रयोग गर्ने प्रयास गर्यौं भने, र कम महत्त्वपूर्ण एक, तब क्यासान्ड्राले तुरुन्तै गुनासो गर्नेछ कि यसले हाम्रो नक्सामा त्यो स्थान फेला पार्न सक्दैन जहाँ यो वस्तु, जसमा शून्य तुलनाकर्ताका लागि यी क्षेत्रहरू छन्, र यो एउटा। त्यो भर्खरै सेट गरिएको थियो, - जहाँ ऊ सुत्छ। मैले यो नोडबाट सबै डाटा पुन: निकाल्नुपर्छ र यसलाई फिल्टर गर्नुपर्छ। र यो नोड भित्र पूर्ण स्क्यान को एक एनालग हो, यो खराब छ।

कुनै पनि अस्पष्ट अवस्थामा, नयाँ तालिका सिर्जना गर्नुहोस्

यदि हामी ID, वा उमेर, वा तलब द्वारा प्रयोगकर्ताहरूलाई लक्षित गर्न सक्षम हुन चाहन्छौं भने, हामीले के गर्नुपर्छ? केही छैन। केवल दुई टेबल प्रयोग गर्नुहोस्। यदि तपाइँ प्रयोगकर्ताहरूलाई तीन फरक तरिकामा पुग्न आवश्यक छ भने, त्यहाँ तीनवटा तालिकाहरू हुनेछन्। ती दिनहरू गए जब हामीले स्क्रूमा ठाउँ बचत गर्यौं। यो सबैभन्दा सस्तो स्रोत हो। यसको लागत प्रतिक्रिया समय भन्दा धेरै कम छ, जुन प्रयोगकर्ताको लागि हानिकारक हुन सक्छ। 10 मिनेटमा भन्दा एक सेकेन्डमा केहि प्राप्त गर्न प्रयोगकर्ताको लागि यो धेरै रमाइलो छ।

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

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

डेटालाई सामान्यीकरण गर्नु सामान्य कुरा हो। हामी सामान्य फारमहरू बिर्सन्छौं, हामीसँग अब रिलेशनल डाटाबेस छैन। यदि हामीले कुनै चीजलाई 100 पटक तल राख्यौं भने, त्यो 100 पटक ढल्छ। यो अझै पनि रोक्न भन्दा सस्तो छ।

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

क्लस्टरिङ कुञ्जी सिर्जना चरणमा क्रमबद्ध एक पटक चयन गरिएको छ। यदि यसलाई परिवर्तन गर्न आवश्यक छ भने, हामीले हाम्रो तालिकालाई फरक कुञ्जीसँग अद्यावधिक गर्नुपर्नेछ।

र सबैभन्दा महत्त्वपूर्ण कुरा: यदि हामीले 100 फरक तरिकामा एउटै डाटा पुन: प्राप्त गर्न आवश्यक छ भने, हामीसँग 100 फरक तालिकाहरू हुनेछन्।

स्रोत: www.habr.com

क्यासान्ड्रा। Oracle मात्र थाहा भएमा कसरी मर्नु हुँदैन

उस्तै देखिने सबै काम उस्तै हुँदैन

चयन गर्नुहोस्: अनुमति दिँदा फिल्टरिङ पूर्ण स्क्यानमा परिणत हुन्छ, वा के नगर्ने

हामीले क्रमबद्ध र प्रतिबन्धहरू सेट गर्छौं

कुनै पनि अस्पष्ट अवस्थामा, नयाँ तालिका सिर्जना गर्नुहोस्

एक टिप्पणी थप्न Отменить ответ