NoSQL का लागि डाटा मोडेल डिजाइन गर्ने सुविधाहरू

परिचय

"तपाईले आफ्नो ठाउँमा रहन सकेसम्म छिटो दौडनु पर्छ,
र कतै पुग्न, तपाईले कम्तिमा दोब्बर छिटो दौडनु पर्छ! ”
(c) एलिस इन वन्डरल्याण्ड

केही समयअघि मलाई व्याख्यान दिन भनियो विश्लेषकहरू हाम्रो कम्पनी डाटा मोडेलहरू डिजाइन गर्ने विषयमा, किनभने लामो समयसम्म परियोजनाहरूमा बसेर (कहिलेकाँही धेरै वर्षहरू) हामी आईटी टेक्नोलोजीहरूको संसारमा हाम्रो वरिपरि के भइरहेको छ भन्ने कुरालाई गुमाउँछौं। हाम्रो कम्पनीमा (यो त्यस्तै हुन्छ) धेरै परियोजनाहरूले NoSQL डाटाबेसहरू प्रयोग गर्दैनन् (कम्तीमा अहिलेको लागि), त्यसैले मेरो व्याख्यानमा मैले HBase को उदाहरण प्रयोग गरेर उनीहरूलाई छुट्टै ध्यान दिएँ र सामग्रीको प्रस्तुतीकरणलाई अभिमुख गर्ने प्रयास गरें। जसले कहिल्यै प्रयोग नगरेको काम गरेको छ। विशेष गरी, मैले धेरै वर्ष अघि पढेको उदाहरण प्रयोग गरेर डाटा मोडेल डिजाइनका केही सुविधाहरू चित्रण गरें अमनदीप खुराना द्वारा "HB ase स्कीमा डिजाइनको परिचय" लेखमा। उदाहरणहरूको विश्लेषण गर्दा, मैले मुख्य विचारहरू दर्शकहरूलाई राम्रोसँग व्यक्त गर्नको लागि उही समस्या समाधान गर्न धेरै विकल्पहरू तुलना गरें।

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

उदाहरण विश्लेषण

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

निम्न "सिंथेटिक" समस्यालाई विचार गरौं, जसको साथ हामी काम गर्न जारी राख्नेछौं:

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

• प्रयोगकर्ता A ले प्रयोगकर्ता B (पढ्ने ढाँचा) पढ्छ कि छैन भन्ने प्रश्नको उत्तर दिनुहोस्
• प्रयोगकर्ता B (डेटा परिवर्तन टेम्प्लेट) बाट प्रयोगकर्ता A को सदस्यता/सदस्यता रद्दको अवस्थामा जडानहरू थप्न/हटाउने अनुमति दिनुहोस्।

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

USER_ID
मित्र_आईडी

Vasya
पत्रुस

Vasya
ओलाला

यसपछि, स्पष्टता र राम्रो बुझ्नको लागि, म ID को सट्टा नामहरू संकेत गर्नेछु

HBase को मामला मा, हामीलाई थाहा छ कि:

• पूर्ण तालिका स्क्यानमा नतिजा नहुने प्रभावकारी खोज सम्भव छ विशेष रूपमा कुञ्जी द्वारा
  • वास्तवमा, त्यसकारण त्यस्ता डाटाबेसहरूमा धेरैलाई परिचित SQL प्रश्नहरू लेख्नु नराम्रो विचार हो; प्राविधिक रूपमा, अवश्य पनि, तपाईले समान इम्पालाबाट HBase मा Joins र अन्य तर्कको साथ SQL क्वेरी पठाउन सक्नुहुन्छ, तर यो कत्तिको प्रभावकारी हुनेछ ...

त्यसकारण, हामी प्रयोगकर्ता आईडीलाई कुञ्जीको रूपमा प्रयोग गर्न बाध्य छौं। र मेरो पहिलो विचार "कहाँ र कसरी साथीहरूको आईडी भण्डार गर्ने?" सायद तिनीहरूलाई स्तम्भहरूमा भण्डारण गर्ने विचार। यो सब भन्दा स्पष्ट र "भोली" विकल्प यो जस्तो देखिन्छ (यसलाई कल गरौं विकल्प १ (पूर्वनिर्धारित)थप सन्दर्भको लागि):

