HBase का उपयोग करने का सिद्धांत और अभ्यास

शुभ दोपहर मेरा नाम Danil Lipova है, Sbertech में हमारी टीम ने संचालन डेटा के भंडार के रूप में HBase का उपयोग करना शुरू किया। उनके अध्ययन के दौरान, अनुभव प्राप्त हुआ कि मैं व्यवस्थित और वर्णन करना चाहता था (हम आशा करते हैं कि यह कई लोगों के लिए उपयोगी होगा)। नीचे दिए गए सभी प्रयोग HBase 1.2.0-cdh5.14.2 और 2.0.0-cdh6.0.0-beta1 के संस्करणों के साथ किए गए थे।

1. सामान्य वास्तुकला
2. HBASE डेटा लिखना
3. HBASE से डेटा पढ़ना
4. डेटा कैशिंग
5. बैच प्रसंस्करण मल्टीगेट / मल्टीपूट
6. क्षेत्रों में टेबल तोड़ने के लिए रणनीति (स्पिलिंग)
7. दोष सहिष्णुता, जमाव और डेटा इलाके
8. सेटिंग्स और प्रदर्शन
9. लोड परीक्षण
10. निष्कर्ष

1. सामान्य वास्तुकला

स्टैंडबाय मास्टर चिड़ियाघर कीपर नोड पर सक्रिय दिल की धड़कन सुनता है और गायब होने की स्थिति में, मास्टर के कार्यों को संभालता है।

2. HBASE को डेटा लिखना

सबसे पहले, सबसे सरल मामले पर विचार करें - पुट (रोकी) का उपयोग करके एक निश्चित तालिका में एक कुंजी-मूल्य ऑब्जेक्ट लिखना। क्लाइंट को पहले पता लगाना होगा कि hbase: मेटा टेबल स्थित रूट एरिया सर्वर (RRS) कहां स्थित है। उसे यह जानकारी चिड़ियाघर कीपर से मिली। फिर वह RRS की ओर मुड़ता है और hbase: meta table पढ़ता है, जिसमें से वह उस सूचना को पुनः प्राप्त करता है जो कि रीजन्स सेवर (RS) के लिए ब्याज की तालिका में दिए गए उपद्रवी के लिए डेटा संग्रहीत करने के लिए जिम्मेदार है। भविष्य के उपयोग के लिए, मेटा तालिका क्लाइंट द्वारा कैश की जाती है और इसलिए बाद में कॉल तेजी से, सीधे आरएस पर जाती हैं।

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

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


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

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

ऊपर वर्णित बूट प्रक्रिया के अलावा, एक बहुत अधिक कुशल प्रक्रिया है, जो संभवत: इस डेटाबेस का सबसे शक्तिशाली पक्ष है - थोकलड। यह इस तथ्य में शामिल है कि हम स्वतंत्र रूप से एचफाइल्स बनाते हैं और इसे डिस्क पर डालते हैं, जो हमें पूरी तरह से स्केल करने और बहुत ही सभ्य गति प्राप्त करने की अनुमति देता है। वास्तव में, यहां सीमा HBase नहीं है, लेकिन लोहे की संभावनाएं हैं। नीचे 16 क्लस्टर क्षेत्र और 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 थ्रेड), संस्करण HBase 1.2.0-cdh5.14.2 से मिलकर क्लस्टर पर लोड करने के परिणाम हैं।



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

आप एक ही समय में दो तालिकाओं में लोड करना भी शुरू कर सकते हैं और गति को दोगुना कर सकते हैं। यह नीचे देखा जा सकता है कि 10 केबी ब्लॉक को लगभग 600 एमबी / एस प्रत्येक (कुल 1275 एमबी / एस) की गति से एक बार में दो टेबल पर लिखा जाता है, जो 623 एमबी / एस से एक टेबल पर लिखने की गति के साथ मेल खाता है (ऊपर नंबर 11 देखें)


लेकिन 50 केबी के रिकॉर्ड के साथ दूसरे लॉन्च से पता चलता है कि डाउनलोड की गति पहले से ही थोड़ी बढ़ रही है, जो सीमा मूल्यों के एक अनुमान को इंगित करता है। यह ध्यान में रखा जाना चाहिए कि HBASE पर व्यावहारिक रूप से कोई भार नहीं है, इसके लिए आवश्यक सभी चीज़ों को पहले hbase से डेटा देना है: मेटा, और HFiles को लिंच करने के बाद, BlockCache डेटा को फ्लश करें और यदि यह नहीं है तो डिस्क पर MemStore बफर को सहेजें खाली करें।

3. HBASE से डेटा पढ़ना

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


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

4. डाटा कैशिंग

