हमने एकाधिक समय श्रृंखला डेटाबेस का परीक्षण कैसे किया

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

ऐसा लग सकता है कि 2019 में एक लेख जिसके बारे में टीएसडीबी उपयोग करने लायक है, उसमें केवल एक वाक्य होगा: "बस क्लिकहाउस का उपयोग करें।" लेकिन... कुछ बारीकियाँ हैं।

वास्तव में, ClickHouse सक्रिय रूप से विकसित हो रहा है, उपयोगकर्ता आधार बढ़ रहा है, और समर्थन बहुत सक्रिय है, लेकिन क्या हम ClickHouse की सार्वजनिक सफलता के बंधक बन गए हैं, जिसने अन्य, शायद अधिक प्रभावी/विश्वसनीय समाधानों को पीछे छोड़ दिया है?

पिछले साल की शुरुआत में, हमने अपनी स्वयं की निगरानी प्रणाली पर फिर से काम करना शुरू किया, जिसके दौरान डेटा संग्रहीत करने के लिए उपयुक्त डेटाबेस चुनने का सवाल उठा। मैं यहां इस पसंद के इतिहास के बारे में बात करना चाहता हूं।

समस्या का निरूपण

सबसे पहले, एक आवश्यक प्रस्तावना. हमें अपनी स्वयं की निगरानी प्रणाली की आवश्यकता क्यों है और इसे कैसे डिज़ाइन किया गया था?

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

हमारी मुख्य आवश्यकताएँ थीं:

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

इस लेख में हम अंतिम बिंदु में रुचि रखते हैं।

भंडारण की बात करें तो आवश्यकताएँ इस प्रकार थीं:

• सिस्टम को शीघ्रता से कार्य करना चाहिए;
• यह वांछनीय है कि सिस्टम में SQL इंटरफ़ेस हो;
• सिस्टम स्थिर होना चाहिए और एक सक्रिय उपयोगकर्ता आधार और समर्थन होना चाहिए (एक बार हमें MemcacheDB जैसे सिस्टम का समर्थन करने की आवश्यकता का सामना करना पड़ा था, जो अब विकसित नहीं हुआ था, या MooseFS वितरित भंडारण, जिसका बग ट्रैकर चीनी में रखा गया था: हम अपने प्रोजेक्ट के लिए यह कहानी दोहराना नहीं चाहते थे);
• सीएपी प्रमेय का अनुपालन: संगति (आवश्यक) - डेटा अद्यतित होना चाहिए, हम नहीं चाहते कि अलर्ट प्रबंधन प्रणाली नया डेटा प्राप्त न करे और सभी परियोजनाओं के लिए डेटा न आने के बारे में अलर्ट जारी करे; विभाजन सहनशीलता (आवश्यक) - हम स्प्लिट ब्रेन सिस्टम प्राप्त नहीं करना चाहते हैं; उपलब्धता (महत्वपूर्ण नहीं, यदि कोई सक्रिय प्रतिकृति है) - हम कोड का उपयोग करके दुर्घटना की स्थिति में स्वयं बैकअप सिस्टम पर स्विच कर सकते हैं।

अजीब बात है, उस समय MySQL हमारे लिए आदर्श समाधान साबित हुआ। हमारी डेटा संरचना बेहद सरल थी: सर्वर आईडी, काउंटर आईडी, टाइमस्टैम्प और मूल्य; हॉट डेटा का तेज़ नमूनाकरण एक बड़े बफर पूल द्वारा सुनिश्चित किया गया था, और ऐतिहासिक डेटा का नमूना एसएसडी द्वारा सुनिश्चित किया गया था।

इस प्रकार, हमने ताजा दो-सप्ताह के डेटा का एक नमूना प्राप्त किया, जिसमें डेटा पूरी तरह से प्रस्तुत होने से पहले 200 एमएस तक का विवरण था, और इस प्रणाली में काफी लंबे समय तक रहे।

इस बीच, समय बीतता गया और डेटा की मात्रा बढ़ती गई। 2016 तक, डेटा वॉल्यूम दसियों टेराबाइट्स तक पहुंच गया, जो किराए के एसएसडी स्टोरेज के संदर्भ में एक महत्वपूर्ण खर्च था।

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

हालाँकि, कंपनी की प्रमुख प्रणाली स्थिर रूप से काम करती रही, और मैं किसी और चीज़ पर स्विच करने का प्रयोग नहीं करना चाहता था।