RowKey
स्तम्भ

Vasya
१: पेटिया
२: ओल्या
३: दशा

पत्रुस
१: माशा
२: वस्य

यहाँ, प्रत्येक रेखा एक नेटवर्क प्रयोगकर्तासँग मेल खान्छ। स्तम्भहरूको नामहरू छन्: 1, 2, ... - साथीहरूको संख्या अनुसार, र साथीहरूको ID स्तम्भहरूमा भण्डार गरिएको छ। यो नोट गर्न महत्त्वपूर्ण छ कि प्रत्येक पङ्क्तिमा स्तम्भहरूको फरक संख्या हुनेछ। माथिको चित्रको उदाहरणमा, एउटा पङ्क्तिमा तीनवटा स्तम्भहरू छन् (1, 2 र 3), र दोस्रोमा मात्र दुई (1 र 2) छन् - यहाँ हामीले आफैंले दुईवटा HBase गुणहरू प्रयोग गर्यौं जुन रिलेशनल डाटाबेसमा छैन:

• गतिशील रूपमा स्तम्भहरूको संरचना परिवर्तन गर्ने क्षमता (एक साथी थप्नुहोस् -> स्तम्भ थप्नुहोस्, साथी हटाउनुहोस् -> स्तम्भ मेटाउनुहोस्)
• विभिन्न पङ्क्तिहरूमा फरक स्तम्भ रचनाहरू हुन सक्छन्

कार्यको आवश्यकताहरूसँग अनुपालनको लागि हाम्रो संरचना जाँच गरौं:

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

अब यी एल्गोरिदमहरू कत्तिको उत्पादकत्वको मूल्याङ्कन गरौं, जुन हामीले "सशर्त अनुप्रयोग" पक्षमा लागू गर्न आवश्यक हुनेछ, प्रयोग गरेर। O- प्रतीकवाद। हाम्रो काल्पनिक सामाजिक नेटवर्कको आकारलाई n को रूपमा बुझौं। त्यसोभए एक प्रयोगकर्ताले राख्न सक्ने साथीहरूको अधिकतम संख्या (n-1) हो। हामी यसलाई (-१) हाम्रो उद्देश्यका लागि बेवास्ता गर्न सक्छौं, किनकि O-प्रतीकहरूको प्रयोगको ढाँचा भित्र यो महत्वहीन छ।

• डाटा पढ्दै: यो सम्पूर्ण रेखा घटाउन आवश्यक छ र यसको सबै स्तम्भहरू सीमामा दोहोर्याउनुहोस्। यसको मतलब लागतको माथिल्लो अनुमान लगभग O(n) हुनेछ।
• डेटा सम्पादन गर्दै: साथी थप्दै: साथीहरूको संख्या निर्धारण गर्न, तपाईंले पङ्क्तिको सबै स्तम्भहरू मार्फत पुनरावृत्ति गर्न आवश्यक छ, र त्यसपछि नयाँ स्तम्भ => O(n) सम्मिलित गर्नुहोस्।
• डाटा परिवर्तन गर्दै: साथी मेटाउँदै:
  • थप्ने जस्तै - तपाईंले सीमा => O(n) मा सबै स्तम्भहरू मार्फत जानु पर्छ।
  • स्तम्भहरू हटाइसकेपछि, हामीले तिनीहरूलाई "सार्नु" आवश्यक छ। यदि तपाईंले यो "हेड-अन" लागू गर्नुभयो भने, त्यसपछि सीमामा तपाईंलाई (n-1) अपरेशनहरू आवश्यक पर्नेछ। तर यहाँ र अगाडि व्यावहारिक भागमा हामी एक फरक दृष्टिकोण प्रयोग गर्नेछौं, जसले निश्चित संख्याको अपरेशनहरूको लागि "स्यूडो-शिफ्ट" लागू गर्नेछ - अर्थात्, n को परवाह नगरी, यसमा निरन्तर समय खर्च गरिनेछ। यो स्थिर समय (O(2) सटीक हुन) O(n) को तुलनामा बेवास्ता गर्न सकिन्छ। दृष्टिकोण तलको चित्रमा चित्रण गरिएको छ: हामी केवल "अन्तिम" स्तम्भबाट डाटा प्रतिलिपि गर्छौं जसबाट हामी डाटा मेटाउन चाहन्छौं, र त्यसपछि अन्तिम स्तम्भ मेटाउनुहोस्:
    

