सहपाठियों के उदाहरण पर ड्र्यूड का उपयोग करने की विशेषताएं

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

हमें आंकड़ों की आवश्यकता क्यों है?

हम अपनी साइट के बारे में सब कुछ जानना चाहते हैं, इसलिए हम न केवल डिस्क, प्रोसेसर, आदि के व्यवहार को लॉग करते हैं, बल्कि प्रत्येक उपयोगकर्ता कार्रवाई, सबसिस्टम और हमारे सभी प्रणालियों के सभी आंतरिक प्रक्रियाओं के बीच हर बातचीत। सांख्यिकी प्रणाली बारीकी से विकास प्रक्रिया में एकीकृत है।

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

हमारे आँकड़े मुख्य रूप से रेखांकन के रूप में प्रस्तुत किए जाते हैं। आमतौर पर, चार्ट एक साथ कई दिनों को प्रदर्शित करता है, ताकि गतिशीलता स्पष्ट हो। यहाँ ड्र्यूड के साथ मेरे प्रयोगों का एक उदाहरण है। यहां डेटा लोडिंग (लाइनों / 5 मिनट) का एक ग्राफ है।



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

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



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

समस्या

जब डेटा वॉल्यूम छोटा था, तो हमने SQL के साथ अच्छी तरह से मुकाबला किया। लेकिन जैसे-जैसे डेटा की मात्रा बढ़ी, चार्ट आउटपुट धीमा हो गया। और अंत में, भीड़ के घंटे के आंकड़े आधे घंटे से कम होने लगे, और एक ग्राफ का औसत प्रतिक्रिया समय 6 सेकंड तक पहुंच गया। यानी किसी को 2 सेकंड में, किसी को 10-20 में और किसी को एक मिनट में शेड्यूल मिला। (आप यहां SQL में सिस्टम के विकास के बारे में पढ़ सकते हैं)

जब आप एक विसंगति या घटना की जांच करते हैं, तो आपको आमतौर पर एक दर्जन रेखांकन खोलने और देखने की आवश्यकता होती है, जिनमें से प्रत्येक पिछले एक से अनुसरण करता है, उन्हें एक ही समय में नहीं खोला जा सकता है। मुझे 10-20 सेकंड के लिए 10 बार इंतजार करना पड़ा। यह बहुत कष्टप्रद था।

प्रवास

आप अभी भी सिस्टम से कुछ निचोड़ सकते हैं, सर्वर जोड़ सकते हैं ... लेकिन लगभग उसी समय, Microsoft ने अपनी लाइसेंसिंग नीति बदल दी। यदि हमने SQL सर्वर का उपयोग जारी रखा, तो हमें लाखों डॉलर देने होंगे। इसलिए, उन्होंने प्रवास करने का फैसला किया।

आवश्यकताएँ इस प्रकार थीं:

• सांख्यिकी में अंतराल नहीं होना चाहिए (2 मिनट से अधिक)।
• चार्ट को 2 सेकंड से अधिक नहीं खोलना चाहिए।
• पूरे पैनल को 10 सेकंड से अधिक नहीं खोलना चाहिए।
• सिस्टम में दोष सहिष्णु होना चाहिए, डेटा सेंटर के नुकसान से बच सकता है।
• सिस्टम को आसानी से मापनीय होना चाहिए।
• सिस्टम को संशोधित करना आसान होना चाहिए, इसलिए हम चाहते थे कि यह जावा में हो।

यह सब हमें ड्र्यूड ने ही दिया था। इसमें प्रारंभिक एकत्रीकरण भी है, जो आपको डेटा प्रविष्टि के दौरान थोड़ी अधिक मात्रा, और अनुक्रमण को बचाने की अनुमति देता है। Druid हमारे आँकड़ों के लिए आवश्यक सभी प्रकार के प्रश्नों का समर्थन करता है। इसलिए, ऐसा लग रहा था कि हम आसानी से SQL सर्वर के लिए ड्र्यूड को प्रतिस्थापित कर सकते हैं।

बेशक, हमने इस कदम के लिए उम्मीदवार की भूमिका के लिए न केवल ड्र्यूड पर विचार किया। मेरा पहला विचार Microsoft SQL Server को PostgreSQL के साथ बदलना था। हालांकि, यह केवल वित्तीय लागतों की समस्या को हल करेगा, लेकिन पहुंच और स्केलिंग के साथ मदद नहीं करेगा।

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

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