2017 में, सैन जोस में पेरकोना लाइव सम्मेलन में, क्लिकहाउस डेवलपर्स ने संभवतः पहली बार खुद की घोषणा की। पहली नज़र में, सिस्टम उत्पादन के लिए तैयार था (खैर, Yandex.Metrica एक कठोर उत्पादन प्रणाली है), समर्थन तेज़ और सरल था, और, सबसे महत्वपूर्ण बात, ऑपरेशन सरल था। 2018 से, हमने परिवर्तन प्रक्रिया शुरू कर दी है। लेकिन उस समय तक, बहुत सारे "वयस्क" और समय-परीक्षणित टीएसडीबी सिस्टम थे, और हमने यह सुनिश्चित करने के लिए काफी समय समर्पित करने और विकल्पों की तुलना करने का निर्णय लिया कि हमारी आवश्यकताओं के अनुसार, क्लिकहाउस के लिए कोई वैकल्पिक समाधान नहीं थे।

पहले से निर्दिष्ट भंडारण आवश्यकताओं के अलावा, नई चीज़ें सामने आई हैं:

• नई प्रणाली को हार्डवेयर की समान मात्रा पर कम से कम MySQL के समान प्रदर्शन प्रदान करना चाहिए;
• नई प्रणाली के भंडारण में काफी कम जगह लगनी चाहिए;
• DBMS को अभी भी प्रबंधित करना आसान होना चाहिए;
• मैं डीबीएमएस बदलते समय एप्लिकेशन को न्यूनतम रूप से बदलना चाहता था।

हमने किन प्रणालियों पर विचार करना शुरू किया?

अपाचे हाइव/अपाचे इम्पाला
एक पुराना, युद्ध-परीक्षित Hadoop स्टैक। अनिवार्य रूप से, यह HDFS पर मूल स्वरूपों में डेटा संग्रहीत करने के शीर्ष पर बनाया गया एक SQL इंटरफ़ेस है।

पेशेवरों।

• स्थिर संचालन के साथ, डेटा को स्केल करना बहुत आसान है।
• डेटा भंडारण (कम जगह) के लिए कॉलम समाधान हैं।
• संसाधन उपलब्ध होने पर समानांतर कार्यों का बहुत तेजी से निष्पादन।

विपक्ष।

• यह Hadoop है, और इसका उपयोग करना कठिन है। यदि हम क्लाउड में तैयार समाधान लेने के लिए तैयार नहीं हैं (और हम लागत के मामले में तैयार नहीं हैं), तो पूरे स्टैक को व्यवस्थापकों के हाथों से इकट्ठा और समर्थित करना होगा, और हम वास्तव में ऐसा नहीं चाहते हैं यह।
• डेटा एकत्रित किया गया है सचमुच तेज.

हालांकि:

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

ड्र्यूड/पिनोट

विशेष रूप से टीएसडीबी के बारे में और भी बहुत कुछ है, लेकिन फिर से, Hadoop स्टैक।

वहाँ ड्र्यूड और पिनोट बनाम क्लिकहाउस के फायदे और नुकसान की तुलना करने वाला शानदार लेख .

कुछ शब्दों में: ड्र्यूड/पिनोट उन मामलों में क्लिकहाउस से बेहतर दिखता है जहां:

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

विपरीत मामलों में, ClickHouse बेहतर प्रदर्शन करता है, और यही हमारा मामला है।

क्लिकहाउस

• SQL जैसी
• प्रबंधन करना आसान है.
• लोग कहते हैं यह काम करता है.

परीक्षण के लिए शॉर्टलिस्ट किया जाता है।

इन्फ्लक्सडीबी

ClickHouse का एक विदेशी विकल्प। कमियों में से: उच्च उपलब्धता केवल व्यावसायिक संस्करण में मौजूद है, लेकिन इसकी तुलना करने की आवश्यकता है।

परीक्षण के लिए शॉर्टलिस्ट किया जाता है।

कैसांद्रा

एक ओर, हम जानते हैं कि इसका उपयोग ऐसी निगरानी प्रणालियों द्वारा मीट्रिक समय-श्रृंखला को संग्रहीत करने के लिए किया जाता है, उदाहरण के लिए, सिग्नलएफएक्स या ओकेमीटर. हालाँकि, विशिष्टताएँ हैं।