कुल मिलाएर, सबै परिदृश्यहरूमा हामीले O(n) को एसिम्प्टोटिक कम्प्युटेशनल जटिलता प्राप्त गर्यौं।
तपाईंले सायद पहिले नै याद गर्नुभएको छ कि हामीले लगभग सधैं डाटाबेसबाट सम्पूर्ण पङ्क्ति पढ्नु पर्छ, र तीन मध्ये दुई अवस्थामा, केवल सबै स्तम्भहरू मार्फत जान र साथीहरूको कुल संख्या गणना गर्न। त्यसकारण, अप्टिमाइजेसनको प्रयासको रूपमा, तपाइँ "गणना" स्तम्भ थप्न सक्नुहुन्छ, जसले प्रत्येक नेटवर्क प्रयोगकर्ताका साथीहरूको कुल सङ्ख्या भण्डार गर्दछ। यस अवस्थामा, हामी साथीहरूको कुल संख्या गणना गर्न सम्पूर्ण पङ्क्ति पढ्न सक्दैनौं, तर केवल एउटा "गणना" स्तम्भ पढ्न सक्छौं। मुख्य कुरा डाटा हेरफेर गर्दा "गणना" अद्यावधिक गर्न बिर्सनु हुँदैन। त्यो। हामी सुधार गर्छौं विकल्प २ (गणना):

RowKey
स्तम्भ

Vasya
१: पेटिया
२: ओल्या
३: दशा
गणना: 3

पत्रुस
१: माशा
२: वस्य

गणना: 2

पहिलो विकल्पको तुलनामा:

• डाटा पढ्दै: प्रश्नको जवाफ प्राप्त गर्न "के Vasya ओल्या पढ्छ?" केहि परिवर्तन भएको छैन => O(n)
• डेटा सम्पादन गर्दै: साथी थप्दै: हामीले नयाँ साथीको प्रविष्टिलाई सरलीकृत गरेका छौं, किनकि अब हामीले सम्पूर्ण लाइन पढ्न र यसको स्तम्भहरूमा दोहोर्याउनु पर्दैन, तर "गणना" स्तम्भ, इत्यादिको मान मात्र प्राप्त गर्न सक्छौं। तुरुन्तै नयाँ साथी सम्मिलित गर्न स्तम्भ नम्बर निर्धारण गर्नुहोस्। यसले O(1) मा कम्प्युटेसनल जटिलतामा कमी ल्याउँछ।
• डाटा परिवर्तन गर्दै: साथी मेटाउँदै: साथीलाई मेटाउँदा, हामी यो स्तम्भलाई I/O अपरेसनहरूको संख्या घटाउनको लागि पनि प्रयोग गर्न सक्छौं जब डेटा एक सेललाई बायाँतिर "सफर" गर्छौं। तर मेटाउन आवश्यक भएको फेला पार्न स्तम्भहरू मार्फत पुनरावृत्ति गर्न आवश्यक छ, त्यसैले => O(n)
• अर्कोतर्फ, अब डाटा अपडेट गर्दा हामीले प्रत्येक पटक "गणना" स्तम्भ अद्यावधिक गर्न आवश्यक छ, तर यसले निरन्तर समय लिन्छ, जुन O-प्रतीकहरूको फ्रेमवर्क भित्र बेवास्ता गर्न सकिन्छ।

सामान्यतया, विकल्प 2 अलि बढी इष्टतम देखिन्छ, तर यो "क्रान्तिको सट्टा विकास" जस्तै छ। "क्रान्ति" गर्न हामीलाई चाहिन्छ विकल्प ३ (col).
सबै कुरा "उल्टो" मा बदलौं: हामी असाइन गर्नेछौं स्तम्भ नाम प्रयोगकर्ता आईडी! स्तम्भमा के लेखिनेछ त्यो अब हाम्रो लागि महत्त्वपूर्ण छैन, यसलाई नम्बर 1 हुन दिनुहोस् (सामान्यतया, उपयोगी चीजहरू त्यहाँ भण्डारण गर्न सकिन्छ, उदाहरणका लागि, समूह "परिवार/साथीहरू/आदि।")। यो दृष्टिकोणले अप्रस्तुत "सामान्य मानिस" लाई आश्चर्यचकित पार्न सक्छ जससँग NoSQL डाटाबेसहरूसँग काम गर्ने कुनै अघिल्लो अनुभव छैन, तर यो ठीक यो दृष्टिकोण हो जसले तपाईंलाई यस कार्यमा HBase को सम्भावनालाई अझ प्रभावकारी रूपमा प्रयोग गर्न अनुमति दिन्छ:

