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

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

ऐसा लग सकता है कि 2019 में, एक लेख जिसके बारे में TSDB का उपयोग किया जाना चाहिए, में केवल एक वाक्य शामिल होगा: "बस ClickHouse का उपयोग करें"। लेकिन ... बारीकियां हैं।

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

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

समस्या का बयान

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

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

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

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

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

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

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

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



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

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

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



हालांकि, कंपनी के काम के लिए प्रमुख प्रणाली लगातार काम करती रही, और मैं कुछ और करने के लिए संक्रमण के साथ प्रयोग नहीं करना चाहता था।

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

पहले से ही इंगित की गई भंडारण आवश्यकताओं के अलावा, ताजा वाले दिखाई दिए:

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

हम किन प्रणालियों पर विचार करने लगे

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

पेशेवरों।

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

विपक्ष।

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

हालांकि:



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

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

TSDB के बारे में विशेष रूप से पहले से ही बहुत अधिक है, लेकिन फिर से - Hadoop-stack।

ClickHouse की तुलना में ड्र्यूड और पिनोट के पेशेवरों और विपक्षों की तुलना में एक शानदार लेख है ।

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

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

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

ClickHouse

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

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

InfluxDB

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

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

कैसेंड्रा

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

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

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

प्रोमेथियस

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

कार्यप्रणाली और परीक्षा परिणाम

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

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

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

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

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

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

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



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

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







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

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