अब 12 नोड्स (40 कोर, 196 जीबी रैम) से ड्र्यूड 500 हजार इवेंट्स प्रति सेकंड प्रति घंटा होता है, जबकि सुरक्षा का एक बड़ा मार्जिन (मैक्स कॉलम: लगभग पांच गुना सीपीयू मार्जिन) है।



ये आंकड़े उत्पादन के आंकड़ों पर आधारित हैं। मैं आपको बताता हूं कि हमने इसे कैसे हासिल किया, लेकिन पहले मैं ड्र्यूड का अधिक विस्तार से वर्णन करूंगा।

ड्र्यूड

यह एक वितरित कॉलम टाइमरीज़ OLAP सिस्टम है। इसके दस्तावेज़ीकरण में एक तालिका के लिए SQL दुनिया की सामान्य अवधारणाएं शामिल नहीं हैं (इसके बजाय डेटा स्रोत) या एक स्ट्रिंग (इसके बजाय घटना), लेकिन मैं उन्हें आसानी से वर्णन के लिए उपयोग करूंगा।

ड्र्यूड कई डेटा मान्यताओं (सीमाओं) पर आधारित है:

• प्रत्येक डेटा लाइन में एक टाइमस्टैम्प होता है जो नीरस रूप से बढ़ता है (डिफ़ॉल्ट रूप से 10 मिनट की विंडो के भीतर)।
• डेटा नहीं बदलता है, केवल सम्मिलित करें (अपडेट ऑपरेशन नहीं)।

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

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

बदले में, इसका परिणाम "वितरण" होता है: समानांतर में गणना करने के लिए छोटे सेगमेंट में बड़ी मात्रा में डेटा को विभाजित करने की क्षमता (दोनों एक मशीन पर और कई बार एक साथ)।

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

डिवाइस सेगमेंट का वर्णन करने के लिए हम सामान्य सारणी के रूप में एक साधारण उदाहरण पर विचार करते हैं:



इस तालिका में, चार मेजबानों से दो पांच मिनट में कॉल की संख्या (ध्यान दें कि वेब 1 होस्ट के लिए प्रत्येक पांच मिनट की अवधि में दो लाइनें हैं)।

ड्र्यूड के दृष्टिकोण से सभी डेटा कोशिकाओं को तीन प्रकारों में विभाजित किया गया है:

• टाइमस्टैम्प - एमएस में यूटीसी टाइमस्टैम्प (उदाहरण में यह समय है)।
• मैट्रिक्स वह है जो आपको गणना करने की आवश्यकता है (राशि, न्यूनतम, अधिकतम, गणना, ...), और आपको उन्हें प्रत्येक तालिका के लिए अग्रिम में जानना होगा (उदाहरण के लिए, यह कॉल है, और हम योग की गणना करेंगे)।
• आयाम - यह वह है जिसे आप समूह और फ़िल्टर कर सकते हैं (आपको उन्हें पहले से जानने की आवश्यकता नहीं है और इसे मक्खी पर बदला जा सकता है) (उदाहरण में, यह होस्ट है)।

सम्मिलित करते समय, सभी पंक्तियों को आयाम + टाइमस्टैम्प के पूर्ण सेट द्वारा समूहीकृत किया जाता है, और यदि वे प्रत्येक मैट्रिक्स से मेल खाते हैं, तो "इसके" एकत्रीकरण फ़ंक्शन को लागू किया जाता है (परिणामस्वरूप, आयाम + टाइमस्टैम्प के समान सेट के साथ कोई पंक्तियाँ नहीं होती हैं)। इस प्रकार, ड्र्यूड में प्रविष्टि के बाद हमारा उदाहरण इस तरह दिखाई देगा:



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

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

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



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

एक ड्र्यूड कई घटकों से बना होता है।

सबसे पहले, इसमें कई बाहरी निर्भरताएं हैं।

1. भंडारण। वहाँ, ड्र्यूड बस एक संपीड़ित रूप में सेगमेंट को संग्रहीत करता है। यह एक स्थानीय निर्देशिका, एचडीएफएस, अमेज़ॅन एस 3 हो सकता है। यहां केवल स्थान का उपयोग किया जाता है, कोई गणना नहीं की जाती है।
2. मेटा: मेटा जानकारी के लिए एक डेटाबेस। यह डेटाबेस पूरा डेटा मैप संग्रहीत करता है: कौन से सेगमेंट प्रासंगिक हैं, जो पुराने हैं, कौन सा पथ संग्रहण में है।
3. चिड़ियाघरकीपर का उपयोग करते हुए, सिस्टम डिस्कवरी करता है और घोषणा करता है कि किस ड्र्यूड नोड्स हैं जो क्वेरी के लिए उपलब्ध हैं।
4. निष्पादित अनुरोधों का कैश, यह याद किया जा सकता है या जावा ढेर में स्थानीय कैश हो सकता है।