RowKey
स्तम्भ

Vasya
पेटी: १
ओल्या: १
दश: १

पत्रुस
माशा: १
वस्य: १

यहाँ हामीले एकैचोटि धेरै फाइदाहरू पाउँछौं। तिनीहरूलाई बुझ्नको लागि, नयाँ संरचनाको विश्लेषण गरौं र कम्प्युटेसनल जटिलता अनुमान गरौं:

• डाटा पढ्दै: वस्याले ओल्याको सदस्यता लिएको छ कि छैन भन्ने प्रश्नको जवाफ दिनको लागि, यो एउटा स्तम्भ "ओल्या" पढ्न पर्याप्त छ: यदि त्यहाँ छ भने, जवाफ सही छ, यदि छैन भने - गलत => O(1)
• डेटा सम्पादन गर्दै: साथी थप्दै: साथी थप्दै: नयाँ स्तम्भ थप्नुहोस् "मित्र ID" => O(1)
• डाटा परिवर्तन गर्दै: साथी मेटाउँदै: केवल मित्र आईडी स्तम्भ हटाउनुहोस् => O(1)

तपाईले देख्न सक्नुहुने रूपमा, यस भण्डारण मोडेलको महत्त्वपूर्ण फाइदा यो हो कि हामीलाई चाहिने सबै परिदृश्यहरूमा, हामी डाटाबेसबाट सम्पूर्ण पङ्क्ति पढ्न बेवास्ता गर्दै र यस पङ्क्तिका सबै स्तम्भहरू गणना गर्दै, केवल एउटा स्तम्भमा काम गर्छौं। हामी त्यहाँ रोक्न सक्छौं, तर ...

तपाईं अन्योलमा पर्न सक्नुहुन्छ र डाटाबेस पहुँच गर्दा प्रदर्शन अनुकूलन र I/O अपरेसनहरू कम गर्ने बाटोमा अलि अगाडि जान सक्नुहुन्छ। के हुन्छ यदि हामीले पूर्ण सम्बन्ध जानकारी सिधै पङ्क्ति कुञ्जीमा भण्डार गर्यौं? अर्थात् userID.friendID जस्तै कुञ्जी कम्पोजिट बनाउने? यस अवस्थामा, हामीले रेखाको स्तम्भहरू पनि पढ्नु पर्दैन (विकल्प ४(पङ्क्ति)):

RowKey
स्तम्भ

Vasya.Petya
पेटी: १

वस्या।ओल्या
ओल्या: १

वस्या।दशा
दश: १

पेट्या।माशा
माशा: १

Petya.vasya
वस्य: १

स्पष्ट रूपमा, यस्तो संरचनामा सबै डेटा हेरफेर परिदृश्यहरूको मूल्याङ्कन, अघिल्लो संस्करणमा जस्तै, O(1) हुनेछ। विकल्प 3 सँगको भिन्नता डाटाबेसमा I/O सञ्चालनहरूको दक्षतामा मात्र हुनेछ।

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

RowKey
स्तम्भ

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
पेटी: १

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
ओल्या: १

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
दश: १

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
माशा: १

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
वस्य: १

स्पष्ट रूपमा, हामीले विचार गरिरहेका परिदृश्यहरूमा यस्तो संरचनासँग काम गर्ने एल्गोरिदमिक जटिलता विकल्प 4 को जस्तै हुनेछ - त्यो हो, O(1)।
कुलमा, एक तालिकामा कम्प्युटेसनल जटिलताका हाम्रा सबै अनुमानहरू संक्षेप गरौं:

साथी थप्दै
साथी जाँच गर्दै
साथीलाई हटाउँदै

