यह ब्लॉग पोस्ट Cloudera के साथ विलय से पहले Hortonworks.com पर प्रकाशित हुआ था। कुछ लिंक, संसाधन या संदर्भ अब सटीक नहीं हो सकते हैं।
यह ब्लॉग पोस्ट मूल रूप से यहां दिखाई दी थी और इसे यहां पूरी तरह से पुन:प्रस्तुत किया गया है।
HBase एक वितरित डेटाबेस है जो एक ऑर्डर किए गए लॉग और लॉग-स्ट्रक्चर्ड मर्ज ट्री की मूल अवधारणाओं के आसपास बनाया गया है। किसी भी डेटाबेस की तरह, अनुकूलित I/O HBase के लिए एक महत्वपूर्ण चिंता का विषय है। जब संभव हो, प्राथमिकता किसी भी I/O को बिल्कुल भी निष्पादित नहीं करना है। इसका मतलब है कि स्मृति उपयोग और कैशिंग संरचनाएं अत्यंत महत्वपूर्ण हैं। इसके लिए, HBase दो कैश संरचनाओं को बनाए रखता है:"मेमोरी स्टोर" और "ब्लॉक कैश"। मेमोरी स्टोर, जिसे MemStore . के रूप में लागू किया गया है , डेटा संपादन को प्राप्त करते ही जमा करता है, उन्हें स्मृति में बफर करता है (1)। ब्लॉक कैश, BlockCache . का कार्यान्वयन इंटरफ़ेस, डेटा ब्लॉक को पढ़ने के बाद स्मृति में निवासी रखता है।
MemStore हाल के संपादनों तक पहुँचने के लिए महत्वपूर्ण है। बिना MemStore . के , उस डेटा तक पहुँचने के लिए जैसा कि इसे राइट लॉग में लिखा गया था, उस फ़ाइल से वापस प्रविष्टियों को पढ़ने और अक्रमांकन करने की आवश्यकता होगी, कम से कम एक O(n) कार्यवाही। इसके बजाय, MemStore एक स्कीपलिस्ट संरचना को बनाए रखता है, जो एक O(log n) . का आनंद लेती है एक्सेस लागत और डिस्क I/O की आवश्यकता नहीं है। MemStore हालाँकि, HBase में संग्रहीत डेटा का एक छोटा सा हिस्सा होता है।
सर्विसिंग BlockCache . से पढ़ता है प्राथमिक तंत्र है जिसके माध्यम से HBase मिलीसेकंड विलंबता के साथ यादृच्छिक पढ़ने की सेवा करने में सक्षम है। जब एचडीएफएस से डेटा ब्लॉक पढ़ा जाता है, तो इसे BlockCache . में कैश किया जाता है . पड़ोसी डेटा के बाद के पढ़ने - उसी ब्लॉक से डेटा - डिस्क (2) से उस डेटा को फिर से प्राप्त करने के I/O दंड का सामना नहीं करना पड़ता है। यह है BlockCache इस पोस्ट का शेष फोकस यही होगा।
कैश करने के लिए अवरोधित करें
BlockCache को समझने से पहले , यह समझने में मदद करता है कि वास्तव में एक HBase "ब्लॉक" क्या है। HBase संदर्भ में, एक ब्लॉक I/O की एकल इकाई है। HFile को डेटा लिखते समय, ब्लॉक लिखे गए डेटा की सबसे छोटी इकाई होती है। इसी तरह, एक एकल ब्लॉक डेटा की सबसे छोटी मात्रा है जिसे HBase HFile से वापस पढ़ सकता है। सावधान रहें कि एचबीएएस ब्लॉक को एचडीएफएस ब्लॉक या अंतर्निहित फाइल सिस्टम के ब्लॉक के साथ भ्रमित न करें - ये सभी अलग-अलग हैं (3)।
HBase ब्लॉक 4 किस्मों में आते हैं: DATA , META , INDEX , और BLOOM ।
DATA ब्लॉक उपयोगकर्ता डेटा संग्रहीत करते हैं। जब BLOCKSIZE कॉलम परिवार के लिए निर्दिष्ट है, यह इस तरह के ब्लॉक के लिए एक संकेत है। ध्यान रहे, यह केवल एक संकेत है। MemStore को फ्लश करते समय , HBase इस दिशानिर्देश का सम्मान करने की पूरी कोशिश करेगा। प्रत्येक Cell . के बाद लिखा है, लेखक जाँचता है कि क्या लिखी गई राशि>=लक्ष्य BLOCKSIZE है . अगर ऐसा है, तो यह मौजूदा ब्लॉक को बंद कर देगा और अगला ब्लॉक (4) शुरू कर देगा।
INDEX और BLOOM ब्लॉक एक ही लक्ष्य की सेवा करते हैं; दोनों का उपयोग पढ़ने के पथ को तेज करने के लिए किया जाता है। INDEX ब्लॉक Cell . पर एक अनुक्रमणिका प्रदान करते हैं DATA . में निहित है ब्लॉक। BLOOM ब्लॉक में एक ही डेटा पर एक ब्लूम फ़िल्टर होता है। अनुक्रमणिका पाठक को शीघ्रता से यह जानने की अनुमति देती है कि Cell . कहां है संग्रहित किया जाना चाहिए। फ़िल्टर पाठक को तब बताता है जब एक Cell निश्चित रूप से डेटा से अनुपस्थित है।
अंत में, META ब्लॉक एचएफआईएल और अन्य विविध सूचनाओं के बारे में जानकारी संग्रहीत करते हैं - मेटाडेटा, जैसा कि आप उम्मीद कर सकते हैं। Apache HBase I/O - HFile में HFile स्वरूपों और विभिन्न ब्लॉक प्रकारों की भूमिकाओं का अधिक व्यापक अवलोकन प्रदान किया गया है।
HBase BlockCache और इसके कार्यान्वयन
एक ही BlockCache . है एक क्षेत्र सर्वर में उदाहरण, जिसका अर्थ है कि उस सर्वर द्वारा होस्ट किए गए सभी क्षेत्रों के सभी डेटा समान कैश पूल साझा करते हैं (5)। BlockCache क्षेत्र सर्वर स्टार्टअप पर त्वरित किया जाता है और प्रक्रिया के पूरे जीवनकाल के लिए बनाए रखा जाता है। परंपरागत रूप से, HBase केवल एक ही BlockCache . प्रदान करता था कार्यान्वयन: LruBlockCache . 0.92 रिलीज ने एचबीएएसई-4027 में पहला विकल्प पेश किया:SlabCache . HBase 0.96 ने HBASE-7404 के माध्यम से एक और विकल्प पेश किया, जिसे BucketCache कहा जाता है। ।
आजमाए हुए और सही LruBlockCache . के बीच मुख्य अंतर और ये विकल्प वह तरीका है जिससे वे स्मृति का प्रबंधन करते हैं। विशेष रूप से, LruBlockCache एक डेटा संरचना है जो पूरी तरह से जेवीएम हीप पर रहती है, जबकि अन्य दो जेवीएम हीप के बाहर से मेमोरी का लाभ उठाने में सक्षम हैं। यह एक महत्वपूर्ण अंतर है क्योंकि JVM हीप मेमोरी को JVM कचरा कलेक्टर द्वारा प्रबंधित किया जाता है, जबकि अन्य नहीं हैं। SlabCache . के मामलों में और BucketCache , यह विचार है कि ढेर पर रखी गई वस्तुओं की संख्या को कम करके क्षेत्र सर्वर प्रक्रिया द्वारा अनुभव किए गए जीसी दबाव को कम किया जाए।
LruBlockCache
यह डिफ़ॉल्ट कार्यान्वयन है। इस कार्यान्वयन का उपयोग करके डेटा ब्लॉक को JVM हीप में कैश किया जाता है। इसे तीन क्षेत्रों में विभाजित किया गया है:सिंगल-एक्सेस, मल्टी-एक्सेस और इन-मेमोरी। क्षेत्रों का आकार कुल BlockCache . का 25%, 50%, 25% है आकार, क्रमशः (6)। एचडीएफएस से शुरू में पढ़ा गया एक ब्लॉक सिंगल-एक्सेस क्षेत्र में आबाद है। लगातार पहुंच उस ब्लॉक को बहु-पहुंच क्षेत्र में बढ़ावा देती है। इन-मेमोरी क्षेत्र IN_MEMORY के रूप में फ़्लैग किए गए स्तंभ परिवारों से लोड किए गए ब्लॉक के लिए आरक्षित है . क्षेत्र चाहे जो भी हो, पुराने ब्लॉकों को कम-हाल ही में उपयोग किए गए एल्गोरिदम का उपयोग करके नए ब्लॉक के लिए जगह बनाने के लिए निकाला जाता है, इसलिए "LruBlockCache" में "Lru"।
स्लैब कैश
यह कार्यान्वयन DirectByteBuffer . का उपयोग करके JVM हीप के बाहर मेमोरी के क्षेत्रों को आवंटित करता है एस। ये क्षेत्र इस BlockCache . का मुख्य भाग प्रदान करते हैं . सटीक क्षेत्र जिसमें एक विशेष ब्लॉक रखा जाएगा, ब्लॉक के आकार पर आधारित है। डिफ़ॉल्ट रूप से, दो क्षेत्रों को आवंटित किया जाता है, जो कुल कॉन्फ़िगर किए गए ऑफ-हीप कैश आकार के क्रमशः 80% और 20% की खपत करता है। पूर्व का उपयोग उन ब्लॉकों को कैश करने के लिए किया जाता है जो लगभग लक्ष्य ब्लॉक आकार (7) हैं। उत्तरार्द्ध में ऐसे ब्लॉक होते हैं जो लक्ष्य ब्लॉक आकार के लगभग 2x होते हैं। एक ब्लॉक को सबसे छोटे क्षेत्र में रखा जाता है जहां वह फिट हो सकता है। यदि कैश का सामना किसी क्षेत्र में फिट होने से बड़ा ब्लॉक होता है, तो उस ब्लॉक को कैश नहीं किया जाएगा। पसंद करें LruBlockCache , ब्लॉक निष्कासन को LRU एल्गोरिथम का उपयोग करके प्रबंधित किया जाता है।
बकेट कैश
इस कार्यान्वयन को तीन अलग-अलग तरीकों में से एक में संचालित करने के लिए कॉन्फ़िगर किया जा सकता है: heap , offheap , और file . ऑपरेटिंग मोड चाहे जो भी हो, BucketCache कैश्ड ब्लॉक रखने के लिए "बकेट" नामक मेमोरी के क्षेत्रों का प्रबंधन करता है। प्रत्येक बकेट लक्ष्य ब्लॉक आकार के साथ बनाया जाता है। heap कार्यान्वयन उन बकेट को JVM हीप पर बनाता है; offheap कार्यान्वयन DirectByteByffers . का उपयोग करता है जेवीएम ढेर के बाहर बाल्टी का प्रबंधन करने के लिए; file मोड फ़ाइल सिस्टम पर एक फ़ाइल के पथ की अपेक्षा करता है जिसमें बकेट बनाए जाते हैं। file मोड कम-विलंबता बैकिंग स्टोर के साथ उपयोग के लिए अभिप्रेत है - एक इन-मेमोरी फाइल सिस्टम, या शायद एसएसडी स्टोरेज (8) पर बैठी फाइल। मोड चाहे जो भी हो, BucketCache विभिन्न आकारों की 14 बाल्टी बनाता है। यह उपयोग को सूचित करने के लिए ब्लॉक एक्सेस की आवृत्ति का उपयोग करता है, ठीक उसी तरह जैसे LruBlockCache , और 25%, 50%, 25% का एक ही सिंगल-एक्सेस, मल्टी-एक्सेस, और इन-मेमोरी ब्रेकडाउन है। डिफ़ॉल्ट कैश की तरह, ब्लॉक निष्कासन को LRU एल्गोरिथम का उपयोग करके प्रबंधित किया जाता है।
बहु-स्तरीय कैशिंग
दोनों SlabCache और BucketCache बहु-स्तरीय कैशिंग रणनीति के भाग के रूप में उपयोग करने के लिए डिज़ाइन किए गए हैं। इस प्रकार, कुल BlockCache . का कुछ भाग आकार एक LruBlockCache . को आवंटित किया गया है उदाहरण। यह उदाहरण पहले स्तर के कैश, "L1" के रूप में कार्य करता है, जबकि अन्य कैश इंस्टेंस को दूसरे स्तर के कैश, "L2" के रूप में माना जाता है। हालांकि, LruBlockCache . के बीच की बातचीत और SlabCache LruBlockCache . से अलग है और BucketCache बातचीत करें।
SlabCache रणनीति, जिसे DoubleBlockCache . कहा जाता है , हमेशा L1 और L2 दोनों कैश में ब्लॉक कैश करना है। दो कैश स्तर स्वतंत्र रूप से काम करते हैं:ब्लॉक को पुनर्प्राप्त करते समय दोनों की जांच की जाती है और प्रत्येक दूसरे के संबंध में ब्लॉक को बेदखल कर देता है। BucketCache रणनीति, जिसे CombinedBlockCache . कहा जाता है , विशेष रूप से ब्लूम और इंडेक्स ब्लॉकों के लिए L1 कैश का उपयोग करता है। डेटा ब्लॉक सीधे L2 कैश में भेजे जाते हैं। L1 ब्लॉक के निष्कासन की स्थिति में, पूरी तरह से खारिज किए जाने के बजाय, उस ब्लॉक को L2 कैश में डिमोट कर दिया जाता है।
कौन सा चुनना है?
किसी एक विकल्प को सक्षम करने पर विचार करने के दो कारण हैं BlockCache कार्यान्वयन। पहला केवल RAM की मात्रा है जिसे आप क्षेत्र सर्वर को समर्पित कर सकते हैं। सामुदायिक ज्ञान जेवीएम ढेर की ऊपरी सीमा को पहचानता है, जहां तक क्षेत्र सर्वर का संबंध है, 14GB और 31GB (9) के बीच कहीं होना चाहिए। सटीक सीमा आमतौर पर हार्डवेयर प्रोफाइल, क्लस्टर कॉन्फ़िगरेशन, डेटा टेबल के आकार और एप्लिकेशन एक्सेस पैटर्न के संयोजन पर निर्भर करती है। जीसी के रुकने और RegionTooBusyException पर आपको पता चल जाएगा कि आपने डेंजर जोन में प्रवेश कर लिया है। आपके लॉग में बाढ़ आने लगती है।
वैकल्पिक कैश पर विचार करने का दूसरा समय तब होता है जब प्रतिक्रिया विलंबता वास्तव में मायने रखता है। ढेर को 8-12GB के आसपास रखने से CMS संग्राहक बहुत सुचारू रूप से (10) चल सकता है, जिसका प्रतिक्रिया समय के 99वें प्रतिशतक पर औसत दर्जे का प्रभाव पड़ता है। इस प्रतिबंध को देखते हुए, वैकल्पिक कचरा संग्रहकर्ता का पता लगाने या स्पिन के लिए इनमें से किसी एक ऑफ-हीप कार्यान्वयन को लेने का एकमात्र विकल्प है।
यह दूसरा विकल्प ठीक वही है जो मैंने किया है। अपनी अगली पोस्ट में, मैं कुछ अवैज्ञानिक-लेकिन-सूचनात्मक प्रयोग परिणामों को साझा करूँगा जहाँ मैं अलग-अलग BlockCache के लिए प्रतिक्रिया समय की तुलना करता हूँ कार्यान्वयन।
हमेशा की तरह, हमारे साथ बने रहें और HBase के साथ बने रहें!
1:MemStore जैसे ही वे प्राप्त होते हैं, डेटा संपादन जमा करते हैं, उन्हें स्मृति में बफ़र करते हैं। यह दो उद्देश्यों को पूरा करता है:यह एक ही ऑपरेशन में डिस्क पर लिखे गए डेटा की कुल मात्रा को बढ़ाता है, और यह निम्न-विलंबता पठन के रूप में बाद की पहुंच के लिए स्मृति में उन हालिया परिवर्तनों को बरकरार रखता है। पूर्व महत्वपूर्ण है क्योंकि यह एचबीएएस को एचडीएफएस ब्लॉक आकार के साथ सिंक में मोटे तौर पर लिखता है, एचबीएएस एक्सेस पैटर्न को अंतर्निहित एचडीएफएस स्टोरेज के साथ संरेखित करता है। उत्तरार्द्ध स्व-व्याख्यात्मक है, हाल ही में लिखित डेटा को पढ़ने के अनुरोधों की सुविधा प्रदान करता है। यह इंगित करने योग्य है कि यह संरचना डेटा स्थायित्व में शामिल नहीं है। आदेशित लेखन लॉग में संपादन भी लिखे जाते हैं, HLog , जिसमें एक विन्यास योग्य अंतराल पर एक एचडीएफएस एपेंड ऑपरेशन शामिल होता है, आमतौर पर तत्काल।
2:स्थानीय फाइल सिस्टम से डेटा को फिर से पढ़ना सबसे अच्छी स्थिति है। आखिरकार, एचडीएफएस एक वितरित फाइल सिस्टम है, इसलिए सबसे खराब स्थिति में नेटवर्क पर उस ब्लॉक को पढ़ने की आवश्यकता होती है। HBase डेटा लोकेलिटी को बनाए रखने की पूरी कोशिश करता है। ये दो लेख इस बात की गहराई से जानकारी देते हैं कि HBase के लिए डेटा इलाके का क्या मतलब है और इसका प्रबंधन कैसे किया जाता है।
3:फाइल सिस्टम, एचडीएफएस, और एचबीएएस ब्लॉक सभी अलग हैं लेकिन संबंधित हैं। आधुनिक I/O सबसिस्टम अमूर्तता के शीर्ष पर अमूर्तता की कई परतें हैं। उस अमूर्तता का मूल डेटा की एक इकाई की अवधारणा है, जिसे "ब्लॉक" कहा जाता है। इसलिए, ये तीनों भंडारण परतें अपने स्वयं के ब्लॉक, प्रत्येक अपने स्वयं के आकार को परिभाषित करती हैं। सामान्य तौर पर, एक बड़े ब्लॉक आकार का अर्थ है क्रमिक पहुंच थ्रूपुट में वृद्धि। एक छोटा ब्लॉक आकार तेजी से रैंडम एक्सेस की सुविधा देता है।
4:BLOCKSIZE रखना डेटा लिखे जाने के बाद जाँच के दो प्रभाव हैं। एक ही Cell DATA . को लिखे गए डेटा की सबसे छोटी इकाई है खंड मैथा। इसका मतलब एक Cell भी होता है एक से अधिक ब्लॉक नहीं फैला सकता।
5:यह MemStore . से अलग है , जिसके लिए क्षेत्र सर्वर द्वारा होस्ट किए गए प्रत्येक क्षेत्र के लिए एक अलग उदाहरण है।
6:हाल ही में, इन स्मृति विभाजनों को स्थिर रूप से परिभाषित किया गया था; 25/50/25 विभाजन को ओवरराइड करने का कोई तरीका नहीं था। एक दिया गया खंड, उदाहरण के लिए बहु-पहुंच क्षेत्र, 50% आवंटन से बड़ा हो सकता है, जब तक कि अन्य क्षेत्रों का उपयोग कम हो। अन्य क्षेत्रों में बढ़ा हुआ उपयोग 25/50/25 शेष राशि प्राप्त होने तक बहु-पहुंच क्षेत्र से प्रविष्टियों को बेदखल कर देगा। ऑपरेटर इन डिफ़ॉल्ट आकारों को नहीं बदल सका। HBASE-10263, HBase 0.98.0 में शिपिंग, इन आकारों के लिए कॉन्फ़िगरेशन पैरामीटर पेश करता है। लचीला व्यवहार बरकरार रखा जाता है।
7:"लगभग" व्यवसाय ब्लॉक आकार में कुछ विग्गल रूम की अनुमति देना है। HBase ब्लॉक आकार एक मोटा लक्ष्य या संकेत है, सख्ती से लागू बाधा नहीं है। किसी विशेष डेटा ब्लॉक का सटीक आकार लक्ष्य ब्लॉक आकार और Cell के आकार पर निर्भर करेगा उसमें निहित मूल्य। ब्लॉक आकार संकेत 64kb के डिफ़ॉल्ट ब्लॉक आकार के रूप में निर्दिष्ट है।
8: BucketCache का उपयोग करना file . में लगातार बैकिंग स्टोर वाले मोड का एक और लाभ है:हठ। स्टार्टअप पर, यह कैश में मौजूदा डेटा की तलाश करेगा और इसकी वैधता को सत्यापित करेगा।
9:जैसा कि मैं इसे समझता हूं, इस सीमा पर ऊपरी सीमा की सलाह देने वाले दो घटक हैं। सबसे पहले JVM ऑब्जेक्ट एड्रेसेबिलिटी पर एक सीमा है। JVM पूर्ण 64-बिट मूल पते के बजाय 32-बिट सापेक्ष पते के साथ ढेर पर किसी ऑब्जेक्ट को संदर्भित करने में सक्षम है। यह अनुकूलन केवल तभी संभव है जब कुल ढेर आकार 32GB से कम हो। अधिक विवरण के लिए संपीडित उफ़ देखें. दूसरा सिस्टम में वस्तु मंथन की मात्रा को बनाए रखने के लिए कचरा संग्रहकर्ता की क्षमता है। मैं जो बता सकता हूं, उसके अनुसार वस्तु मंथन के तीन स्रोत हैं MemStore , BlockCache , और नेटवर्क संचालन। पहले को MemSlab . द्वारा कम किया जाता है सुविधा, डिफ़ॉल्ट रूप से सक्षम। दूसरा आपके डेटासेट के आकार बनाम कैश के आकार से प्रभावित होता है। तीसरे की तब तक मदद नहीं की जा सकती जब तक HBase एक नेटवर्क स्टैक का उपयोग करता है जो डेटा कॉपी पर निर्भर करता है।
10:ठीक 8 की तरह, यह "आधुनिक हार्डवेयर" मान रहा है। यहां बातचीत काफी जटिल है और एक ब्लॉग पोस्ट के दायरे से बाहर है।
