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

नमस्कार, मेरा नाम डैनिल लिपोवॉय है, 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 में डेटा लिखना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

संपूर्ण RS के लिए एक BlockCache है, तथा प्रत्येक तालिका का अपना MemStore (प्रत्येक कॉलम परिवार के लिए एक) है।

जैसा वर्णित सिद्धांत रूप में, जब कैश में डेटा लिखा जाता है, तो यह वहां नहीं पहुंचता है, और वास्तव में, तालिका के लिए CACHE_DATA_ON_WRITE और RS के लिए "Cache DATA on Write" जैसे पैरामीटर गलत पर सेट होते हैं। हालाँकि, व्यवहार में, यदि हम मेमस्टोर में डेटा लिखते हैं, फिर उसे डिस्क पर फ्लश करते हैं (इस प्रकार उसे साफ़ करते हैं), फिर परिणामी फ़ाइल को हटाते हैं, फिर एक गेट अनुरोध निष्पादित करके हम सफलतापूर्वक डेटा प्राप्त कर लेंगे। इसके अलावा, यदि आप BlockCache को पूरी तरह से अक्षम कर देते हैं और तालिका को नए डेटा से भर देते हैं, फिर डिस्क पर 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 रिकॉर्ड पढ़ने में लगने वाला समय दर्शाता है। रीडिंग एक थ्रेड में की गई थी और क्षैतिज अक्ष क्वेरी में कुंजियों की संख्या दर्शाता है। यहां आप देख सकते हैं कि जब एक अनुरोध में एक हजार कुंजियों तक वृद्धि की जाती है, तो निष्पादन समय कम हो जाता है, अर्थात गति बढ़ जाती है। हालाँकि, डिफ़ॉल्ट रूप से सक्षम MSLAB मोड के साथ, इस सीमा के बाद, प्रदर्शन में नाटकीय रूप से गिरावट आने लगती है, और रिकॉर्ड में डेटा की मात्रा जितनी अधिक होती है, रनटाइम उतना ही लंबा होता है।

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

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

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

6. तालिका को क्षेत्रों में विभाजित करने की रणनीति (स्पिलिंग)

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

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

1000001
1000002
...
1100003

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

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

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

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

हैश + रोकी

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

7. दोष सहिष्णुता और डेटा स्थानीयता

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

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

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

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

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

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

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

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

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

- रखना
- पाना
— प्राप्त करें+रखें

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

— ब्लॉककैश = चालू या बंद
— ब्लॉक आकार = 65 KB या 16 KB
— विभाजन = 1, 5 या 30
— MSLAB = सक्षम या अक्षम

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

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

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

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

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

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

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

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

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

खैर, अंत में, आइए उस ब्लॉक के मॉडल को देखें जिसने पहले get और फिर put का प्रदर्शन किया:

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

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

खैर, अंत में, हम कमोबेश एक अच्छा लोड लॉन्च करेंगे, लेकिन जब तुलना करने के लिए कुछ हो तो यह हमेशा अधिक दिलचस्प होता है। कैसांद्रा के प्रमुख डेवलपर डेटास्टैक्स की वेबसाइट पर, निष्कर्ष HBase संस्करण 0.98.6-1 सहित अनेक NoSQL स्टोरेजों का NT. डाउनलोड 40 थ्रेड्स, 100 बाइट्स डेटा आकार, SSD डिस्क में किया गया था। पढ़ें-संशोधित करें-लिखें परिचालनों के परीक्षण के परिणाम निम्नलिखित दर्शाए गए।

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

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

स्टैंड: 16 डेटा नोड्स और 16 आरएस (सीपीयू जिऑन ई5-2680 v4 @ 2.40GHz * 64 थ्रेड्स)। एचबेस संस्करण 1.2.0-cdh5.14.2.

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

स्टैंड: 16 डेटा नोड्स और 16 आरएस (सीपीयू जिऑन ई5-2680 v4 @ 2.40GHz * 64 थ्रेड्स)। एचबेस संस्करण 1.2.0-cdh5.14.2.

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

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

स्टैंड: 16 डेटा नोड्स और 16 आरएस (सीपीयू जिऑन ई5-2680 v4 @ 2.40GHz * 64 थ्रेड्स)। एचबेस संस्करण 1.2.0-cdh5.14.2.

10। निष्कर्ष

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

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

स्रोत: www.habr.com