दूसरे, ड्र्यूड में कई प्रकार के घटक होते हैं।

1. रीयलटाइम नोड्स प्राप्त किए गए क्रम में ताजा डेटा की धारा को लोड करते हैं और इसके लिए अनुरोध करते हैं।
2. ऐतिहासिक नोड्स में डेटा का संपूर्ण द्रव्यमान होता है और इसके लिए अनुरोध करता है। जब हम कहते हैं कि हमारे पास 300 टीबी क्लस्टर है, तो हमारा मतलब ऐतिहासिक नोड्स से है।
3. ब्रोकर ऐतिहासिक और रीयलटाइम नोड्स के बीच कम्प्यूटेशन वितरित करने के लिए जिम्मेदार है।
4. समन्वयक ऐतिहासिक नोड्स में और प्रतिकृति के लिए खंड आवंटित करने के लिए जिम्मेदार है।
5. अनुक्रमण सेवा, जो आपको बैचों में डेटा (पुनः) लोड करने की अनुमति देती है, उदाहरण के लिए, डेटा के "अपग्रेड" भाग के लिए।

डेटा स्ट्रीम

बोल्ड तीर एक डेटा स्ट्रीम को इंगित करता है, पतले तीर मेटाडेटा स्ट्रीम को इंगित करते हैं।

एक रीयलटाइम नोड समय-समय पर डेटा, इंडेक्स और कटौती को खंडों में लेता है, उदाहरण के लिए, दिन के हिसाब से।

रीयलटाइम नोड का प्रत्येक नया खंड भंडारण के लिए लिखता है और इसके लिए अनुरोधों की सेवा करने के लिए एक प्रति छोड़ता है। फिर यह मेटाडेटा को रिकॉर्ड करता है कि इस तरह के और इस तरह के एक पथ में एक नया खंड दिखाई दिया है।

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

प्रसंस्करण का अनुरोध करें

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

उच्च उपलब्धता

जैसा कि आप याद करते हैं, निर्भरता की सूची में ड्र्यूड में मेटाडेटा के लिए आधार है, जो MySQL या PostgreSQL हो सकता है। अपाचे डर्बी का भी उल्लेख किया गया है, लेकिन इस उत्पाद का उपयोग उत्पादन के लिए नहीं किया जा सकता है, केवल विकास के लिए (जैसा कि मैं इसे समझता हूं, डर्बी का उपयोग एक एम्बेडेड रूप में किया जाता है, ताकि मायके के वातावरण में mysql / pgsql न बढ़ाएं)।

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

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

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

ड्र्यूड और ज़ूकीपर

चिड़ियाघरकीपर के साथ, सब कुछ बेहतर और बदतर है। बेहतर है क्योंकि ज़ूकीपर स्वयं ही दोष सहिष्णु है, इसकी प्रतिकृति बॉक्स से बाहर है। ऐसा लगता है कि ऐसा हो सकता है?

सामान्यतया, यह अध्याय अब प्रासंगिक नहीं है। और यह एक सफलता की कहानी नहीं है, यह एक दर्द है जो (हम और ताजा ड्र्यूड दोनों) ने चिड़ियाघरकीपर से लगभग सभी डेटा को मौलिक रूप से हटाने का फैसला किया है, और अब ड्र्यूड नोड सीधे HTTP के माध्यम से एक दूसरे से अनुरोध करते हैं।

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

इसके आधार पर, ड्र्यूड कार्यों में खोज: स्टार्टअप पर, प्रत्येक नोड ZooKeeper में एक नया सत्र बनाता है और अपने बारे में पंचांग डेटा रिकॉर्ड करता है: होस्ट: पोर्ट, नोड का प्रकार (ब्रोकर / रियलटाइम / ऐतिहासिक / ...), कनेक्शन टाइमस्टैम्प, आदि। ... अन्य ड्र्यूड नोड्स को चिड़ियाघर कीपर से सूचनाएं प्राप्त होती हैं और यह डेटा पढ़ता है, इसलिए वे सीखते हैं कि एक नया ड्र्यूड नोड बढ़ गया है और यह किस तरह का नोड है। यदि कोई ड्र्यूड नोड अपने सत्र के समय समाप्त होने के बाद गिरता है, तो इसके बारे में डेटा चिड़ियाघरकीपर द्वारा हटा दिया जाएगा, और अन्य ड्र्यूड नोड्स को इसके बारे में पता चल जाएगा। ताकि वे इसके बारे में तेज़ी से सीखें, हम एक छोटे सत्र का समय देना पसंद करते हैं।

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