MemStore और BlockCache बफ़र आवंटित ऑन-हेल RS स्मृति के 80% तक का कब्जा है (बाकी RS सेवा कार्यों के लिए आरक्षित है)। यदि विशिष्ट उपयोग मोड ऐसा है, जो प्रक्रियाएं लिखता है और तुरंत एक ही डेटा पढ़ता है, तो यह ब्लॉकचैच को कम करने और मेमोरी को बढ़ाने के लिए समझ में आता है, क्योंकि जब रीड कैश में डेटा लिखना बंद नहीं होता है, तो ब्लॉकचैच का उपयोग कम बार होगा। ब्लॉकचैच बफर में दो भाग होते हैं: LruBlockCache (हमेशा ऑन-हीप) और बकेटकैचे (आमतौर पर ऑफ-हीप या एसएसडी पर)। बहुत सारे रीड रिक्वेस्ट होने पर बकेट कैचे का इस्तेमाल किया जाना चाहिए और वे LruBlockCache में फिट नहीं होते हैं, जिससे गारबेज कलेक्टर का सक्रिय काम होता है। उसी समय, आपको रीड कैश का उपयोग करने से प्रदर्शन में क्रांतिकारी वृद्धि की उम्मीद नहीं करनी चाहिए, लेकिन हम धारा 8 में इस पर लौट आएंगे


ब्लॉकचैच पूरे आरएस के लिए एक है, और मेमेस्टोर में प्रत्येक टेबल (प्रत्येक कॉलम परिवार के लिए) के लिए अपना है।

जैसा कि सिद्धांत में वर्णित है, जब डेटा लिखना कैश में नहीं पड़ता है, और वास्तव में, ऐसे पैरामीटर तालिका के लिए CACHE_DATA_ON_WRITE और RS के लिए "कैश डेटा ऑन राइट" गलत पर सेट हैं। हालाँकि, व्यवहार में, यदि आप डेटा को MemStore में लिखते हैं, तो इसे डिस्क पर फ्लश करें (इसे इस तरह से साफ करें), फिर परिणामी फ़ाइल को हटा दें, फिर एक प्राप्त अनुरोध निष्पादित करके हम सफलतापूर्वक डेटा प्राप्त करेंगे। और यहां तक ​​कि अगर आप ब्लॉकचैच को पूरी तरह से अक्षम करते हैं और नए डेटा के साथ तालिका को भरते हैं, तो मेमस्टोर को डिस्क पर ले जाएं, उन्हें हटा दें और दूसरे सत्र से अनुरोध करें, फिर भी वे कहीं से लाए जाएंगे। इसलिए HBase न केवल डेटा, बल्कि रहस्यमय पहेली भी संग्रहीत करता है।

hbase(main):001:0> create 'ns:magic', 'cf' Created table ns:magic Took 1.1533 seconds hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me' Took 0.2610 seconds hbase(main):003:0> flush 'ns:magic' Took 0.6161 seconds hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash hbase(main):002:0> get 'ns:magic', 'key1' cf:c timestamp=1534440690218, value=try_to_delete_me 

पढ़ें पर कैश डेटा गलत पर सेट है। यदि आपके पास कोई विचार है, तो टिप्पणियों में इस पर चर्चा करने के लिए आपका स्वागत है।

5. मल्टीगेट / मल्टीपॉट डेटा की बैच प्रोसेसिंग

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



एक वर्चुअल मशीन, 8 कोर, HBase संस्करण 2.0.0-cdh6.0.0-beta1 पर टेस्ट किए गए।

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


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

6. क्षेत्रों को विभाजित करने की रणनीति (काटना)

चूंकि HBase एक कुंजी-मूल्य संग्रहण है और कुंजी द्वारा विभाजन किया जाता है, इसलिए सभी क्षेत्रों में समान रूप से डेटा साझा करना बेहद महत्वपूर्ण है। उदाहरण के लिए, ऐसी तालिका को तीन भागों में विभाजित करने से डेटा तीन क्षेत्रों में विभाजित हो जाएगा:


ऐसा होता है कि यह एक तीव्र मंदी की ओर जाता है यदि भविष्य में लोड किए गए डेटा जैसे दिखेंगे, उदाहरण के लिए, लंबे मान, जिनमें से अधिकांश एक ही अंक से शुरू होते हैं, उदाहरण के लिए:

1000001
1000002
...
1100003

चूँकि कुंजियाँ बाइट्स की एक सरणी के रूप में संग्रहीत की जाती हैं, इसलिए वे सभी उसी तरह से शुरू होंगी और उसी क्षेत्र # 1 से संबंधित होंगी जो इस श्रेणी की कुंजियाँ संग्रहीत करती हैं। कई विभाजन रणनीति हैं:

HexStringSplit - कुंजी को "00000000" => "FFFFFFFF" श्रेणी में हेक्साडेसिमल एन्कोडिंग के साथ एक स्ट्रिंग में बदल देता है और इसे बाईं ओर शून्य से भरता है।

