आम्ही एकाधिक वेळ मालिका डेटाबेस कसे तपासले

गेल्या काही वर्षांमध्ये, वेळ-मालिका डेटाबेस एका विचित्र गोष्टीपासून (उच्च देखरेख प्रणालींमध्ये वापरल्या जाणार्‍या (आणि विशिष्ट उपायांशी जोडलेले) किंवा बिग डेटा प्रकल्पांमध्ये वापरल्या जाणार्‍या अत्यंत विशिष्ट गोष्टींमधून "ग्राहक उत्पादन" मध्ये बदलले आहेत. रशियन फेडरेशनच्या प्रदेशावर, यासाठी यांडेक्स आणि क्लिकहाऊसचे विशेष आभार मानले पाहिजेत. या क्षणापर्यंत, जर तुम्हाला मोठ्या प्रमाणात वेळ-मालिका डेटा संग्रहित करण्याची आवश्यकता असेल, तर तुम्हाला एकतर राक्षसी हॅडूप स्टॅक तयार करण्याची आणि त्याची देखभाल करण्याची किंवा प्रत्येक सिस्टमसाठी वैयक्तिक प्रोटोकॉलशी संवाद साधण्याची आवश्यकता होती.

असे दिसते की 2019 मध्ये TSDB वापरण्यायोग्य असलेल्या लेखात फक्त एक वाक्य असेल: "फक्त क्लिकहाऊस वापरा." पण... बारकावे आहेत.

खरंच, क्लिकहाऊस सक्रियपणे विकसित होत आहे, वापरकर्ता आधार वाढत आहे, आणि समर्थन खूप सक्रिय आहे, परंतु आम्ही क्लिकहाऊसच्या सार्वजनिक यशाचे ओलिस झालो आहोत, ज्याने इतर, कदाचित अधिक प्रभावी/विश्वसनीय उपायांची छाया केली आहे?

गेल्या वर्षाच्या सुरूवातीस, आम्ही आमच्या स्वतःच्या मॉनिटरिंग सिस्टमला पुन्हा काम करण्यास सुरुवात केली, ज्या दरम्यान डेटा संचयित करण्यासाठी योग्य डेटाबेस निवडण्याचा प्रश्न उद्भवला. मला या निवडीच्या इतिहासाबद्दल इथे बोलायचे आहे.

समस्येची निर्मिती

सर्व प्रथम, एक आवश्यक प्रस्तावना. आम्हाला आमच्या स्वतःच्या मॉनिटरिंग सिस्टमची गरज का आहे आणि ती कशी तयार केली गेली?

आम्ही 2008 मध्ये समर्थन सेवा प्रदान करण्यास सुरुवात केली आणि 2010 पर्यंत हे स्पष्ट झाले की क्लायंट इन्फ्रास्ट्रक्चरमध्ये होणार्‍या प्रक्रियांबद्दल त्या वेळी अस्तित्वात असलेल्या उपायांसह डेटा एकत्रित करणे कठीण झाले आहे (आम्ही बोलत आहोत, देव मला माफ करा, कॅक्टी, झब्बीक्स आणि उदयोन्मुख ग्रेफाइट).

आमच्या मुख्य आवश्यकता होत्या:

• समर्थन (त्या वेळी - डझनभर, आणि भविष्यात - शेकडो) क्लायंट एका सिस्टममध्ये आणि त्याच वेळी केंद्रीकृत अॅलर्ट व्यवस्थापन प्रणालीची उपस्थिती;
• अॅलर्ट सिस्टम व्यवस्थापित करण्यात लवचिकता (कर्तव्य अधिकारी, शेड्युलिंग, ज्ञान बेस दरम्यान अलर्ट वाढवणे);
• सखोल तपशील आलेख करण्याची क्षमता (जॅबिक्सने त्यावेळी चित्रांच्या स्वरूपात आलेख प्रस्तुत केले होते);
• मोठ्या प्रमाणात डेटाचे दीर्घकालीन संचयन (एक वर्ष किंवा अधिक) आणि ते द्रुतपणे पुनर्प्राप्त करण्याची क्षमता.

या लेखात आम्हाला शेवटच्या बिंदूमध्ये रस आहे.

स्टोरेजबद्दल बोलताना, आवश्यकता खालीलप्रमाणे होत्या:

• प्रणाली त्वरीत कार्य करणे आवश्यक आहे;
• सिस्टममध्ये SQL इंटरफेस असणे इष्ट आहे;
• सिस्टम स्थिर असणे आवश्यक आहे आणि सक्रिय वापरकर्ता आधार आणि समर्थन असणे आवश्यक आहे (एकदा आम्हाला MemcacheDB सारख्या प्रणालींना समर्थन देण्याची गरज भासली, जी यापुढे विकसित झाली नाही, किंवा MooseFS वितरित स्टोरेज, ज्याचा बग ट्रॅकर चीनी भाषेत ठेवला गेला होता: आमच्या प्रकल्पासाठी आम्ही ही कथा पुन्हा पुन्हा करू इच्छित नाही);
• CAP प्रमेयचे पालन: सुसंगतता (आवश्यक) - डेटा अद्ययावत असणे आवश्यक आहे, अलर्ट मॅनेजमेंट सिस्टमने नवीन डेटा प्राप्त करू नये आणि सर्व प्रकल्पांसाठी डेटा न येण्याबद्दल अलर्ट बाहेर काढावे अशी आमची इच्छा नाही; विभाजन सहिष्णुता (आवश्यक) - आम्हाला स्प्लिट ब्रेन सिस्टम मिळवायचे नाही; उपलब्धता (गंभीर नाही, सक्रिय प्रतिकृती असल्यास) - आम्ही कोड वापरून अपघात झाल्यास स्वतः बॅकअप सिस्टमवर स्विच करू शकतो.

विचित्रपणे, त्या वेळी MySQL आमच्यासाठी आदर्श उपाय ठरला. आमची डेटा रचना अत्यंत सोपी होती: सर्व्हर आयडी, काउंटर आयडी, टाइमस्टॅम्प आणि मूल्य; मोठ्या बफर पूलद्वारे हॉट डेटाचे जलद सॅम्पलिंग सुनिश्चित केले गेले आणि SSD द्वारे ऐतिहासिक डेटाचे सॅम्पलिंग सुनिश्चित केले गेले.

अशाप्रकारे, आम्ही डेटा पूर्णपणे प्रस्तुत होण्यापूर्वी दुसऱ्या 200 ms पर्यंत तपशीलांसह, नवीन दोन आठवड्यांच्या डेटाचा नमुना प्राप्त केला आणि या प्रणालीमध्ये बराच काळ जगलो.

दरम्यान, वेळ निघून गेला आणि डेटाचे प्रमाण वाढले. 2016 पर्यंत, डेटा व्हॉल्यूम दहापट टेराबाइट्सपर्यंत पोहोचला, जो भाड्याने घेतलेल्या SSD स्टोरेजच्या संदर्भात एक महत्त्वपूर्ण खर्च होता.

या वेळेपर्यंत, स्तंभीय डेटाबेस सक्रियपणे व्यापक बनले होते, ज्याचा आम्ही सक्रियपणे विचार करू लागलो: स्तंभ डेटाबेसमध्ये, डेटा संग्रहित केला जातो, जसे आपण समजू शकता, स्तंभांमध्ये, आणि आपण आमच्या डेटाकडे पाहिल्यास, मोठ्या प्रमाणात पाहणे सोपे आहे. डुप्लिकेटची संख्या जी, मध्ये जर तुम्ही स्तंभीय डेटाबेस वापरत असाल, तर ते कॉम्प्रेशन वापरून कॉम्प्रेस करा.

तथापि, कंपनीची मुख्य प्रणाली स्थिरपणे कार्य करत राहिली आणि मला दुसर्‍या गोष्टीवर स्विच करण्याचा प्रयोग करायचा नव्हता.

2017 मध्ये, सॅन जोस येथील पर्कोना लाइव्ह कॉन्फरन्समध्ये, क्लिकहाऊस डेव्हलपर्सनी कदाचित पहिल्यांदाच स्वतःची घोषणा केली. पहिल्या दृष्टीक्षेपात, प्रणाली उत्पादनासाठी तयार होती (तसेच, Yandex.Metrica एक कठोर उत्पादन प्रणाली आहे), समर्थन जलद आणि सोपे होते आणि, सर्वात महत्त्वाचे म्हणजे, ऑपरेशन सोपे होते. 2018 पासून, आम्ही संक्रमण प्रक्रिया सुरू केली आहे. पण तोपर्यंत, भरपूर "प्रौढ" आणि वेळ-चाचणी केलेल्या TSDB प्रणाली होत्या, आणि आमच्या गरजेनुसार, Clickhouse साठी पर्यायी उपाय नाहीत याची खात्री करण्यासाठी आम्ही बराच वेळ घालवण्याचा आणि पर्यायांची तुलना करण्याचे ठरवले.

आधीच निर्दिष्ट केलेल्या स्टोरेज आवश्यकतांव्यतिरिक्त, नवीन दिसल्या आहेत:

• नवीन प्रणालीने किमान त्याच प्रमाणात हार्डवेअरवर MySQL प्रमाणे कार्यप्रदर्शन प्रदान केले पाहिजे;
• नवीन सिस्टमच्या स्टोरेजने लक्षणीय कमी जागा घेतली पाहिजे;
• DBMS व्यवस्थापित करणे अद्याप सोपे असले पाहिजे;
• DBMS बदलताना मला ऍप्लिकेशन कमीत कमी बदलायचे होते.

आम्ही कोणत्या प्रणालींचा विचार करण्यास सुरुवात केली?

अपाचे पोळे/अपाचे इम्पाला
एक जुना, युद्ध-चाचणी केलेला Hadoop स्टॅक. मूलत:, हा एक एसक्यूएल इंटरफेस आहे जो HDFS वर नेटिव्ह फॉरमॅटमध्ये डेटा संचयित करण्याच्या शीर्षस्थानी तयार केला आहे.

साधक.

• स्थिर ऑपरेशनसह, डेटा स्केल करणे खूप सोपे आहे.
• डेटा स्टोरेजसाठी कॉलम सोल्यूशन्स आहेत (कमी जागा).
• संसाधने उपलब्ध असताना समांतर कार्यांची अतिशय जलद अंमलबजावणी.

उणे.

• हे Hadoop आहे, आणि ते वापरणे कठीण आहे. जर आम्ही क्लाउडमध्ये तयार उपाय घेण्यास तयार नसलो (आणि आम्ही किंमतीच्या बाबतीत तयार नसलो), तर संपूर्ण स्टॅक अॅडमिन्सच्या हातांनी एकत्र करून सपोर्ट करावा लागेल आणि आम्हाला खरोखर नको आहे. हे
• डेटा एकत्रित केला आहे खरोखर जलद.

परंतु:

संगणकीय सर्व्हरची संख्या मोजून गती प्राप्त केली जाते. सोप्या भाषेत सांगायचे तर, जर आम्ही एक मोठी कंपनी आहोत, विश्लेषणामध्ये गुंतलो आहोत आणि व्यवसायासाठी शक्य तितक्या लवकर माहिती एकत्रित करणे महत्वाचे आहे (मोठ्या प्रमाणात संगणकीय संसाधने वापरूनही), ही आमची निवड असू शकते. परंतु आम्ही कामांना गती देण्यासाठी हार्डवेअर फ्लीटमध्ये वाढ करण्यास तयार नव्हतो.

ड्रुइड/पिनोट

विशेषतः TSDB बद्दल बरेच काही आहे, परंतु पुन्हा, Hadoop स्टॅक.

आहेत Druid आणि Pinot विरुद्ध ClickHouse च्या साधक आणि बाधकांची तुलना करणारा उत्तम लेख .

काही शब्दांत: ड्रुइड/पिनोट क्लिकहाऊसपेक्षा अधिक चांगले दिसतात अशा प्रकरणांमध्ये:

• तुमच्याकडे डेटाचे विषम स्वरूप आहे (आमच्या बाबतीत, आम्ही सर्व्हर मेट्रिक्सची फक्त टाइमसीरीज रेकॉर्ड करतो, आणि खरं तर, हे एक टेबल आहे. परंतु इतर प्रकरणे असू शकतात: उपकरणे वेळ मालिका, आर्थिक वेळ मालिका इ. - प्रत्येकासह. त्याची स्वतःची रचना, ज्याची एकत्रित आणि प्रक्रिया करणे आवश्यक आहे).
• शिवाय, हा डेटा भरपूर आहे.
• वेळ मालिकेसह सारण्या आणि डेटा दिसतात आणि अदृश्य होतात (म्हणजेच, डेटाचा काही संच आला, विश्लेषित केला गेला आणि हटविला गेला).
• कोणताही स्पष्ट निकष नाही ज्याद्वारे डेटाचे विभाजन केले जाऊ शकते.

उलट प्रकरणांमध्ये, क्लिकहाऊस अधिक चांगले कार्य करते आणि हे आमचे प्रकरण आहे.

क्लिकहाऊस

• SQL सारखे
• व्यवस्थापित करणे सोपे.
• लोक म्हणतात ते काम करते.

चाचणीसाठी शॉर्टलिस्ट केले जाते.

InfluxDB

क्लिकहाऊससाठी परदेशी पर्याय. उणेंपैकी: उच्च उपलब्धता केवळ व्यावसायिक आवृत्तीमध्ये आहे, परंतु त्याची तुलना करणे आवश्यक आहे.

चाचणीसाठी शॉर्टलिस्ट केले जाते.

शरिरासाठी चांगलं असतं,

एकीकडे, आम्हाला माहित आहे की ते अशा मॉनिटरिंग सिस्टमद्वारे मेट्रिक टाइमसीरीज संचयित करण्यासाठी वापरले जाते, उदाहरणार्थ, सिग्नलएफएक्स किंवा OkMeter. तथापि, तेथे तपशील आहेत.

पारंपारिक अर्थाने कॅसॅंड्रा हा स्तंभीय डेटाबेस नाही. हे पंक्तीच्या दृश्यासारखे दिसते, परंतु प्रत्येक ओळीत स्तंभांची संख्या भिन्न असू शकते, ज्यामुळे स्तंभीय दृश्य व्यवस्थापित करणे सोपे होते. या अर्थाने, हे स्पष्ट आहे की 2 अब्ज स्तंभांच्या मर्यादेसह, स्तंभांमध्ये (आणि त्याच वेळेची मालिका) काही डेटा संग्रहित करणे शक्य आहे. उदाहरणार्थ, MySQL मध्ये 4096 स्तंभांची मर्यादा आहे आणि कोड 1117 सह त्रुटी आढळल्यास अडखळणे सोपे आहे.

कॅसॅन्ड्रा इंजिन मास्टरशिवाय वितरित प्रणालीमध्ये मोठ्या प्रमाणात डेटा संचयित करण्यावर केंद्रित आहे आणि वर नमूद केलेले कॅसॅन्ड्रा CAP प्रमेय AP बद्दल, म्हणजेच डेटाची उपलब्धता आणि विभाजनास प्रतिकार करण्याबद्दल आहे. अशा प्रकारे, जर तुम्हाला फक्त या डेटाबेसवर लिहायचे असेल आणि त्यातून क्वचितच वाचायचे असेल तर हे साधन उत्तम असू शकते. आणि येथे कॅसॅन्ड्राचा “कोल्ड” स्टोरेज म्हणून वापर करणे तर्कसंगत आहे. म्हणजे, क्वचितच आवश्‍यक असणारा, परंतु आवश्‍यकता भासल्‍यास पुन्‍हा मिळवता येणार्‍या मोठ्या प्रमाणात ऐतिहासिक डेटा साठवण्‍यासाठी दीर्घकालीन, विश्‍वासार्ह ठिकाण आहे. तरीसुद्धा, पूर्णतेसाठी, आम्ही त्याची चाचणी देखील करू. परंतु, मी आधी म्हटल्याप्रमाणे, निवडलेल्या डेटाबेस सोल्यूशनसाठी कोड सक्रियपणे पुन्हा लिहिण्याची इच्छा नाही, म्हणून आम्ही ते काहीसे मर्यादितपणे तपासू - डेटाबेस संरचना कॅसॅंड्राच्या वैशिष्ट्यांशी जुळवून न घेता.

Prometheus

बरं, उत्सुकतेपोटी, आम्ही प्रोमिथियस स्टोरेजच्या कार्यक्षमतेची चाचणी घेण्याचा निर्णय घेतला - फक्त हे समजून घेण्यासाठी की आम्ही सध्याच्या सोल्यूशन्सपेक्षा वेगवान आहोत की हळू आणि किती.

चाचणी पद्धत आणि परिणाम

म्हणून, आम्ही खालील 5 कॉन्फिगरेशनमध्ये 6 डेटाबेसेसची चाचणी केली: क्लिकहाऊस (1 नोड), क्लिकहाऊस (3 नोड्ससाठी वितरित टेबल), InfluxDB, Mysql 8, Cassandra (3 नोड्स) आणि Prometheus. चाचणी योजना खालीलप्रमाणे आहे:

1. एका आठवड्यासाठी ऐतिहासिक डेटा अपलोड करा (दररोज 840 दशलक्ष मूल्ये; 208 हजार मेट्रिक्स);
2. आम्ही रेकॉर्डिंग लोड व्युत्पन्न करतो (6 लोड मोड विचारात घेतले होते, खाली पहा);
3. रेकॉर्डिंगच्या समांतर, आम्ही चार्टसह काम करणार्‍या वापरकर्त्याच्या विनंत्यांचे अनुकरण करून वेळोवेळी निवडी करतो. गोष्टी जास्त क्लिष्ट होऊ नयेत म्हणून, आम्ही एका आठवड्यासाठी 10 मेट्रिक्ससाठी डेटा निवडला (म्हणजेच CPU आलेखावर किती आहेत).

आम्ही आमच्या मॉनिटरिंग एजंटच्या वर्तनाचे अनुकरण करून लोड करतो, जे प्रत्येक मेट्रिकला प्रत्येक 15 सेकंदात एकदा मूल्ये पाठवते. त्याच वेळी, आम्हाला बदलण्यात स्वारस्य आहे:

• मेट्रिक्सची एकूण संख्या ज्यामध्ये डेटा लिहिलेला आहे;
• एका मेट्रिकवर मूल्ये पाठवण्यासाठी मध्यांतर;
• बॅच आकार.

बॅच आकार बद्दल. आमचा जवळजवळ सर्व प्रायोगिक डेटाबेस सिंगल इन्सर्टसह लोड करण्याची शिफारस केलेली नसल्यामुळे, आम्हाला एक रिले आवश्यक असेल जो येणारे मेट्रिक्स गोळा करेल आणि त्यांना गटांमध्ये गट करेल आणि बॅच इन्सर्ट म्हणून डेटाबेसमध्ये लिहेल.

तसेच, प्राप्त झालेल्या डेटाचा अर्थ कसा लावायचा हे अधिक चांगल्या प्रकारे समजून घेण्यासाठी, कल्पना करूया की आम्ही फक्त मेट्रिक्सचा एक समूह पाठवत नाही, तर मेट्रिक्स सर्व्हरमध्ये व्यवस्थापित केल्या आहेत - प्रति सर्व्हर 125 मेट्रिक्स. येथे सर्व्हर फक्त एक आभासी अस्तित्व आहे - फक्त हे समजून घेण्यासाठी, उदाहरणार्थ, 10000 मेट्रिक्स सुमारे 80 सर्व्हरशी संबंधित आहेत.

आणि येथे, हे सर्व लक्षात घेऊन, आमचे 6 डेटाबेस लेखन लोड मोड आहेत:

येथे दोन मुद्दे आहेत. प्रथम, कॅसॅन्ड्रासाठी हे बॅच आकार खूप मोठे असल्याचे दिसून आले, तेथे आम्ही 50 किंवा 100 ची मूल्ये वापरली. आणि दुसरे म्हणजे, प्रोमिथियस पुल मोडमध्ये कठोरपणे कार्य करत असल्याने, उदा. तो स्वतः जातो आणि मेट्रिक्स स्त्रोतांकडून डेटा संकलित करतो (आणि पुशगेटवे देखील, नाव असूनही, परिस्थिती मूलभूतपणे बदलत नाही), संबंधित लोड स्थिर कॉन्फिगरेशनच्या संयोजनाचा वापर करून लागू केले गेले.

चाचणी परिणाम खालीलप्रमाणे आहेत:

काय लक्षात घेण्यासारखे आहे: प्रोमिथियसचे विलक्षण वेगवान नमुने, कॅसॅंड्राचे कमालीचे मंद नमुने, इन्फ्लक्सडीबीचे अस्वीकार्यपणे हळू नमुने; रेकॉर्डिंग गतीच्या बाबतीत, क्लिकहाऊसने प्रत्येकजण जिंकला आणि प्रोमिथियस स्पर्धेत भाग घेत नाही, कारण तो स्वतःच इन्सर्ट करतो आणि आम्ही काहीही मोजत नाही.

शेवटी: ClickHouse आणि InfluxDB यांनी स्वतःला सर्वोत्कृष्ट असल्याचे दाखवले, परंतु Influx मधील क्लस्टर केवळ एंटरप्राइझ आवृत्तीच्या आधारावर तयार केले जाऊ शकते, ज्यासाठी पैसे खर्च होतात, तर ClickHouse ला काहीही लागत नाही आणि ते रशियामध्ये बनवले जाते. हे तर्कसंगत आहे की यूएसएमध्ये निवड कदाचित इनफ्लक्सडीबीच्या बाजूने आहे आणि आपल्या देशात ती क्लिकहाऊसच्या बाजूने आहे.

स्त्रोत: www.habr.com