कैसेंड्रा पारंपरिक अर्थों में एक स्तंभ डेटाबेस नहीं है। यह एक पंक्ति दृश्य की तरह अधिक दिखता है, लेकिन प्रत्येक पंक्ति में स्तंभों की एक अलग संख्या हो सकती है, जिससे स्तंभ दृश्य को व्यवस्थित करना आसान हो जाता है। इस अर्थ में, यह स्पष्ट है कि 2 बिलियन कॉलम की सीमा के साथ, कुछ डेटा को कॉलम (और समान समय श्रृंखला) में संग्रहीत करना संभव है। उदाहरण के लिए, MySQL में 4096 कॉलम की सीमा है और यदि आप ऐसा करने का प्रयास करते हैं तो कोड 1117 के साथ त्रुटि का सामना करना आसान है।

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

प्रोमिथेउस

खैर, जिज्ञासा से बाहर, हमने प्रोमेथियस स्टोरेज के प्रदर्शन का परीक्षण करने का फैसला किया - बस यह समझने के लिए कि क्या हम मौजूदा समाधानों की तुलना में तेज़ या धीमे हैं और कितना।

परीक्षण पद्धति और परिणाम

इसलिए, हमने निम्नलिखित 5 कॉन्फ़िगरेशन में 6 डेटाबेस का परीक्षण किया: ClickHouse (1 नोड), ClickHouse (3 नोड्स के लिए वितरित तालिका), InfluxDB, Mysql 8, कैसेंड्रा (3 नोड्स) और प्रोमेथियस। परीक्षण योजना इस प्रकार है:

1. एक सप्ताह के लिए ऐतिहासिक डेटा अपलोड करें (प्रति दिन 840 मिलियन मूल्य; 208 हजार मीट्रिक);
2. हम एक रिकॉर्डिंग लोड उत्पन्न करते हैं (6 लोड मोड पर विचार किया गया, नीचे देखें);
3. रिकॉर्डिंग के समानांतर, हम समय-समय पर चार्ट के साथ काम करने वाले उपयोगकर्ता के अनुरोधों का अनुकरण करते हुए चयन करते हैं। चीजों को बहुत अधिक जटिल न करने के लिए, हमने एक सप्ताह के लिए 10 मेट्रिक्स (यानी सीपीयू ग्राफ़ पर कितने हैं) के लिए डेटा का चयन किया।

हम अपने मॉनिटरिंग एजेंट के व्यवहार का अनुकरण करके लोड करते हैं, जो प्रत्येक 15 सेकंड में एक बार प्रत्येक मीट्रिक को मान भेजता है। साथ ही, हम अलग-अलग चीजों में रुचि रखते हैं:

• मेट्रिक्स की कुल संख्या जिसमें डेटा लिखा गया है;
• एक मीट्रिक पर मान भेजने के लिए अंतराल;
• बैच का आकार।

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

इसके अलावा, प्राप्त डेटा की व्याख्या कैसे करें, इसे बेहतर ढंग से समझने के लिए, आइए कल्पना करें कि हम केवल मेट्रिक्स का एक समूह नहीं भेज रहे हैं, बल्कि मेट्रिक्स को सर्वर में व्यवस्थित किया गया है - प्रति सर्वर 125 मेट्रिक्स। यहां सर्वर बस एक आभासी इकाई है - बस यह समझने के लिए कि, उदाहरण के लिए, 10000 मीट्रिक लगभग 80 सर्वर के अनुरूप हैं।

और यहां, इन सबको ध्यान में रखते हुए, हमारे 6 डेटाबेस राइट लोड मोड हैं:

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

परीक्षण के परिणाम इस प्रकार हैं:

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

नतीजतन,: ClickHouse और InfluxDB ने खुद को सर्वश्रेष्ठ दिखाया है, लेकिन Influx का क्लस्टर केवल एंटरप्राइज़ संस्करण के आधार पर बनाया जा सकता है, जिसमें पैसे खर्च होते हैं, जबकि ClickHouse की लागत कुछ भी नहीं है और यह रूस में बना है। यह तर्कसंगत है कि संयुक्त राज्य अमेरिका में विकल्प संभवतः inInfluxDB के पक्ष में है, और हमारे देश में यह ClickHouse के पक्ष में है।

स्रोत: www.habr.com