अपने क्लस्टर पर किसी भी प्रदर्शन बेंचमार्किंग टूल को चलाते समय, एक महत्वपूर्ण निर्णय हमेशा एक प्रदर्शन परीक्षण के लिए डेटा सेट आकार का उपयोग किया जाना चाहिए, और यहां हम प्रदर्शित करते हैं कि HBase प्रदर्शन चलाते समय "अच्छा फिट" डेटा सेट आकार का चयन करना क्यों महत्वपूर्ण है अपने क्लस्टर पर परीक्षण करें।
HBase क्लस्टर कॉन्फ़िगरेशन और डेटा सेट का आकार आपके कार्यभार के प्रदर्शन और उसी क्लस्टर पर परीक्षण के परिणामों को बदल सकता है। आप अपने क्लस्टर के प्रदर्शन के बारे में जो समझने की कोशिश कर रहे हैं, उसके आधार पर आपको यह डेटा सेट आकार चुनना चाहिए। उपलब्ध मेमोरी कैश में फिट होने वाले वर्किंग सेट और अंतर्निहित स्टोरेज से पढ़े जाने वाले वर्किंग सेट के बीच अंतर दिखाने के लिए हमने समान CDP प्राइवेट क्लाउड बेस 7.2.2 ऑपरेशन डेटाबेस क्लस्टर पर उचित रूप से चुने गए डेटा सेट साइज के साथ 2 YCSB वर्कलोड टेस्ट चलाए। हमने 40GB बनाम 1TB के डेटा सेट आकार का उपयोग किया और विभिन्न YCSB वर्कलोड के लिए थ्रूपुट की तुलना नीचे की गई है, चार्ट में बार जितना अधिक होगा, थ्रूपुट उतना ही बेहतर होगा।
नोट:थ्रूपुट =संचालन प्रति सेकंड
जब कोई एप्लिकेशन HBase क्लस्टर से रीड करने का प्रयास करता है, तो रिक्वेस्ट को हैंडल करने वाला रीजन सर्वर पहले जांचता है कि क्या आवश्यक परिणाम डेटा ब्लॉक में हैं जो पहले से ही अपने ब्लॉक कैश के माध्यम से इसकी प्रक्रिया के लिए स्थानीय है। यदि डेटा ब्लॉक मौजूद है तो क्लाइंट अनुरोध को सीधे कैश से सेवित किया जा सकता है और इसे कैश हिट के रूप में गिना जाता है। हालाँकि, यदि ब्लॉक वर्तमान में क्षेत्र सर्वर प्रक्रिया के लिए स्थानीय नहीं है, तो इसे कैश मिस के रूप में गिना जाता है और इसे HDFS स्टोरेज में HFile से पढ़ा जाना चाहिए। कैश उपयोग के आधार पर उस ब्लॉक को भविष्य के अनुरोधों के लिए कैश में सहेजा जाएगा।
जैसा कि अपेक्षित है और सारांश चार्ट में देखा गया है, एक वर्कलोड जहां अधिकांश डेटा सेट कैश में फिट होता है, उसमें लेटेंसी कम होती है और थ्रूपुट बहुत अधिक होता है बनाम वर्कलोड रन जहां डेटा को एचडीएफएस स्टोरेज में एचएफआईएल से एक्सेस किया जा रहा है।
हमारे परीक्षण लक्ष्यों को अच्छी तरह से पूरा करने के लिए हमारे कार्यभार डेटा सेट आकारों को चुनने के लिए, रीजनसर्वर हीप, L1 और L2 कैश, OS बफर कैश के आकार की जांच करना और फिर एक उपयुक्त डेटा सेट आकार सेट करना महत्वपूर्ण है। YCSB वर्कलोड रन ने यह सत्यापित करने के तरीके के रूप में जाँच करने के लिए एक अच्छा पैरामीटर पूरा कर लिया है कि चीजें अपेक्षित रूप से चल रही हैं, कैश (कैश हिट) से कितना डेटा सेवित किया गया था और एचडीएफएस स्टोरेज से कितना एक्सेस किया गया था। रीजन सर्वर कैश हिट का कुल पढ़ने के अनुरोधों का अनुपात कैश हिट अनुपात है।
आप यह जानकारी L1 कैश हिट अनुपात “l1CacheHitRatio” कॉन्फिगरेशन से प्राप्त कर सकते हैं। यदि आपके क्लस्टर में L1 और L2 दोनों कैश सेट हैं, तो L1 कैश इंडेक्स ब्लॉक में कार्य करता है और L2 कैश डेटा ब्लॉक की सेवा करता है, और आप संदर्भ के लिए L1 "l1CacheHitRatio" और L2 "l2CacheHitRatio" दोनों को रिकॉर्ड कर सकते हैं।
इस ब्लॉग पोस्ट का बाकी हिस्सा हमारे परीक्षण सेटअप के विवरण के माध्यम से चलेगा, डेटा सेट आकार का चयन करेगा, और फिर उन डेटा सेट आकारों के साथ YCSB चलाएगा।
इस परीक्षण के लिए उपयोग किया गया HBase क्लस्टर कॉन्फ़िगरेशन:
- इस्तेमाल किया गया क्लस्टर: 6 नोड क्लस्टर (1 मास्टर + 5 क्षेत्र सर्वर)
- विवरण: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2.2Ghz, 128GB Ram, 4-2TB डिस्क
- सुरक्षा: कोई कॉन्फ़िगर नहीं किया गया (कोई केर्बरोस नहीं)
- सीडीपी संस्करण: CDP प्राइवेट क्लाउड बेस 7.2.2 6 नोड HBase क्लस्टर जिसमें 1 मास्टर + 5 रीजन सर्वर हैं
- JDK ने jdk1.8_232 का उपयोग किया
- HBase क्षेत्र के सर्वर 32GB हीप के साथ कॉन्फ़िगर किए गए थे
- HBase मास्टर को 4GB हीप के साथ कॉन्फ़िगर किया गया था
- LruBlockCache के साथ L1 कैश का उपयोग 12.3 GB कैश आकार के साथ किया गया था
- क्लस्टर में कुल L1 कैशे 61 GB (12.3 * 5 =61GB) है
- L2 ऑफ हीप कैश क्लस्टर पर कॉन्फ़िगर नहीं किया गया था
साइज़िंग केस 1:डेटा पूरी तरह से क्लस्टर में उपलब्ध कैश में फ़िट हो जाता है
हमारे HBase क्लस्टर में, हमने L1 ब्लॉक कैश के लिए आवंटित 5 क्षेत्र सर्वरों में कुल 61GB (12.3GB *5) कॉन्फ़िगर किया है। एक डेटा सेट के लिए जो पूरी तरह से कैश में फिट बैठता है, हमने एक डेटा सेट जो 40GB था चुना था आकार में।
साइज़िंग केस 2:क्लस्टर पर उपलब्ध कैश से बड़ा डेटा सेट
दूसरे परिदृश्य के लिए हम चाहते हैं कि डेटा उपलब्ध कैश से बहुत बड़ा हो। उपयुक्त डेटा सेट आकार चुनने के लिए हमने क्लस्टर में कॉन्फ़िगर किए गए HBase ब्लॉक कैश और OS बफर कैश दोनों को देखा। हमारे दिए गए HBase क्लस्टर में कॉन्फ़िगर किया गया L1 ब्लॉक कैश 61G है, जब इसे पूरे क्षेत्र के सर्वरों में एकत्रित किया जाता है। सर्वर नोड्स में कुल 128G RAM था और सर्वर प्रक्रिया के लिए समर्पित कोई भी मेमोरी का उपयोग OS द्वारा अंतर्निहित HDFS ब्लॉक को प्रभावी ढंग से कैश करने और समग्र थ्रूपुट को बढ़ाने के लिए किया जा सकता है। हमारे परीक्षण विन्यास में इस उद्देश्य के लिए प्रत्येक क्षेत्र सर्वर नोड पर लगभग 96G OS कैश उपलब्ध है (चीजों को सरल बनाने के लिए DataNode या OS प्रक्रियाओं द्वारा उपयोग की जाने वाली मेमोरी को अनदेखा करना)। 5 क्षेत्र सर्वरों में इसे एकत्रित करते हुए, हमारे पास बफ़र्स (96G * 5 क्षेत्र सर्वर) के लिए लगभग 500G की क्षमता थी। इस प्रकार हमने 1TB का डेटा सेट आकार चुना, जो कॉन्फ़िगर किए गए ब्लॉक कैश और उपलब्ध OS बफर कैश दोनों से अधिक है।
टारगेट डेटा साइज़ को YCSB पैरामीटर में बदलना
YCSB में, डिफ़ॉल्ट रूप से एक पंक्ति 1KB होती है, इसलिए आप YCSB 'यूजरटेबल' में कितनी पंक्तियों को लोड करते हैं, इसके आधार पर आप आसानी से अपने YCSB 'यूजरटेबल' टेबल डेटा आकार का अनुमान लगा सकते हैं। इसलिए यदि आप 1 मिलियन पंक्तियां अपलोड करते हैं, तो आपने YCSB 'उपयोगकर्ता तालिका' में 1,000,000 * 1KB =1GB डेटा अपलोड किया है।
हमारे दो परीक्षणों के लिए उपयोग किए गए डेटा सेट आकार थे:
- 40 जीबी डेटा 40 मिलियन पंक्तियों के साथ
- 1 टीबी डेटा 1 अरब पंक्तियों के साथ
परीक्षण पद्धति
सीडीपी प्राइवेट क्लाउड बेस 7.2.2 6 नोड क्लस्टर पर स्थापित किया गया था और 40 मिलियन पंक्तियों के साथ वर्कलोड डेटा (कुल डेटा सेट आकार => 40 जीबी) उत्पन्न किया गया था और वाईसीएसबी वर्कलोड चलाया गया था। लोड करने के बाद, हमने वर्कलोड टेस्ट शुरू करने से पहले सभी कॉम्पैक्शन ऑपरेशंस के खत्म होने का इंतजार किया।
YCSB वर्कलोड जो HBase पर चलाए गए थे, वे थे
- कार्यभार A:50% पढ़ें और 50% अपडेट करें
- कार्यभार C:100% पढ़ें
- कार्यभार F:50%पढ़ें और 50% अपडेट/पढ़ें-संशोधित करें-लिखें अनुपात:50/50
- कस्टम अपडेट केवल वर्कलोड:100% अपडेट
प्रत्येक YCSB वर्कलोड (A, C, F और UpdateOnly) प्रत्येक को 15 मिनट के लिए चलाया गया था, और YCSB थ्रूपुट * को मापने के लिए रन के बीच बिना किसी पुनरारंभ के 5 बार पूरा रन दोहराया गया था। दिखाए गए परिणाम 5 रन से अंतिम 3 रन के लिए औसत हैं। पहले और दूसरे रन पेनल्टी से बचने के लिए पहले 2 टेस्ट रन पर ध्यान नहीं दिया गया।
एक बार 40GB रन पूरे हो जाने के बाद, हमने 1TB डेटा सेट आकार बनाने के लिए उपयोगकर्ता योग्य और 1 बिलियन पंक्तियों को फिर से जनरेट किया और उसी क्लस्टर पर समान कार्यप्रणाली के साथ परीक्षणों को फिर से चलाया।
परीक्षा परिणाम
YCSB परिणाम 40GB के साथ
40GB के मामले में डेटा पूरी तरह से क्लस्टर पर 61GB L1 कैश में फिट हो सकता है। परीक्षण के दौरान क्लस्टर में देखा गया L1 कैश हिट अनुपात 99% के करीब था।
युक्ति: छोटे डेटासेट के लिए जहां डेटा कैश में फ़िट हो सकता है, हम कैश ऑन लोड विकल्प का भी उपयोग कर सकते हैं और टेबल विकल्प PREFETCH_BLOCKS_ON_OPEN का उपयोग करके 100% कैश हिट अनुपात प्राप्त करने के लिए कैश को प्री-वार्म कर सकते हैं।
हमने प्रत्येक वाईसीएसबी वर्कलोड को प्रत्येक 5 बार 15 मिनट तक चलाया और पहले रन पेनल्टी से बचने के लिए पिछले 3 रन से औसत लिया।
40G L1 कैश हिट अनुपात 99% . के साथ देखे गए परिणाम क्षेत्र सर्वर पर नीचे तालिका में दिखाया गया है:
| ऑपरेशन | संख्या संचालन | थ्रूपुट | औसत विलंबता | 95 विलंबता | 99 विलंबता |
| (संख्या ऑप्स/सेकंड) | (ms) | (ms) | (ms) | ||
| कार्यभार C | 148558364 | 165063 | 0.24 | 0.30 | 0.48 |
| केवल अपडेट करें | 56727908 | 63030 | 0.63 | 0.78 | 1.57 |
| कार्यभार A | 35745710 | 79439 | 0.40 | 0.54 | 0.66 |
| कार्यभार एफ | 24823285 | 55157 | 0.58 | 0.70 | 0.96 |
YCSB परिणाम 1TB डेटा सेट के साथ
1TB मामले में डेटा क्लस्टर पर 61GB L1 कैश या 500GB OS बफर कैश में फिट नहीं होता है। परीक्षण के दौरान देखे गए क्लस्टर में L1 कैश हिट अनुपात 82-84% था।
हमने प्रत्येक कार्यभार को प्रत्येक 5 बार 15 मिनट तक चलाया, और पहले रन पेनल्टी से बचने के लिए अंतिम 3 रन से औसत लिया।
1TB . के साथ देखे गए परिणाम L1 कैश हिट अनुपात 82-84% क्षेत्र सर्वर पर नीचे तालिका में दिखाया गया है:
| ऑपरेशन | संख्या संचालन | थ्रूपुट | औसत विलंबता | 95 विलंबता | 99 विलंबता |
| (संख्या ऑप्स/सेकंड) | (ms) | (ms) | (ms) | ||
| कार्यभार C | 2727037 | 3030 | 13.19 | 55.50 | 110.85 |
| केवल अपडेट करें | 56345498 | 62605 | 0.64 | 0.78 | 1.58 |
| कार्यभार A | 3085135 | 6855 | 10.88 | 48.34 | 97.70 |
| कार्यभार एफ | 3333982 | 3704 | 10.45 | 47.78 | 98.62 |
*थ्रूपुट (ऑप्स/सेकंड) =संचालन की संख्या प्रति सेकंड
विश्लेषण:
ऊपर दिए गए दो अलग-अलग डेटा सेट आकारों के परीक्षण परिणामों की तुलना करते हुए, हम देख सकते हैं कि कैसे समान कार्यभार थ्रूपुट 3K संचालन प्रति सेकंड से 165K संचालन प्रति सेकंड तक भिन्न हो सकता है। जब डेटा को 40G डेटासेट से वार्म अप कैश बनाम hdfs संग्रहण से अधिक तेज़ी से एक्सेस किया जाता है।
नीचे दिया गया चार्ट थ्रूपुट दिखाता है और तुलना करता है कि 2 अलग-अलग आकार के डेटासेट के साथ चलने पर विभिन्न वर्कलोड के लिए थ्रूपुट कैसे बदल गया। चार्ट में बार जितना ऊंचा होगा, थ्रूपुट उतना ही बेहतर होगा।
नोट:थ्रूपुट =संचालन प्रति सेकंड
जैसा कि चार्ट में देखा गया है, वाईसीएसबी वर्कलोड जो वर्कलोड ए, वर्कलोड सी और वर्कलोड एफ जैसे डेटा को पढ़ता है, 40 जी मामले में बेहतर थ्रूपुट था जहां डेटा आसानी से कैश बनाम 1 टीबी डेटा आकार के मामले में फिट होता है जहां एचएफआईएल डेटा होना था। एचडीएफएस से एक्सेस किया गया
कैश हिट अनुपात को देखते हुए, 40G डेटासेट का कैश हिट अनुपात 99% के करीब था, और 1TB डेटा सेट का कैश हिट अनुपात लगभग 85% था, इसलिए 1TB मामले में 15% डेटा hdfs स्टोरेज से एक्सेस किया गया था। ।
हमारे द्वारा चलाए गए YCSB कस्टम अपडेट-ओनली वर्कलोड में दोनों मामलों में समान थ्रूपुट था क्योंकि इसने केवल अपडेट किया और कोई रीड नहीं किया।
HBase प्रदर्शन के दौरान हम 95वें और 99वें पर्सेंटाइल लेटेंसीज को करीब से देखते हैं। औसत विलंबता केवल कुल थ्रूपुट को कुल समय से विभाजित किया जाता है, हालांकि 95 वाँ प्रतिशतक और 99 वाँ प्रतिशतक वास्तविक आउटलेयर दिखाते हैं जो कुल कार्यभार थ्रूपुट को प्रभावित करते हैं। 1TB मामले में, 95वें और 99वें पर्सेंटाइल में उच्च विलंबता आउटलाइर्स थ्रूपुट को धीमा कर देते हैं, और 40GB मामले में कम लेटेंसी कैश 99वें पर्सेंटाइल लीड में हिट कुल थ्रूपुट में वृद्धि करता है।
नीचे दिया गया चार्ट औसत प्रतीक्षा अवधि, 95वीं शतमक प्रतीक्षा अवधि और 99वीं शतमक प्रतीक्षा अवधि के लिए विलंबता तुलना दिखाता है और यह दिखाता है कि विभिन्न आकार के डेटा सेट के साथ चलाए जाने पर यह विभिन्न कार्यभार के लिए कैसे भिन्न होता है।
उपरोक्त चार्ट में, 40GB डेटा सेट के लिए विलंबता का प्रतिनिधित्व करने वाले बार को देखना कठिन है क्योंकि वे hdfs से डेटा एक्सेस करने वाले 1TB डेटासेट के लिए देखी गई विलंबता की तुलना में बहुत कम हैं।
हमने नीचे दिए गए चार्ट में अंतर दिखाने के लिए लेटेंसी मानों के लॉग का उपयोग करके लेटेंसी ग्राफ़ प्लॉट किया है
जैसा कि ऊपर देखा गया है कि 40GB मामले में विलंबता बहुत कम है जहां कैश हिट अनुपात 99% के करीब है और अधिकांश कार्यभार डेटा कैश में उपलब्ध है। 1TB डेटा सेट की तुलना में, कैश हिट अनुपात लगभग 85% था क्योंकि HFile डेटा को HDFS संग्रहण से एक्सेस किया जाना था।
40जी मामले में वर्कलोड सी के लिए औसत और 99 विलंबता जहां वार्म अप कैश से 99% डेटा लौटाया गया था, लगभग 2 - 4 एमएस था। 1TB मामले में समान कार्यभार C के लिए 99वां प्रतिशत विलंबता कार्यभार C (केवल कार्यभार पढ़ने के लिए) के लिए लगभग 100ms थी।
इससे पता चलता है कि ऑन-हीप ब्लॉक कैश से एक कैश हिट लगभग 2 एमएस में एक रीड देता है और एक कैश मिस और एचडीएफएस से एक रिकॉर्ड प्राप्त करने में इस क्लस्टर पर लगभग 100ms लग सकते हैं।
सिफारिश:
YCSB बेंचमार्किंग परीक्षण चलाते समय डेटा सेट का आकार प्रदर्शन परिणामों में काफी अंतर डालता है, और इसलिए परीक्षण को उचित रूप से आकार देना बहुत महत्वपूर्ण है। साथ ही, कैश हिट अनुपात और न्यूनतम और 99वीं विलंबता के बीच विलंबता अंतर को देखने से आपको कैश-हिट की विलंबता का पता लगाने में मदद मिलेगी, जब क्लस्टर में अंतर्निहित भंडारण से डेटा तक पहुँचा जाता है।
टिप:
किसी क्षेत्र सर्वर पर अपने कार्यभार के कैश हिट अनुपात की जांच के लिए आप नीचे दिए गए आदेश का उपयोग कर सकते हैं
curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio
आप नीचे दिए गए चरणों का पालन करके HBase वेब UI से कैश हिट अनुपात भी देख सकते हैं:
- HBase वेब UI से रीजन सर्वर पर क्लिक करें
- कैश हिट अनुपात की समीक्षा करने के लिए कैश ब्लॉक अनुभाग के अंतर्गत L1 (और L2 यदि L2 कॉन्फ़िगर किया गया है) का चयन करें।
L1 ब्लॉक कैश से कैश हिट अनुपात दिखाने वाला एक स्क्रीनशॉट नीचे दिखाया गया है:
यहां ऊपर दिखाए गए HBase स्क्रीनशॉट के बारे में अधिक जानकारी के लिए एक लिंक है और कैश को ब्लॉक करें https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html
वाईसीएसबी के बारे में
YCSB कंप्यूटर प्रोग्राम की पुनर्प्राप्ति और रखरखाव क्षमताओं के मूल्यांकन के लिए एक ओपन-सोर्स विनिर्देश और प्रोग्राम सूट है। यह एक बहुत लोकप्रिय उपकरण है जिसका उपयोग NoSQL डेटाबेस प्रबंधन प्रणालियों के सापेक्ष प्रदर्शन की तुलना करने के लिए किया जाता है।
परिचालन डेटाबेस के प्रदर्शन का परीक्षण करने के लिए YCSB का उपयोग करने के लिए, ब्लॉग देखें HBase के लिए YCSB कैसे चलाएं