यूनिफ़ॉर्मप्लिट - एक कुंजी को बाइट सरणी में "00" => "FF" श्रेणी में हेक्साडेसिमल एन्कोडिंग के साथ बदल देता है और इसे दाईं ओर शून्य से भरता है।

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

हैश + रंडी

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

7. दोष सहिष्णुता और डेटा इलाके

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

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

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


परीक्षण 3 डेटानेट और 4 आरएस (सीपीयू एक्सोन ई 5-2680 वी 4 @ 2.40GHz * 64 थ्रेड्स) पर किया गया था। HBase संस्करण 1.2.0-cdh5.14.2

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

इसके अलावा, प्रमुख संघनन मेम्स्टोर की स्थिति को प्रभावित नहीं करता है, इसे डिस्क और कॉम्पैक्ट करने के लिए फ्लश करने के लिए, आपको फ्लश (कनेक्शन .getAdmin) () फ़्लश (TableName.valueOf (tblName)) का उपयोग करने की आवश्यकता है।

8. सेटिंग्स और प्रदर्शन

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

• 10 धागे एक ही समय में एक पंक्ति में 3 बार शुरू किए गए थे (चलो इसे थ्रेड्स का एक ब्लॉक कहते हैं)।
• ब्लॉक में सभी प्रवाह का परिचालन समय औसत था और यह ब्लॉक के संचालन का अंतिम परिणाम था।
• सभी धागे एक ही तालिका के साथ काम करते थे।
• थ्रेड ब्लॉक की प्रत्येक शुरुआत से पहले, एक प्रमुख संघनन निष्पादित किया गया था।
• प्रत्येक ब्लॉक ने निम्न में से केवल एक ऑपरेशन किया:

- रखो
- मिलता है
- ऑनलाइन पाएं

• प्रत्येक ब्लॉक ने अपने ऑपरेशन के 50,000 दोहराव किए।
• ब्लॉक में रिकॉर्ड आकार 100 बाइट्स, 1000 बाइट्स या 10000 बाइट्स (यादृच्छिक) हैं।
• ब्लॉक एक अलग संख्या में अनुरोधित कुंजी (या तो एक कुंजी या 10) के साथ लॉन्च किए गए थे।
• विभिन्न तालिका सेटिंग्स पर ब्लॉक लॉन्च किए गए थे। पैरामीटर बदले गए:

- ब्लॉकचैच = चालू या बंद
- BlockSize = 65 Kb या 16 Kb
- विभाजन = 1, 5 या 30
- MSLAB = चालू या बंद

इस प्रकार, ब्लॉक इस तरह दिखता है:

एक। MSLAB मोड चालू / बंद हो गया।
ख। एक तालिका बनाई गई थी जिसके लिए निम्नलिखित पैरामीटर निर्धारित किए गए थे: ब्लॉकचैच = सच / कोई नहीं, ब्लॉकसाइज = 65/16 Kb, विभाजन = 1/5/30।
सी। संपीड़न GZ सेट करें।
घ। 10 थ्रेड्स एक साथ लॉन्च किए गए थे, इस तालिका में 100/1000/10000 बाइट्स के रिकॉर्ड के साथ पुट / गेट / गेट + ऑपरेशन किया गया, जिसमें एक पंक्ति में 50,000 प्रश्नों को निष्पादित किया गया (रैंडम कीज़)।
ई। प्वाइंट डी को तीन बार दोहराया गया था।
च। सभी थ्रेड्स का ऑपरेटिंग समय औसत था।

सभी संभावित संयोजनों की जाँच की गई। यह अनुमान लगाने योग्य है कि जैसे ही रिकॉर्डिंग आकार बढ़ता है, गति कम हो जाएगी या अक्षम कैशिंग धीमा हो जाएगा। हालांकि, लक्ष्य प्रत्येक पैरामीटर के प्रभाव की डिग्री और महत्व को समझना था, इसलिए, एकत्रित डेटा को रेखीय प्रतिगमन फ़ंक्शन के इनपुट को खिलाया गया था, जो टी-सांख्यिकी का उपयोग करके विश्वसनीयता का मूल्यांकन करना संभव बनाता है। नीचे पुट ऑपरेशन करने वाले ब्लॉकों के परिणाम हैं। संयोजनों का एक पूरा सेट 2 * 2 * 3 * 2 * 3 = 144 विकल्प + 72 के बाद से कुछ दो बार किए गए। इसलिए, कुल 216 लॉन्च:


परीक्षण 3 DataNode और 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 धाराओं) वाले एक मिनी-क्लस्टर पर किया गया था। HBase संस्करण 1.2.0-cdh5.14.2।