जैसा कि मैंने कहा, यह सूची लंबी हो सकती है। जब चिड़ियाघरकीपर में बहुत अधिक डेटा होता है, तो यह पता चलता है कि यह अब इतना स्थिर नहीं है। हमारे मामले में, स्पष्ट समस्याएं शुरू हुईं जब खंडों की संख्या लगभग 7 मिलियन तक पहुंच गई, ज़ूकीपर स्नैपशॉट ने 6GB पर कब्जा कर लिया।
क्या होता है अगर एक ड्र्यूड नोड चिड़ियाघरकीपर के साथ स्पर्श करता है?

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

उपयोगकर्ता इस समय क्या देखता है?

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

अब हम सत्र का समय बढ़ा रहे हैं। इस मामले में क्या होता है?

मान लीजिए कि ऐतिहासिक नोड ने सही तरीके से पुनरारंभ नहीं किया और चिड़ियाघरकीपर से पुराने सत्र को नहीं हटाया, जबकि एक नया बना और वहां डेटा का एक गुच्छा लिख ​​रहा है। जबकि पुराना सत्र अभी भी जीवित है और समय समाप्त नहीं हुआ है, डेटा की दो प्रतियां ज़ूकीपर में संग्रहीत हैं। यदि कई ऐसे नोड्स हैं जिन्हें तुरंत फिर से शुरू किया जाता है, तो बहुत सारे डेटा को डुप्लिकेट किया जाएगा। इसलिए, आपको ज़ूकिपर के लिए मेमोरी की आपूर्ति बनाए रखने की आवश्यकता है ताकि यह बाहर न निकले और ज़ूकीपर काम करना बंद न करे। पुराने सत्र का डेटा क्यों नहीं हटाया जा सका?

उसी कारण से, ऐतिहासिक नोड्स के संचालन को सही ढंग से पूरा करना आवश्यक है, क्योंकि उस क्षण से वे ज़ूकिपर से अपना डेटा हटाते हैं, और लंबे समय तक ऐसा कर सकते हैं। ऐतिहासिक नोड्स के पूरा होने में लगभग आधे घंटे लगते हैं।

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

हमने दो और अनुकूलन किए:

• हमने ज़ूकेपर के साथ काम करना थोड़ा दोहरा दिया ताकि केवल उन नोड्स की ज़रूरत हो जो उन्हें ड्र्यूड से पढ़े जाते हैं। realtime, , . , . , .
• , ZooKeeper, , . ZooKeeper 6 2 ( ).

8 ; .

Druid

realtime , . - ( , , ). , MMAP ( ). . .

-, realtime- , JVM , .



. : 1) 2) . , . , , . , , , . ( , , ).

, realtime- , , .. , , , ( ).

, . , , .

, Druid . , , , .



, . , (web%, api%).

• Druid — . .
• , .
• Druid , , : , , , .
• Druid , , calls.

, 5 % , 95 % — .

, , realtime- .



, ( 10:45) . - , -. , ( 10:50) , -. और इसी तरह। , , «calls», «time» «host» .
-. , «» . , , . ( 95% ) , : , . 100 , 1000.

? , . , realtime , . (.. historical realtime-), .

, : . , , . 100 . , . .

. 80% , , , . . . , selector, . , .

, , , . , . , 8 . Druid. , , Druid, . , . :



, , . . , , . . 27 . , 27 , 27 .

, . 27 , 9, 9 , .
.



— : , , . — : , , . — : , , . — , . , . , 27. 9, . ( 95% ) 9 . 27 .

14 . . , 14 . 14 . . , , 10 , . .

, 2 . 11 , 74 . , . 74 ? , .
Druid . , , , . , , . , , . , , .

, Druid . , ( ) , . 5 : , . . ( java), . Druid , .

परिणाम

, , SQL Server, Microsoft.

, / .

, , .

20 , , 18 .

one-cloud ( https://habr.com/company/odnoklassniki/blog/346868/ ), .