विकल्प १ (पूर्वनिर्धारित)
ऊ)
ऊ)
ऊ)

विकल्प २ (गणना)
O (१)
ऊ)
ऊ)

विकल्प ३ (स्तम्भ)
O (१)
O (१)
O (१)

विकल्प ४ (पङ्क्ति)
O (१)
O (१)
O (१)

विकल्प ५ (ह्यास)
O (१)
O (१)
O (१)

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

प्रयोगको तयारी

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

• एउटा नयाँ साथी थप्दै
• प्रयोगकर्ता A प्रयोगकर्ता B को साथी हो कि भनेर जाँच गर्दै
• एउटा साथीलाई हटाउँदै

तसर्थ, प्रारम्भिक कथनमा उल्लिखित आवश्यकताहरूलाई ध्यानमा राख्दै, प्रमाणीकरण परिदृश्य निम्न रूपमा देखा पर्दछ:

• डाटा रेकर्डिङ। अनियमित रूपमा आकार n को प्रारम्भिक नेटवर्क उत्पन्न गर्नुहोस्। "वास्तविक संसार" को नजिक जानको लागि, प्रत्येक प्रयोगकर्ताको साथीहरूको संख्या पनि अनियमित चर हो। हाम्रो "सशर्त अनुप्रयोग" ले HBase मा सबै उत्पन्न डाटा लेख्ने समय मापन गर्नुहोस्। त्यसपछि नतिजाको समयलाई थपिएका साथीहरूको कुल संख्याले विभाजन गर्नुहोस् - यसरी हामीले एउटा "व्यवसाय सञ्चालन" को लागि औसत समय पाउँछौं।
• डाटा पढ्दै। प्रत्येक प्रयोगकर्ताको लागि, "व्यक्तित्वहरू" को सूची सिर्जना गर्नुहोस् जसको लागि तपाईंले प्रयोगकर्तालाई सदस्यता लिएको छ वा छैन भनेर जवाफ प्राप्त गर्न आवश्यक छ। सूचीको लम्बाइ = लगभग प्रयोगकर्ताका साथीहरूको संख्या, र जाँच गरिएका साथीहरूको आधाको लागि जवाफ "हो", र अर्को आधाको लागि - "होइन" हुनुपर्छ। चेक यस्तो क्रम मा गरिन्छ कि जवाफ "हो" र "होइन" वैकल्पिक (अर्थात, प्रत्येक दोस्रो केसमा हामीले विकल्प 1 र 2 को लागी लाइन को सबै स्तम्भहरु मा जानु पर्छ)। कुल स्क्रिनिङ समय प्रति विषय औसत स्क्रिनिङ समय प्राप्त गर्न परीक्षण गरिएका साथीहरूको संख्याद्वारा विभाजित गरिन्छ।
• डाटा मेटाउँदै। प्रयोगकर्ताबाट सबै साथीहरू हटाउनुहोस्। यसबाहेक, मेटाउने क्रम अनियमित छ (अर्थात, हामी डेटा रेकर्ड गर्न प्रयोग गरिएको मौलिक सूची "सफल" गर्छौं)। कुल चेक समय प्रति चेक औसत समय प्राप्त गर्न हटाइएका साथीहरूको संख्याले विभाजन गरिन्छ।

परिदृश्यहरू प्रत्येक 5 डेटा मोडेल विकल्पहरू र सामाजिक सञ्जालका विभिन्न आकारहरूको लागि समय कसरी बढ्दै जान्छ भनेर हेर्नको लागि चलाउन आवश्यक छ। एक n भित्र, नेटवर्कमा जडानहरू र जाँच गर्नका लागि प्रयोगकर्ताहरूको सूची, अवश्य पनि, सबै 5 विकल्पहरूको लागि समान हुनुपर्छ।
राम्रो बुझ्नको लागि, तल n= 5 को लागि उत्पन्न डेटाको उदाहरण हो। लिखित "जेनेरेटर" ले उत्पादनको रूपमा तीन आईडी शब्दकोशहरू उत्पादन गर्दछ:

• पहिलो प्रविष्टिको लागि हो
• दोस्रो जाँचको लागि हो
• तेस्रो - मेटाउनको लागि

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

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