MSLAB मोड बंद होने पर 3.7 सेकंड की उच्चतम प्रविष्टि गति प्राप्त की गई थी, एक विभाजन पर एक तालिका के साथ, BlockCache सक्षम, BlockSize = 16, प्रति पैक 10 टुकड़ों के 100 बाइट्स के रिकॉर्ड।
MSLAB मोड सक्षम होने पर, एक विभाजन के साथ एक तालिका पर, 82.8 सेकंड की सबसे कम प्रविष्टि गति प्राप्त की गई थी, जिसमें ब्लॉकचेक सक्षम, ब्लॉकसाइज़ = 16, 10,000 बाइट्स के रिकॉर्ड प्रत्येक।

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


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


अब आइए गेट ब्लॉक के निष्पादन के परिणामों का मूल्यांकन करें:


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


ठीक है, अंत में, उस ब्लॉक के मॉडल को देखें जिसे पहले निष्पादित किया गया था, और फिर डाल दिया गया:


यहां सभी पैरामीटर महत्वपूर्ण हैं। और नेताओं के परिणाम:

9. लोड परीक्षण

ठीक है, अंत में, हम एक कम या ज्यादा सभ्य लोड लॉन्च करेंगे, लेकिन यह हमेशा अधिक दिलचस्प होता है जब तुलना करने के लिए कुछ होता है। कैसेंड्रा के एक प्रमुख डेवलपर, डाटास्टैक्स की साइट में कई एनएसक्यूएल रिपॉजिटरी के NT के परिणाम हैं , जिनमें HBase संस्करण 0.98.6-1 शामिल है। लोड हो रहा था 40 धाराओं, डेटा आकार 100 बाइट्स, एसएसडी डिस्क द्वारा किया गया। रीड-मॉडिफाई-राइट ऑपरेशन के परीक्षण के परिणाम ने ये परिणाम दिखाए।


जैसा कि मैंने इसे समझा, 100 रिकॉर्ड्स के ब्लॉक में रीडिंग की गई और 16 HBase नोड्स के लिए, DataStax टेस्ट में प्रति सेकंड 10 हजार ऑपरेशन का प्रदर्शन दिखाया गया।

यह भाग्यशाली है कि हमारे क्लस्टर में 16 नोड्स हैं, लेकिन बहुत "भाग्यशाली" नहीं है कि प्रत्येक में 64 कोर (थ्रेड्स) हैं, जबकि डेटास्टैक्स परीक्षण में केवल 4 हैं। दूसरी तरफ, उनके पास एसएसडी डिस्क हैं, और हमारे पास एचडीडी और बहुत कुछ है। व्यावहारिक रूप से लोड के दौरान HBase और CPU उपयोग के नए संस्करण में उल्लेखनीय रूप से वृद्धि नहीं हुई (नेत्रहीन 5-10 प्रतिशत)। फिर भी, हम इस कॉन्फ़िगरेशन पर शुरू करने का प्रयास करेंगे। डिफ़ॉल्ट रूप से तालिका सेटिंग, रीडिंग 0 से 50 मिलियन तक की रैंडमली (यानी, वास्तव में हर बार एक नया) की एक श्रेणी में की जाती है। तालिका में, 50 मिलियन प्रविष्टियों को 64 विभाजन में विभाजित किया गया है। कुंजी crc32 हैशेड हैं। तालिका सेटिंग्स डिफ़ॉल्ट हैं, MSLAB सक्षम है। 40 धागे शुरू करते हुए, प्रत्येक धागा 100 यादृच्छिक कुंजी का एक सेट पढ़ता है और तुरंत इन कुंजियों पर उत्पन्न 100 बाइट्स लिखता है।


स्टैंड: 16 डेटानॉड और 16 आरएस (सीपीयू एक्सोन ई 5-2680 वी 4 @ 2.40GHz * 64 स्ट्रीम)। HBase संस्करण 1.2.0-cdh5.14.2।

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


स्टैंड: 16 डेटानॉड और 16 आरएस (सीपीयू एक्सोन ई 5-2680 वी 4 @ 2.40GHz * 64 स्ट्रीम)। HBase संस्करण 1.2.0-cdh5.14.2।

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

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


स्टैंड: 16 डेटानॉड और 16 आरएस (सीपीयू एक्सोन ई 5-2680 वी 4 @ 2.40GHz * 64 स्ट्रीम)। HBase संस्करण 1.2.0-cdh5.14.2।

10. निष्कर्ष

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

यदि आपकी राय में कुछ का पर्याप्त रूप से खुलासा नहीं किया गया है, तो मैं और अधिक विस्तार से बताने के लिए तैयार हूं। यदि आप किसी बात से असहमत हैं तो हम आपके अनुभव को साझा करने या बहस करने का सुझाव देते हैं।