यो प्रयोग Windows 10 चलिरहेको ल्यापटपमा गरिएको थियो, जहाँ एउटा डकर कन्टेनरमा HBase चलिरहेको थियो, र अर्कोमा Jupyter Notebook भएको Python चलिरहेको थियो। डकरलाई 2 CPU कोर र 2 GB RAM आवंटित गरिएको थियो। सबै तर्क, दुबै "सशर्त अनुप्रयोग" को अनुकरण र परीक्षण डाटा उत्पन्न गर्न र समय नाप्ने "पाइपिङ" पाइथनमा लेखिएको थियो। पुस्तकालय HBase सँग काम गर्न प्रयोग गरिएको थियो खुशीको आधार, विकल्प 5 को लागि ह्यास (MD5) गणना गर्न - hashlib

एक विशेष ल्यापटपको कम्प्युटिङ पावरलाई ध्यानमा राख्दै, n = 10, 30, … को लागि प्रक्षेपण प्रयोगात्मक रूपमा चयन गरिएको थियो। 170 - जब पूर्ण परीक्षण चक्रको कुल परिचालन समय (सबै n को लागि सबै विकल्पहरूका लागि सबै परिदृश्यहरू) एक चिया पार्टी (औसत 15 मिनेट) को समयमा अझ बढी वा कम व्यावहारिक र उपयुक्त थियो।

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

प्रयोग परिणाम

पहिलो परीक्षण भनेको साथीहरूको सूची भर्न बिताएको समय कसरी परिवर्तन हुन्छ। नतिजा तलको ग्राफमा छ।

विकल्प 3-5, अपेक्षित रूपमा, लगभग स्थिर "व्यवसाय लेनदेन" समय देखाउँदछ, जुन नेटवर्क आकारको वृद्धि र कार्यसम्पादनमा अविभाज्य भिन्नतामा निर्भर हुँदैन।
विकल्प 2 ले पनि स्थिर, तर थोरै नराम्रो कार्यसम्पादन देखाउँछ, विकल्प 2-3 को तुलनामा लगभग 5 पटक। र यसले रमाइलो गर्न सक्दैन, किनकि यो सिद्धान्तसँग सम्बन्धित छ - यस संस्करणमा HBase मा/बाट I/O अपरेशनहरूको संख्या ठ्याक्कै २ गुणा बढी छ। यसले अप्रत्यक्ष प्रमाणको रूपमा सेवा गर्न सक्छ कि हाम्रो परीक्षण बेन्च, सिद्धान्तमा, राम्रो शुद्धता प्रदान गर्दछ।
विकल्प 1 पनि, अपेक्षित रूपमा, सबैभन्दा ढिलो हुन जान्छ र नेटवर्कको आकारमा एकअर्कालाई थप्न खर्च गरिएको समयमा एक रैखिक वृद्धि देखाउँछ।
अब दोस्रो परीक्षाको नतिजा हेरौं।

विकल्पहरू 3-5 फेरि अपेक्षित रूपमा व्यवहार गर्दछ - स्थिर समय, नेटवर्कको आकारबाट स्वतन्त्र। विकल्प 1 र 2 ले नेटवर्क साइज बढ्दै जाँदा र समान कार्यसम्पादन गर्दा समयमा रैखिक वृद्धि देखाउँछन्। यसबाहेक, विकल्प 2 अलि ढिलो हुन जान्छ - स्पष्ट रूपमा थप "गणना" स्तम्भलाई प्रूफरीड र प्रशोधन गर्ने आवश्यकताको कारणले गर्दा, जुन n बढ्दै जाँदा थप ध्यानयोग्य हुन्छ। तर यो तुलनाको शुद्धता अपेक्षाकृत कम भएकोले म अझै पनि कुनै निष्कर्ष निकाल्नबाट जोगाउनेछु। थप रूपमा, यी अनुपातहरू (जुन विकल्प, 1 वा 2, छिटो छ) रनबाट दौडमा परिवर्तन भयो (निर्भरताको प्रकृति कायम राख्दै र "घाँटी र घाँटी जाँदै")।

खैर, अन्तिम ग्राफ हटाउने परीक्षणको परिणाम हो।

फेरि, यहाँ कुनै आश्चर्य छैन। विकल्प 3-5 निरन्तर समयमा हटाउने कार्य गर्दछ।
यसबाहेक, चाखलाग्दो कुरा, विकल्प 4 र 5, अघिल्लो परिदृश्यहरूको विपरीत, विकल्प 3 भन्दा उल्लेखनीय रूपमा अलिकति खराब प्रदर्शन देखाउँदछ। स्पष्ट रूपमा, पङ्क्ति मेटाउने कार्य स्तम्भ मेटाउने कार्य भन्दा महँगो छ, जुन सामान्यतया तार्किक हुन्छ।

विकल्प 1 र 2, अपेक्षित रूपमा, समय मा एक रैखिक वृद्धि प्रदर्शन। एकै समयमा, विकल्प 2 विकल्प 1 भन्दा लगातार ढिलो छ - गणना स्तम्भ "बनाइ राख्न" थप I/O सञ्चालनको कारण।

प्रयोगको सामान्य निष्कर्ष:

• विकल्प 3-5 ले HBase को फाइदा लिँदा अझ बढी दक्षता देखाउँछन्। यसबाहेक, तिनीहरूको कार्यसम्पादन एक-अर्काको सापेक्ष स्थिर रूपमा भिन्न हुन्छ र नेटवर्कको आकारमा निर्भर हुँदैन।
• विकल्प 4 र 5 बीचको भिन्नता रेकर्ड गरिएको थिएन। तर यसको मतलब यो होइन कि विकल्प 5 प्रयोग गर्नु हुँदैन। यो सम्भव छ कि प्रयोग गरिएको प्रयोगात्मक परिदृश्य, खातामा परीक्षण बेन्चको कार्यसम्पादन विशेषताहरू लिई, यसलाई पत्ता लगाउन अनुमति दिएन।
• डेटाको साथ "व्यवसाय सञ्चालन" गर्न आवश्यक समयको वृद्धिको प्रकृतिले सामान्यतया सबै विकल्पहरूको लागि पहिले प्राप्त गरेको सैद्धान्तिक गणनाहरू पुष्टि गर्दछ।

Epilogue

गरिएका नराम्रा प्रयोगहरूलाई पूर्ण सत्यको रूपमा लिनु हुँदैन। त्यहाँ धेरै कारकहरू छन् जुन खातामा लिइएन र परिणामहरू विकृत गरियो (यी उतार-चढ़ावहरू विशेष गरी सानो नेटवर्क साइजको साथ ग्राफहरूमा देखिन्छन्)। उदाहरणका लागि, thrift को गति, जो Happybase द्वारा प्रयोग गरिन्छ, भोल्युम र तर्क लागू गर्ने विधि जुन मैले पाइथनमा लेखेको छु (म यो दाबी गर्न सक्दिन कि कोड इष्टतम र प्रभावकारी रूपमा सबै कम्पोनेन्टहरूको क्षमताहरू प्रयोग गरी लेखिएको थियो), सायद। HBase क्यासिङका सुविधाहरू, मेरो ल्यापटपमा Windows 10 को पृष्ठभूमि गतिविधि, आदि। सामान्यतया, हामी मान्न सक्छौं कि सबै सैद्धान्तिक गणनाहरूले प्रयोगात्मक रूपमा तिनीहरूको वैधता प्रदर्शन गरेको छ। ठीक छ, वा कम्तिमा यस्तो "हेड-अन आक्रमण" द्वारा तिनीहरूलाई खण्डन गर्न सम्भव थिएन।

अन्तमा, HBase मा डाटा मोडेलहरू डिजाइन गर्न सुरु गर्ने सबैका लागि सिफारिसहरू: रिलेसनल डाटाबेसहरूसँग काम गर्ने अघिल्लो अनुभवबाट सार र "आदेशहरू" सम्झनुहोस्:

• डिजाइन गर्दा, हामी डाटा हेरफेरको कार्य र ढाँचाबाट अगाडि बढ्छौं, डोमेन मोडेलबाट होइन
• कुशल पहुँच (पूर्ण तालिका स्क्यान बिना) - केवल कुञ्जी द्वारा
• विकृतिकरण
• विभिन्न पङ्क्तिहरूमा फरक स्तम्भहरू हुन सक्छन्
• स्पिकरहरूको गतिशील संरचना

स्रोत: www.habr.com