VictoriaMetrics मध्ये ऑप्टिमायझेशनवर जा. अलेक्झांडर वाल्याल्किन

मी तुम्हाला अलेक्झांडर व्हॅल्याल्किनच्या 2019 च्या उत्तरार्धाच्या अहवालाचा उतारा वाचण्याचा सल्ला देतो “व्हिक्टोरियामेट्रिक्समध्ये ऑप्टिमायझेशन करा”

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

या अहवालाच्या व्हिडिओची ही लिंक - https://youtu.be/MZ5P21j_HLE

स्लाइड

स्वत: बद्दल सांगा. मी अलेक्झांडर वाल्याल्किन आहे. येथे माझे GitHub खाते. मी गो आणि परफॉर्मन्स ऑप्टिमायझेशनबद्दल उत्कट आहे. मी खूप उपयुक्त आणि तितकी उपयुक्त नसलेली लायब्ररी लिहिली. ते एकतर सुरू करतात fast, किंवा सह quick उपसर्ग

मी सध्या VictoriaMetrics वर काम करत आहे. ते काय आहे आणि मी तिथे काय करत आहे? मी या सादरीकरणात याबद्दल बोलणार आहे.

अहवालाची रूपरेषा खालीलप्रमाणे आहे.

• प्रथम, मी तुम्हाला व्हिक्टोरियामेट्रिक्स काय आहे ते सांगेन.
• मग मी तुम्हाला वेळ मालिका काय आहे ते सांगेन.
• मग मी तुम्हाला टाईम सीरीज डेटाबेस कसा काम करतो ते सांगेन.
• पुढे, मी तुम्हाला डेटाबेस आर्किटेक्चरबद्दल सांगेन: त्यात काय समाविष्ट आहे.
• आणि मग व्हिक्टोरियामेट्रिक्सच्या ऑप्टिमायझेशनकडे वळूया. हे इनव्हर्टेड इंडेक्ससाठी ऑप्टिमायझेशन आहे आणि Go मधील बिटसेट अंमलबजावणीसाठी ऑप्टिमायझेशन आहे.

व्हिक्टोरियामेट्रिक्स म्हणजे काय हे प्रेक्षकांमधील कोणाला माहीत आहे का? व्वा, बर्‍याच लोकांना आधीच माहित आहे. ही एक चांगली बातमी आहे. ज्यांना माहित नाही त्यांच्यासाठी हा टाइम सीरीज डेटाबेस आहे. हे क्लिकहाऊसच्या अंमलबजावणीच्या काही तपशीलांवर क्लिकहाऊस आर्किटेक्चरवर आधारित आहे. उदाहरणार्थ, जसे की: MergeTree, सर्व उपलब्ध प्रोसेसर कोरची समांतर गणना आणि प्रोसेसर कॅशेमध्ये ठेवलेल्या डेटा ब्लॉक्सवर कार्य करून कार्यप्रदर्शन ऑप्टिमायझेशन.

VictoriaMetrics इतर टाइम सीरीज डेटाबेसपेक्षा चांगले डेटा कॉम्प्रेशन प्रदान करते.

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

VictoriaMetrics देखील क्षैतिजरित्या स्केल करते - म्हणजेच, तुम्ही VictoriaMetrics क्लस्टरमध्ये अतिरिक्त नोड जोडू शकता आणि त्याचे कार्यप्रदर्शन जवळजवळ रेषीयरित्या वाढेल.

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

वेळ मालिका म्हणजे काय कोणास ठाऊक? तोही अनेकांना ओळखतो. वेळ मालिका ही जोड्यांची मालिका आहे (timestamp, значение), जेथे या जोड्या वेळेनुसार क्रमवारी लावल्या जातात. मूल्य एक फ्लोटिंग पॉइंट क्रमांक आहे - फ्लोट64.

प्रत्येक वेळी मालिका विशिष्टपणे की द्वारे ओळखली जाते. या किल्लीमध्ये काय समाविष्ट आहे? यात की-व्हॅल्यू जोड्यांचा रिक्त नसलेला संच असतो.

येथे वेळ मालिकेचे उदाहरण आहे. या मालिकेची मुख्य जोड्यांची यादी आहे: __name__="cpu_usage" मेट्रिकचे नाव आहे, instance="my-server" - हा तो संगणक आहे ज्यावर हे मेट्रिक गोळा केले जाते, datacenter="us-east" - हे डेटा सेंटर आहे जिथे हा संगणक आहे.

आम्ही तीन की-व्हॅल्यू जोड्यांचा समावेश असलेल्या टाइम सीरीज नावासह समाप्त झालो. ही की जोड्यांच्या सूचीशी संबंधित आहे (timestamp, value). t1, t3, t3, ..., tN - हे टाइमस्टॅम्प आहेत, 10, 20, 12, ..., 15 - संबंधित मूल्ये. दिलेल्या मालिकेसाठी दिलेल्या वेळी हा cpu-वापर आहे.

वेळ मालिका कुठे वापरली जाऊ शकते? कोणाला काही कल्पना आहे का?

• DevOps मध्ये, तुम्ही CPU, RAM, नेटवर्क, rps, त्रुटींची संख्या इत्यादी मोजू शकता.
• IoT - आम्ही तापमान, दाब, भौगोलिक निर्देशांक आणि इतर काहीतरी मोजू शकतो.
• तसेच वित्त - आम्ही सर्व प्रकारच्या स्टॉक आणि चलनांच्या किमतींचे परीक्षण करू शकतो.
• याव्यतिरिक्त, कारखान्यांमधील उत्पादन प्रक्रियेचे निरीक्षण करण्यासाठी वेळ मालिका वापरली जाऊ शकते. आमच्याकडे असे वापरकर्ते आहेत जे रोबोटसाठी पवन टर्बाइनचे निरीक्षण करण्यासाठी VictoriaMetrics वापरतात.
• वेळ मालिका विविध उपकरणांच्या सेन्सरमधून माहिती गोळा करण्यासाठी देखील उपयुक्त आहे. उदाहरणार्थ, इंजिनसाठी; टायरचा दाब मोजण्यासाठी; वेग, अंतर मोजण्यासाठी; गॅसोलीन वापर मोजण्यासाठी, इ.
• टाइम सीरिजचा वापर विमानांवर नजर ठेवण्यासाठीही करता येतो. प्रत्येक विमानात एक ब्लॅक बॉक्स असतो जो विमानाच्या आरोग्याच्या विविध पॅरामीटर्ससाठी वेळ मालिका गोळा करतो. एरोस्पेस उद्योगातही टाइम सीरीज वापरली जातात.
• आरोग्यसेवा म्हणजे रक्तदाब, नाडी इ.

मी विसरलो असे आणखी काही अनुप्रयोग असू शकतात, परंतु मला आशा आहे की आधुनिक जगात वेळ मालिका सक्रियपणे वापरली जाते हे तुम्हाला समजले असेल. आणि त्यांच्या वापराचे प्रमाण दरवर्षी वाढत आहे.

तुम्हाला टाइम सीरीज डेटाबेस का आवश्यक आहे? आपण वेळ मालिका संग्रहित करण्यासाठी नियमित रिलेशनल डेटाबेस का वापरू शकत नाही?

कारण वेळ मालिकेत सहसा मोठ्या प्रमाणात माहिती असते, जी परंपरागत डेटाबेसमध्ये संग्रहित करणे आणि प्रक्रिया करणे कठीण असते. म्हणून, वेळ मालिकेसाठी विशेष डेटाबेस दिसू लागले. हे बेस प्रभावीपणे गुण साठवतात (timestamp, value) दिलेल्या की सह. ते की, एकल की-व्हॅल्यू जोडीद्वारे, किंवा एकाधिक की-व्हॅल्यू जोडीद्वारे किंवा regexp द्वारे संग्रहित डेटा वाचण्यासाठी API प्रदान करतात. उदाहरणार्थ, तुम्हाला तुमच्या सर्व सेवांचा CPU लोड अमेरिकेतील डेटा सेंटरमध्ये शोधायचा आहे, तर तुम्हाला ही स्यूडो-क्वेरी वापरण्याची आवश्यकता आहे.

सामान्यत: वेळ मालिका डेटाबेस विशेष क्वेरी भाषा प्रदान करतात कारण वेळ मालिका SQL फारशी अनुकूल नाही. SQL ला समर्थन देणारे डेटाबेस असले तरी ते फारसे योग्य नाही. प्रश्न भाषा जसे की PromQL, InfluxQL, प्रवाह, Q. मला आशा आहे की कोणीतरी यापैकी किमान एक भाषा ऐकली असेल. अनेक लोकांनी PromQL बद्दल ऐकले असेल. ही प्रोमिथियस क्वेरी भाषा आहे.

उदाहरण म्हणून व्हिक्टोरियामेट्रिक्स वापरून आधुनिक वेळ मालिका डेटाबेस आर्किटेक्चर असे दिसते.

त्यात दोन भाग असतात. हे इन्व्हर्टेड इंडेक्ससाठी स्टोरेज आणि टाइम सीरिज व्हॅल्यूजसाठी स्टोरेज आहे. हे भांडार वेगळे केले जातात.

डेटाबेसमध्ये नवीन रेकॉर्ड आल्यावर, दिलेल्या सेटसाठी वेळ मालिका अभिज्ञापक शोधण्यासाठी आम्ही प्रथम इनव्हर्टेड इंडेक्समध्ये प्रवेश करतो. label=value दिलेल्या मेट्रिकसाठी. आम्हाला हा अभिज्ञापक सापडतो आणि डेटा स्टोअरमध्ये मूल्य जतन करतो.

जेव्हा TSDB कडून डेटा पुनर्प्राप्त करण्याची विनंती येते, तेव्हा आम्ही प्रथम इनव्हर्टेड इंडेक्सवर जातो. चला सर्वकाही मिळवूया timeseries_ids या सेटशी जुळणारे रेकॉर्ड label=value. आणि मग आम्हाला डेटा वेअरहाऊसमधून सर्व आवश्यक डेटा मिळतो, द्वारे अनुक्रमित timeseries_ids.

टाइम सीरीज डेटाबेस इनकमिंग सिलेक्ट क्वेरीवर प्रक्रिया कशी करतो याचे उदाहरण पाहू.

• सर्वप्रथम तिला सर्व काही मिळते timeseries_ids दिलेल्या जोड्या असलेल्या एका उलट्या निर्देशांकातून label=value, किंवा दिलेल्या नियमित अभिव्यक्तीचे समाधान करा.
• मग ते सापडलेल्यांसाठी दिलेल्या वेळेच्या अंतराने डेटा स्टोरेजमधून सर्व डेटा पॉइंट्स पुनर्प्राप्त करते timeseries_ids.
• यानंतर, वापरकर्त्याच्या विनंतीनुसार डेटाबेस या डेटा पॉइंट्सवर काही गणना करतो. आणि त्यानंतर तो उत्तर देतो.

या सादरीकरणात मी तुम्हाला पहिल्या भागाबद्दल सांगेन. हा शोध आहे timeseries_ids उलटा निर्देशांक द्वारे. दुसरा भाग आणि तिसरा भाग तुम्ही नंतर पाहू शकता VictoriaMetrics स्रोत, किंवा मी इतर अहवाल तयार करेपर्यंत प्रतीक्षा करा :)

चला उलटा निर्देशांकाकडे जाऊया. अनेकांना हे सोपे वाटेल. इन्व्हर्टेड इंडेक्स म्हणजे काय आणि ते कसे कार्य करते हे कोणाला माहीत आहे? अरे, आता इतके लोक नाहीत. ते काय आहे ते समजून घेण्याचा प्रयत्न करूया.

हे प्रत्यक्षात सोपे आहे. हा फक्त एक शब्दकोष आहे जो मूल्याची की मॅप करतो. चावी म्हणजे काय? हे जोडपे label=valueकुठे label и value - या ओळी आहेत. आणि मूल्ये एक संच आहेत timeseries_ids, ज्यामध्ये दिलेल्या जोडीचा समावेश आहे label=value.

इन्व्हर्टेड इंडेक्स आपल्याला सर्वकाही द्रुतपणे शोधण्याची परवानगी देते timeseries_ids, जे दिले आहेत label=value.

हे आपल्याला द्रुतपणे शोधण्याची देखील परवानगी देते timeseries_ids अनेक जोड्यांसाठी वेळ मालिका label=value, किंवा जोडप्यांसाठी label=regexp. हे कसे घडते? संचाचा छेदनबिंदू शोधून timeseries_ids प्रत्येक जोडीसाठी label=value.

इनव्हर्टेड इंडेक्सची विविध अंमलबजावणी पाहू. चला सर्वात सोप्या साध्या अंमलबजावणीसह प्रारंभ करूया. ती अशी दिसते.

कार्य getMetricIDs तारांची यादी मिळते. प्रत्येक ओळीत समाविष्ट आहे label=value. हे फंक्शन सूची परत करते metricIDs.

हे कसे कार्य करते? येथे आपल्याकडे ग्लोबल व्हेरिएबल आहे invertedIndex. हा एक नियमित शब्दकोश आहे (map), जे इंट्सचे तुकडे करण्यासाठी स्ट्रिंग मॅप करेल. ओळ समाविष्टीत आहे label=value.

कार्य अंमलबजावणी: मिळवा metricIDs पहिल्यासाठी label=value, मग आम्ही इतर सर्व गोष्टींमधून जातो label=value, आम्हाला ते मिळते metricIDs त्यांच्यासाठी. आणि फंक्शनला कॉल करा intersectInts, ज्याची खाली चर्चा केली जाईल. आणि हे फंक्शन या सूचींचे छेदनबिंदू परत करते.

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

दुसरी कमतरता देखील स्मरणशक्तीशी संबंधित आहे. उलटा निर्देशांक RAM मध्ये बसला पाहिजे. जर ते RAM च्या आकारापेक्षा जास्त असेल तर स्पष्टपणे आम्हाला मिळेल - मेमरी त्रुटी बाहेर. आणि कार्यक्रम चालणार नाही.

ही समस्या तयार-तयार उपाय वापरून सोडवली जाऊ शकते जसे की लेव्हलडीबी, किंवा रॉक्सडीबी.

थोडक्यात, आम्हाला एक डेटाबेस हवा आहे जो आम्हाला तीन ऑपरेशन्स त्वरीत करू देतो.

• पहिले ऑपरेशन रेकॉर्डिंग आहे ключ-значение या डेटाबेसला. ती हे खूप पटकन करते, कुठे ключ-значение अनियंत्रित तार आहेत.
• दुसरे ऑपरेशन म्हणजे दिलेल्या की वापरून मूल्याचा द्रुत शोध.
• आणि तिसरे ऑपरेशन हे दिलेल्या उपसर्गाद्वारे सर्व मूल्यांसाठी द्रुत शोध आहे.

LevelDB आणि RocksDB - हे डेटाबेस Google आणि Facebook ने विकसित केले होते. प्रथम LevelDB आला. मग फेसबुकच्या लोकांनी लेव्हलडीबी घेतला आणि त्यात सुधारणा करायला सुरुवात केली, त्यांनी रॉक्सडीबी बनवला. आता जवळजवळ सर्व अंतर्गत डेटाबेस RocksDB आणि MySQL वर हस्तांतरित केलेल्यांसह Facebook मध्ये RocksDB वर कार्य करतात. त्यांनी त्याचे नाव ठेवले मायरॉक्स.

लेव्हलडीबी वापरून एक उलटा निर्देशांक लागू केला जाऊ शकतो. ते कसे करायचे? आम्ही की म्हणून सेव्ह करतो label=value. आणि मूल्य हे जोडी उपस्थित असलेल्या वेळेच्या मालिकेचे अभिज्ञापक आहे label=value.

आमच्याकडे दिलेल्या जोडीसह अनेक वेळा मालिका असल्यास label=value, नंतर या डेटाबेसमध्ये समान की आणि भिन्न असलेल्या अनेक पंक्ती असतील timeseries_ids. सर्वांची यादी मिळवण्यासाठी timeseries_ids, जे यापासून सुरू होते label=prefix, आम्ही रेंज स्कॅन करतो ज्यासाठी हा डेटाबेस ऑप्टिमाइझ केला जातो. म्हणजेच, आम्ही सुरू होणाऱ्या सर्व ओळी निवडतो label=prefix आणि आवश्यक मिळवा timeseries_ids.

गो मध्ये ते कसे दिसेल याचा नमुना अंमलबजावणी येथे आहे. आमच्याकडे एक उलटा निर्देशांक आहे. हे LevelDB आहे.

फंक्शन निष्पाप अंमलबजावणीसाठी समान आहे. हे जवळजवळ ओळीने सरळ सरळ अंमलबजावणीची पुनरावृत्ती करते. मुद्दा एवढाच की वळण्याऐवजी map आम्ही इनव्हर्टेड इंडेक्समध्ये प्रवेश करतो. आम्हाला पहिल्यासाठी सर्व मूल्ये मिळतात label=value. मग आम्ही उर्वरित सर्व जोड्यांमधून जातो label=value आणि त्यांच्यासाठी मेट्रिकआयडीचे संबंधित संच मिळवा. मग आपल्याला छेदनबिंदू सापडतो.

सर्व काही ठीक आहे असे दिसते, परंतु या सोल्यूशनमध्ये तोटे आहेत. VictoriaMetrics ने सुरुवातीला LevelDB वर आधारित एक उलटा निर्देशांक लागू केला. पण शेवटी मला ते सोडून द्यावे लागले.

का? कारण लेव्हलडीबी निरागस अंमलबजावणीपेक्षा हळू आहे. साध्या अंमलबजावणीमध्ये, दिलेली की दिली, आम्ही ताबडतोब संपूर्ण स्लाइस पुनर्प्राप्त करतो metricIDs. हे एक अतिशय जलद ऑपरेशन आहे - संपूर्ण स्लाइस वापरासाठी तयार आहे.

LevelDB मध्ये, प्रत्येक वेळी फंक्शन कॉल केले जाते GetValues तुम्हाला सुरू होणाऱ्या सर्व ओळींमधून जाणे आवश्यक आहे label=value. आणि प्रत्येक ओळीचे मूल्य मिळवा timeseries_ids. च्या अशा timeseries_ids यापैकी एक तुकडा गोळा करा timeseries_ids. स्पष्टपणे, की द्वारे नियमित नकाशावर प्रवेश करण्यापेक्षा हे खूपच हळू आहे.

दुसरा दोष म्हणजे LevelDB C मध्ये लिहिलेला आहे. Go वरून C फंक्शन्स कॉल करणे फार वेगवान नाही. यास शेकडो नॅनोसेकंद लागतात. हे फार वेगवान नाही, कारण गो मध्ये लिहिलेल्या नियमित फंक्शन कॉलच्या तुलनेत, ज्याला 1-5 नॅनोसेकंद लागतात, कामगिरीतील फरक दहापट आहे. VictoriaMetrics साठी हा एक घातक दोष होता :)

म्हणून मी इन्व्हर्टेड इंडेक्सची माझी स्वतःची अंमलबजावणी लिहिली. आणि त्याने तिला हाक मारली विलीन करा.

Mergeset MergeTree डेटा स्ट्रक्चरवर आधारित आहे. ही डेटा रचना ClickHouse कडून घेतली आहे. अर्थात, जलद शोधासाठी विलीनीकरण ऑप्टिमाइझ केले पाहिजे timeseries_ids दिलेल्या की नुसार. मर्जसेट पूर्णपणे गो मध्ये लिहिलेले आहे. आपण पाहू शकता GitHub वर VictoriaMetrics स्रोत. मर्जसेटची अंमलबजावणी फोल्डरमध्ये आहे /lib/mergeset. तुम्ही तिथे काय चालले आहे ते शोधण्याचा प्रयत्न करू शकता.

मर्जसेट API हे LevelDB आणि RocksDB सारखेच आहे. म्हणजेच, ते तुम्हाला तेथे नवीन रेकॉर्ड त्वरीत जतन करण्यास आणि दिलेल्या उपसर्गाद्वारे रेकॉर्ड द्रुतपणे निवडण्याची परवानगी देते.

मर्जसेटच्या तोट्यांबद्दल आपण नंतर बोलू. आता इनव्हर्टेड इंडेक्स लागू करताना उत्पादनामध्ये व्हिक्टोरियामेट्रिक्समध्ये कोणत्या समस्या उद्भवल्या याबद्दल बोलूया.

ते का उद्भवले?

पहिले कारण म्हणजे उच्च मंथन दर. रशियन भाषेत अनुवादित, हा वेळ मालिकेतील वारंवार बदल आहे. ही वेळ मालिका संपते आणि नवीन मालिका सुरू होते किंवा अनेक नवीन वेळ मालिका सुरू होतात. आणि हे अनेकदा घडते.

दुसरे कारण म्हणजे मोठ्या संख्येने वेळ मालिका. सुरुवातीला, जेव्हा देखरेख लोकप्रिय होत होती, तेव्हा वेळ मालिकेची संख्या कमी होती. उदाहरणार्थ, प्रत्येक संगणकासाठी आपल्याला CPU, मेमरी, नेटवर्क आणि डिस्क लोडचे निरीक्षण करणे आवश्यक आहे. प्रति संगणक 4 वेळा मालिका. समजा तुमच्याकडे 100 संगणक आणि 400 वेळ मालिका आहेत. हे फार थोडे आहे.

कालांतराने, लोकांना समजले की ते अधिक दाणेदार माहिती मोजू शकतात. उदाहरणार्थ, संपूर्ण प्रोसेसरचे नव्हे तर प्रत्येक प्रोसेसर कोरचे भार स्वतंत्रपणे मोजा. तुमच्याकडे 40 प्रोसेसर कोर असल्यास, प्रोसेसर लोड मोजण्यासाठी तुमच्याकडे 40 पट जास्त वेळ आहे.

पण एवढेच नाही. प्रत्येक प्रोसेसर कोरमध्ये निष्क्रिय सारख्या अनेक अवस्था असू शकतात, जेव्हा ते निष्क्रिय असते. आणि युजर स्पेसमध्येही काम करा, कर्नल स्पेस आणि इतर राज्यांमध्ये काम करा. आणि अशी प्रत्येक अवस्था वेगळी वेळ मालिका म्हणून देखील मोजली जाऊ शकते. हे याव्यतिरिक्त पंक्तींची संख्या 7-8 पट वाढवते.

एका मेट्रिकमधून आम्हाला फक्त एका संगणकासाठी 40 x 8 = 320 मेट्रिक्स मिळाले. 100 ने गुणाकार केल्यास 32 ऐवजी 000 मिळतील.

मग कुबर्नेट्स सोबत आले. आणि ते आणखी वाईट झाले कारण Kubernetes अनेक भिन्न सेवा होस्ट करू शकतात. कुबर्नेट्समधील प्रत्येक सेवेमध्ये अनेक शेंगा असतात. आणि हे सर्व निरीक्षण करणे आवश्यक आहे. याव्यतिरिक्त, आमच्याकडे तुमच्या सेवांच्या नवीन आवृत्त्यांचा सतत उपयोजन आहे. प्रत्येक नवीन आवृत्तीसाठी, नवीन वेळ मालिका तयार करणे आवश्यक आहे. परिणामी, वेळ मालिकेची संख्या झपाट्याने वाढते आणि आम्हाला मोठ्या संख्येने टाइम सीरिजच्या समस्येचा सामना करावा लागतो, ज्याला उच्च-कार्डिनॅलिटी म्हणतात. व्हिक्टोरियामेट्रिक्स इतर टाइम सीरीज डेटाबेसच्या तुलनेत यशस्वीपणे त्याचा सामना करते.

चला उच्च मंथन दर जवळून पाहू. उत्पादनात उच्च मंथन दर कशामुळे होतो? कारण लेबल आणि टॅगचे काही अर्थ सतत बदलत असतात.

उदाहरणार्थ, कुबर्नेट्स घ्या, ज्याची संकल्पना आहे deployment, म्हणजे जेव्हा तुमच्या अर्जाची नवीन आवृत्ती आणली जाते. काही कारणास्तव, Kubernetes विकासकांनी लेबलमध्ये उपयोजन आयडी जोडण्याचा निर्णय घेतला.

यातून काय घडले? शिवाय, प्रत्येक नवीन उपयोजनासह, सर्व जुन्या वेळ मालिका व्यत्यय आणल्या जातात आणि त्याऐवजी, नवीन वेळ मालिका नवीन लेबल मूल्यासह सुरू होते. deployment_id. अशा शेकडो हजारो आणि लाखो पंक्ती असू शकतात.

या सर्वांबद्दल महत्त्वाची गोष्ट अशी आहे की एकूण वेळ मालिकेची संख्या वाढते, परंतु सध्या सक्रिय असलेल्या आणि डेटा प्राप्त करणार्‍या वेळ मालिकांची संख्या स्थिर आहे. या अवस्थेला उच्च मंथन दर म्हणतात.

उच्च मंथन दराची मुख्य समस्या म्हणजे ठराविक वेळेच्या अंतराने दिलेल्या लेबलच्या सेटसाठी सर्व वेळच्या मालिकेसाठी सतत शोध गती सुनिश्चित करणे. सामान्यतः हा शेवटचा तास किंवा शेवटचा दिवस असतो.

ही समस्या कशी सोडवायची? हा पहिला पर्याय आहे. हे उलटे निर्देशांक कालांतराने स्वतंत्र भागांमध्ये विभागणे आहे. म्हणजेच, काही वेळ मध्यांतर होऊन, आम्ही वर्तमान उलट्या निर्देशांकासह कार्य पूर्ण करतो. आणि एक नवीन उलटा निर्देशांक तयार करा. आणखी एक वेळ मध्यांतर पास होईल, आम्ही दुसरे आणि दुसरे तयार करतो.

आणि या उलट्या निर्देशांकांचे नमुने घेताना, दिलेल्या मध्यांतरात येणारा उलटा निर्देशांकांचा संच आपल्याला आढळतो. आणि, त्यानुसार, आम्ही तेथून वेळ मालिकेचा आयडी निवडतो.

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

या समस्येचे निराकरण करण्यासाठी आणखी एक पर्याय आहे. हे प्रत्येक दिवसासाठी त्या दिवशी झालेल्या टाइम सीरीजच्या आयडींची स्वतंत्र यादी संग्रहित करण्यासाठी आहे.

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

गैरसोय असा आहे की असा उपाय अंमलात आणणे अधिक कठीण आणि डीबग करणे अधिक कठीण आहे. आणि VictoriaMetrics ने हा उपाय निवडला. ऐतिहासिकदृष्ट्या हे असेच घडले. हे समाधान देखील मागील एकाच्या तुलनेत चांगले कार्य करते. कारण बदल न होणाऱ्या, म्हणजेच कालांतराने अदृश्य न होणाऱ्या टाइम सीरिजसाठी प्रत्येक विभाजनामध्ये डेटा डुप्लिकेट करणे आवश्यक आहे या वस्तुस्थितीमुळे हे समाधान लागू केले गेले नाही. VictoriaMetrics हे प्रामुख्याने डिस्क स्पेसच्या वापरासाठी ऑप्टिमाइझ केले गेले होते आणि मागील अंमलबजावणीमुळे डिस्क स्पेसचा वापर अधिक वाईट झाला. परंतु ही अंमलबजावणी डिस्क जागेचा वापर कमी करण्यासाठी अधिक योग्य आहे, म्हणून ते निवडले गेले.

मला तिच्याशी लढावे लागले. संघर्ष असा होता की या अंमलबजावणीमध्ये तुम्हाला अजून खूप मोठी संख्या निवडायची आहे timeseries_ids जेव्हा इन्व्हर्टेड इंडेक्सचे विभाजन केले जाते तेव्हापेक्षा डेटासाठी.

आम्ही ही समस्या कशी सोडवली? आम्ही मूळ मार्गाने याचे निराकरण केले - प्रत्येक इन्व्हर्टेड इंडेक्स एंट्रीमध्ये एका आयडेंटिफायरऐवजी अनेक वेळा मालिका अभिज्ञापक संचयित करून. म्हणजेच आमच्याकडे एक किल्ली आहे label=value, जे प्रत्येक वेळेच्या मालिकेत आढळते. आणि आता आम्ही अनेक वाचवतो timeseries_ids एका नोंदीमध्ये.

येथे एक उदाहरण आहे. पूर्वी आमच्याकडे N प्रविष्ट्या होत्या, परंतु आता आमच्याकडे एक प्रविष्टी आहे ज्याचा उपसर्ग इतर सर्व प्रमाणेच आहे. मागील एंट्रीसाठी, मूल्यामध्ये सर्व वेळ मालिका आयडी असतात.

यामुळे अशा इनव्हर्टेड इंडेक्सची स्कॅनिंग गती 10 पट वाढवणे शक्य झाले. आणि यामुळे आम्हाला कॅशेसाठी मेमरी वापर कमी करण्याची परवानगी दिली, कारण आता आम्ही स्ट्रिंग संग्रहित करतो label=value कॅशेमध्ये फक्त एकदा N वेळा एकत्र. आणि ही ओळ मोठी असू शकते जर तुम्ही तुमच्या टॅग्ज आणि लेबल्समध्ये लांबलचक रेषा साठवून ठेवल्या, ज्या कुबर्नेट्सला तिथे हलवायला आवडतात.

इन्व्हर्टेड इंडेक्सवर शोध वेगवान करण्यासाठी दुसरा पर्याय म्हणजे शार्डिंग. एका ऐवजी अनेक उलटे निर्देशांक तयार करणे आणि त्यांच्यामध्ये की द्वारे डेटा शार्ड करणे. हा एक संच आहे key=value वाफ म्हणजेच, आम्हाला अनेक स्वतंत्र इन्व्हर्टेड इंडेक्सेस मिळतात, ज्यांना आम्ही अनेक प्रोसेसरवर समांतरपणे क्वेरी करू शकतो. मागील अंमलबजावणीने केवळ एकल-प्रोसेसर मोडमध्ये ऑपरेशनला परवानगी दिली होती, म्हणजे, फक्त एका कोरवर डेटा स्कॅन करणे. हे सोल्यूशन तुम्हाला एकाच वेळी अनेक कोरवर डेटा स्कॅन करण्यास अनुमती देते, जसे क्लिकहाऊस करायला आवडते. हेच आम्ही राबविण्याची योजना आखली आहे.

आता आपण आपल्या मेंढीकडे परत जाऊया - इंटरसेक्शन फंक्शनकडे timeseries_ids. तेथे कोणती अंमलबजावणी असू शकते याचा विचार करूया. हे कार्य आपल्याला शोधण्याची परवानगी देते timeseries_ids दिलेल्या सेटसाठी label=value.

पहिला पर्याय एक भोळे अंमलबजावणी आहे. दोन नेस्टेड लूप. येथे आपल्याला फंक्शन इनपुट मिळेल intersectInts दोन तुकडे - a и b. आउटपुटवर, ते या स्लाइसच्या छेदनबिंदूकडे परत यावे.

एक भोळसट अंमलबजावणी असे दिसते. आम्ही स्लाइसमधून सर्व मूल्यांवर पुनरावृत्ती करतो a, या लूपच्या आत आपण स्लाइसच्या सर्व मूल्यांमधून जातो b. आणि आम्ही त्यांची तुलना करतो. जर ते जुळले तर आम्हाला एक छेदनबिंदू सापडला आहे. आणि त्यात सेव्ह करा result.

तोटे काय आहेत? चतुर्भुज जटिलता ही त्याची मुख्य कमतरता आहे. उदाहरणार्थ, जर तुमचे परिमाण स्लाइस असतील a и b एका वेळी एक दशलक्ष, नंतर हे कार्य तुम्हाला कधीही उत्तर देणार नाही. कारण त्याला एक ट्रिलियन पुनरावृत्ती करावी लागेल, जे आधुनिक संगणकांसाठीही खूप आहे.

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

फायदे काय आहेत? फायदा असा आहे की फक्त रेखीय जटिलता आहे. म्हणजेच, फंक्शन मोठ्या स्लाइससाठी अधिक जलद कार्यान्वित करेल. दशलक्ष-आकाराच्या स्लाइससाठी, हे फंक्शन मागील फंक्शनच्या ट्रिलियन पुनरावृत्तीच्या विरूद्ध, 2 दशलक्ष पुनरावृत्तींमध्ये कार्यान्वित करेल.

नकारात्मक बाजू म्हणजे हा नकाशा तयार करण्यासाठी या फंक्शनला अधिक मेमरी आवश्यक आहे.

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

या ठिकाणी CPU चा वेळ का वाया जातो? कारण गो या ओळींवर हॅशिंग ऑपरेशन करते. म्हणजेच, हॅशमॅपमध्ये दिलेल्या निर्देशांकात प्रवेश करण्यासाठी ते कीच्या हॅशची गणना करते. हॅश गणना ऑपरेशन दहापट नॅनोसेकंदांमध्ये पूर्ण होते. VictoriaMetrics साठी हे मंद आहे.

मी विशेषत: या केससाठी ऑप्टिमाइझ केलेला बिटसेट लागू करण्याचा निर्णय घेतला. दोन स्लाइसचे छेदनबिंदू आता असे दिसते. येथे आपण बिटसेट तयार करतो. आम्ही त्यात पहिल्या स्लाइसमधून घटक जोडतो. मग आम्ही दुसऱ्या स्लाइसमध्ये या घटकांची उपस्थिती तपासतो. आणि त्यांना निकालात जोडा. म्हणजेच, मागील उदाहरणापेक्षा ते जवळजवळ वेगळे नाही. येथे फक्त एक गोष्ट आहे की आम्ही सानुकूल फंक्शन्ससह नकाशावरील प्रवेश बदलला आहे add и has.

पहिल्या दृष्टीक्षेपात, असे दिसते की हे हळू चालले पाहिजे, जर पूर्वी तेथे मानक नकाशा वापरला गेला असेल आणि नंतर काही कार्ये कॉल केली गेली असतील, परंतु प्रोफाइलिंग दर्शवते की ही गोष्ट व्हिक्टोरियामेट्रिक्सच्या बाबतीत मानक नकाशापेक्षा 10 पट वेगाने कार्य करते.

याव्यतिरिक्त, नकाशा अंमलबजावणीच्या तुलनेत ते खूपच कमी मेमरी वापरते. कारण आम्ही येथे आठ-बाइट मूल्यांऐवजी बिट साठवत आहोत.

या अंमलबजावणीचा तोटा असा आहे की ते इतके स्पष्ट नाही, क्षुल्लक नाही.

आणखी एक कमतरता जी अनेकांच्या लक्षात येत नाही ती म्हणजे काही प्रकरणांमध्ये ही अंमलबजावणी चांगली होऊ शकत नाही. म्हणजेच, व्हिक्टोरियामेट्रिक्स टाइम सीरिज आयडीच्या छेदनबिंदूच्या या केससाठी, विशिष्ट केससाठी ते ऑप्टिमाइझ केले आहे. याचा अर्थ असा नाही की ते सर्व प्रकरणांसाठी योग्य आहे. जर ते चुकीच्या पद्धतीने वापरले गेले, तर आम्हाला कार्यक्षमतेत वाढ होणार नाही, परंतु मेमरी त्रुटी आणि कार्यक्षमतेत मंदावलेली त्रुटी.

या संरचनेच्या अंमलबजावणीचा विचार करूया. तुम्हाला पहायचे असल्यास, ते फोल्डरमध्ये VictoriaMetrics स्त्रोतांमध्ये स्थित आहे lib/uint64set. हे विशेषतः VictoriaMetrics केससाठी ऑप्टिमाइझ केले आहे, जेथे timeseries_id 64-बिट मूल्य आहे, जेथे पहिले 32 बिट्स मुळात स्थिर असतात आणि फक्त शेवटचे 32 बिट्स बदलतात.

ही डेटा रचना डिस्कवर साठवली जात नाही, ती फक्त मेमरीमध्ये चालते.

येथे त्याचे API आहे. हे फार क्लिष्ट नाही. API हे व्हिक्टोरियामेट्रिक्स वापरण्याच्या विशिष्ट उदाहरणासाठी विशेषतः तयार केले आहे. म्हणजेच येथे कोणतीही अनावश्यक कार्ये नाहीत. VictoriaMetrics द्वारे स्पष्टपणे वापरलेली कार्ये येथे आहेत.

फंक्शन्स आहेत add, जे नवीन मूल्ये जोडते. एक कार्य आहे has, जे नवीन मूल्ये तपासते. आणि एक फंक्शन आहे del, जे मूल्ये काढून टाकते. एक मदतनीस कार्य आहे len, जे सेटचा आकार परत करते. कार्य clone खूप क्लोन. आणि कार्य appendto या सेटला स्लाइसमध्ये रूपांतरित करते timeseries_ids.

या डेटा स्ट्रक्चरची अंमलबजावणी असे दिसते. सेटमध्ये दोन घटक आहेत:

• ItemsCount संचातील घटकांची संख्या द्रुतपणे परत करण्यासाठी एक सहायक फील्ड आहे. या सहाय्यक फील्डशिवाय हे करणे शक्य आहे, परंतु ते येथे जोडणे आवश्यक आहे कारण VictoriaMetrics अनेकदा त्याच्या अल्गोरिदममध्ये बिटसेट लांबीची चौकशी करते.

• दुसरे क्षेत्र आहे buckets. हे रचना पासून स्लाइस आहे bucket32. प्रत्येक रचना संग्रहित करते hi फील्ड हे वरचे 32 बिट आहेत. आणि दोन तुकडे - b16his и buckets पासून bucket16 संरचना

16-बिट संरचनेच्या दुसऱ्या भागाचे शीर्ष 64 बिट येथे संग्रहित केले आहेत. आणि इथे प्रत्येक बाइटच्या खालच्या १६ बिट्ससाठी बिटसेट साठवले जातात.

Bucket64 अॅरेचा समावेश आहे uint64. या स्थिरांकांचा वापर करून लांबी मोजली जाते. एका मध्ये bucket16 जास्तीत जास्त साठवले जाऊ शकते 2^16=65536 बिट जर तुम्ही याला 8 ने भागले तर ते 8 किलोबाइट होते. जर तुम्ही पुन्हा 8 ने भागले तर ते 1000 होईल uint64 अर्थ ते आहे Bucket16 - ही आमची 8-किलोबाइट रचना आहे.

नवीन मूल्य जोडण्यासाठी या संरचनेची एक पद्धत कशी लागू केली जाते ते पाहू या.

हे सर्व सुरू होते uint64 अर्थ आम्ही वरच्या 32 बिट्सची गणना करतो, आम्ही खालच्या 32 बिट्सची गणना करतो. चला सर्वकाही जाणून घेऊया buckets. आम्ही प्रत्येक बकेटमधील शीर्ष 32 बिट्सची तुलना मूल्य जोडल्या जाणार्याशी करतो. आणि जर ते जुळले तर आपण फंक्शन कॉल करू add संरचनेत b32 buckets. आणि तेथे खालचे ३२ बिट्स जोडा. आणि तो परत आला तर true, तर याचा अर्थ असा की आम्ही तेथे असे मूल्य जोडले आणि आमच्याकडे असे मूल्य नाही. तो परत आला तर false, मग असा अर्थ आधीच अस्तित्वात होता. मग आपण संरचनेतील घटकांची संख्या वाढवतो.

आपल्याला आवश्यक असलेले आम्हाला सापडले नसल्यास bucket आवश्यक हाय-व्हॅल्यूसह, नंतर आम्ही फंक्शनला कॉल करतो addAlloc, जे नवीन तयार करेल bucket, बादली संरचनेत जोडणे.

ही फंक्शनची अंमलबजावणी आहे b32.add. हे मागील अंमलबजावणीसारखेच आहे. आम्ही सर्वात महत्त्वपूर्ण 16 बिट्स, सर्वात कमी महत्त्वपूर्ण 16 बिट्सची गणना करतो.

मग आपण सर्व वरच्या 16 बिट्समधून जाऊ. आम्ही सामने शोधू. आणि जर एखादी जुळणी असेल, तर आम्ही ऍड पद्धत म्हणतो, ज्याचा आम्ही पुढील पृष्ठावर विचार करू bucket16.

आणि येथे सर्वात कमी पातळी आहे, जे शक्य तितके ऑप्टिमाइझ केले पाहिजे. साठी आम्ही गणना करतो uint64 स्लाइस बिट मध्ये id मूल्य आणि देखील bitmask. दिलेल्या 64-बिट मूल्यासाठी हा मुखवटा आहे, जो या बिटची उपस्थिती तपासण्यासाठी किंवा सेट करण्यासाठी वापरला जाऊ शकतो. आम्ही हा बिट सेट आहे का ते तपासतो आणि ते सेट करतो आणि उपस्थिती परत करतो. ही आमची अंमलबजावणी आहे, ज्याने आम्हाला पारंपारिक नकाशांच्या तुलनेत 10 पटीने वेळ मालिकेच्या ids च्या छेदनबिंदूच्या ऑपरेशनला गती दिली.

या ऑप्टिमायझेशन व्यतिरिक्त, VictoriaMetrics मध्ये इतर अनेक ऑप्टिमायझेशन आहेत. यापैकी बहुतेक ऑप्टिमायझेशन एका कारणासाठी जोडले गेले होते, परंतु उत्पादनामध्ये कोड प्रोफाइल केल्यानंतर.

हा ऑप्टिमायझेशनचा मुख्य नियम आहे - येथे अडचण असेल असे गृहीत धरून ऑप्टिमायझेशन जोडू नका, कारण असे होऊ शकते की तेथे अडचण होणार नाही. ऑप्टिमायझेशन सहसा कोडची गुणवत्ता कमी करते. म्हणूनच, केवळ प्रोफाइलिंगनंतर आणि प्राधान्याने उत्पादनामध्ये ऑप्टिमाइझ करणे योग्य आहे, जेणेकरून हा वास्तविक डेटा आहे. जर कोणाला स्वारस्य असेल, तर तुम्ही VictoriaMetrics सोर्स कोड पाहू शकता आणि तेथे असलेले इतर ऑप्टिमायझेशन एक्सप्लोर करू शकता.

मला बिटसेटबद्दल एक प्रश्न आहे. C++ वेक्टर बूल अंमलबजावणी, ऑप्टिमाइझ बिटसेट सारखेच. तिथून अंमलबजावणी घेतली का?

नाही, तिथून नाही. हा बिटसेट अंमलात आणताना, मला VictoriaMetrics मध्ये वापरल्या जाणार्‍या या ids टाइमसिरीजच्या संरचनेच्या ज्ञानाने मार्गदर्शन केले. आणि त्यांची रचना अशी आहे की वरचे 32 बिट मुळात स्थिर असतात. खालच्या ३२ बिट्स बदलाच्या अधीन आहेत. थोडा कमी, अधिक वेळा तो बदलू शकतो. म्हणून, ही अंमलबजावणी विशेषतः या डेटा स्ट्रक्चरसाठी ऑप्टिमाइझ केली आहे. सी++ अंमलबजावणी, माझ्या माहितीनुसार, सामान्य केससाठी अनुकूल आहे. जर तुम्ही सामान्य केससाठी ऑप्टिमाइझ करत असाल, तर याचा अर्थ विशिष्ट केससाठी ते सर्वात इष्टतम असणार नाही.

मी तुम्हाला अॅलेक्सी मिलोविडचा अहवाल पाहण्याचा सल्ला देतो. सुमारे एक महिन्यापूर्वी, त्याने विशिष्ट स्पेशलायझेशनसाठी क्लिकहाऊसमध्ये ऑप्टिमायझेशनबद्दल बोलले. तो फक्त असे म्हणतो की सामान्य बाबतीत, C++ अंमलबजावणी किंवा इतर काही अंमलबजावणी हॉस्पिटलमध्ये सरासरी चांगले काम करण्यासाठी तयार केली जाते. हे आमच्यासारख्या ज्ञान-विशिष्ट अंमलबजावणीपेक्षा वाईट कामगिरी करू शकते, जिथे आम्हाला माहित आहे की शीर्ष 32 बिट बहुतेक स्थिर असतात.

माझा दुसरा प्रश्न आहे. InfluxDB मधील मूलभूत फरक काय आहे?

अनेक मूलभूत फरक आहेत. कार्यप्रदर्शन आणि मेमरी वापराच्या बाबतीत, चाचण्यांमध्ये InfluxDB उच्च कार्डिनॅलिटी टाइम सीरिजसाठी 10 पट जास्त मेमरी वापर दर्शवते, जेव्हा आपल्याकडे त्यापैकी बरेच असतात, उदाहरणार्थ, लाखो. उदाहरणार्थ, VictoriaMetrics 1 GB प्रति दशलक्ष सक्रिय पंक्ती वापरते, तर InfluxDB 10 GB वापरते. आणि हा मोठा फरक आहे.

दुसरा मूलभूत फरक म्हणजे InfluxDB मध्ये विचित्र क्वेरी भाषा आहेत - Flux आणि InfluxQL. च्या तुलनेत वेळ मालिकेसह काम करण्यासाठी ते फार सोयीस्कर नाहीत PromQL, जे VictoriaMetrics द्वारे समर्थित आहे. PromQL ही Prometheus ची क्वेरी भाषा आहे.

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

VictoriaMetrics मध्ये सर्वकाही खूप सोपे आहे. तेथे, प्रत्येक वेळी मालिका ही मुख्य-मूल्य असते. मूल्य बिंदूंचा संच आहे - (timestamp, value), आणि की संच आहे label=value. फील्ड आणि मोजमापांमध्ये कोणतेही पृथक्करण नाही. हे तुम्हाला कोणताही डेटा निवडण्याची आणि नंतर एकत्र, जोडा, वजाबाकी, गुणाकार, भागाकार, InfluxDB च्या विपरीत, जेथे माझ्या माहितीनुसार वेगवेगळ्या पंक्तींमधील गणना अद्याप लागू केलेली नाही. ते अंमलात आणले तरी ते अवघड आहे, तुम्हाला भरपूर कोड लिहावे लागेल.

मला एक स्पष्टीकरण देणारा प्रश्न आहे. मला बरोबर समजले आहे का की तुम्ही बोललात अशी काही समस्या होती, की हा उलटा निर्देशांक मेमरीमध्ये बसत नाही, त्यामुळे तेथे विभाजन होते?

प्रथम, मी मानक Go नकाशावर उलट्या निर्देशांकाची साधी अंमलबजावणी दर्शविली. ही अंमलबजावणी डेटाबेससाठी योग्य नाही कारण हा उलटा निर्देशांक डिस्कवर जतन केलेला नाही आणि डेटाबेस डिस्कवर जतन करणे आवश्यक आहे जेणेकरून हा डेटा रीस्टार्ट केल्यावर उपलब्ध राहील. या अंमलबजावणीमध्ये, जेव्हा तुम्ही अॅप्लिकेशन रीस्टार्ट कराल, तेव्हा तुमचा उलटा निर्देशांक अदृश्य होईल. आणि तुम्ही सर्व डेटाचा प्रवेश गमवाल कारण तुम्ही तो शोधू शकणार नाही.

नमस्कार! अहवालाबद्दल धन्यवाद! माझे नाव पावेल आहे. मी Wildberries चा आहे. माझ्याकडे तुमच्यासाठी काही प्रश्न आहेत. प्रश्न एक. तुम्हाला असे वाटते का की जर तुम्ही तुमच्या ऍप्लिकेशनचे आर्किटेक्चर तयार करताना वेगळे तत्त्व निवडले असते आणि कालांतराने डेटाचे विभाजन केले असते, तर कदाचित एका विभाजनामध्ये डेटा आहे या वस्तुस्थितीवर आधारित, शोधताना तुम्ही डेटाला छेदू शकला असता. कालावधी , म्हणजेच एका वेळेच्या अंतराने आणि तुमचे तुकडे वेगळ्या पद्धतीने विखुरले आहेत याची काळजी करण्याची गरज नाही? प्रश्न क्रमांक 2 - तुम्ही बिटसेट आणि इतर सर्व गोष्टींसह समान अल्गोरिदम लागू करत असल्याने, कदाचित तुम्ही प्रोसेसर सूचना वापरण्याचा प्रयत्न केला असेल? कदाचित आपण अशा ऑप्टिमायझेशनचा प्रयत्न केला असेल?

मी लगेच दुसऱ्याला उत्तर देईन. आम्ही अद्याप त्या टप्प्यावर पोहोचलो नाही. पण गरज पडली तर तिथे पोहोचू. आणि पहिला, प्रश्न काय होता?

तुम्ही दोन परिस्थितींवर चर्चा केली. आणि ते म्हणाले की त्यांनी अधिक जटिल अंमलबजावणीसह दुसरा निवडला. आणि त्यांनी पहिल्याला प्राधान्य दिले नाही, जिथे डेटा वेळेनुसार विभाजित केला जातो.

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

आणि म्हणून - होय, वेळ विभाजन हा एक चांगला पर्याय आहे. प्रोमिथियस त्याचा वापर करतो. पण प्रोमिथियसची आणखी एक कमतरता आहे. डेटाचे हे तुकडे विलीन करताना, सर्व लेबले आणि टाइमसीरीजसाठी मेमरी मेटा माहिती ठेवणे आवश्यक आहे. त्यामुळे, विलीन होणारे डेटाचे तुकडे मोठे असल्यास, विलीनीकरणादरम्यान मेमरी वापर खूप वाढतो, व्हिक्टोरियामेट्रिक्सच्या विपरीत. विलीन करताना, VictoriaMetrics मेमरी अजिबात वापरत नाही; डेटाच्या विलीन केलेल्या तुकड्यांचा आकार विचारात न घेता फक्त दोन किलोबाइट्स वापरली जातात.

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

डेटा ट्रॅव्हर्स करण्यासाठी आम्ही कर्सर का वापरत नाही?

होय

आम्ही क्रमवारी लावलेल्या पंक्ती LevelDB किंवा mergeset मध्ये संग्रहित करतो. आपण कर्सर हलवू शकतो आणि छेदनबिंदू शोधू शकतो. आम्ही ते का वापरत नाही? कारण ते संथ आहे. कारण कर्सर म्हणजे तुम्हाला प्रत्येक ओळीसाठी फंक्शन कॉल करणे आवश्यक आहे. फंक्शन कॉल 5 नॅनोसेकंद आहे. आणि जर तुमच्याकडे 100 ओळी असतील, तर असे दिसून येते की आम्ही फंक्शन कॉल करण्यासाठी अर्धा सेकंद घालवतो.

अशी एक गोष्ट आहे, होय. आणि माझा शेवटचा प्रश्न. प्रश्न जरा विचित्र वाटेल. डेटा येतो त्या क्षणी सर्व आवश्यक समुच्चय वाचणे आणि ते आवश्यक स्वरूपात जतन करणे का शक्य नाही? VictoriaMetrics, ClickHouse, इत्यादीसारख्या काही सिस्टीममध्ये प्रचंड व्हॉल्यूम का वाचवायचे आणि नंतर त्यावर बराच वेळ का घालवायचा?

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

ठीक आहे, मला प्रश्न समजला. तुमच्या उदाहरणाला स्थान आहे. तुम्हाला कोणती समुच्चय आवश्यक आहे हे माहित असल्यास, ही सर्वोत्तम अंमलबजावणी आहे. परंतु समस्या अशी आहे की लोक हे मेट्रिक्स, काही डेटा क्लिकहाऊसमध्ये सेव्ह करतात आणि भविष्यात ते एकत्रित आणि फिल्टर कसे करतील हे त्यांना अद्याप माहित नाही, म्हणून त्यांना सर्व कच्चा डेटा जतन करावा लागेल. परंतु जर तुम्हाला माहित असेल की तुम्हाला सरासरी काहीतरी मोजणे आवश्यक आहे, तर तेथे कच्च्या मूल्यांचा समूह साठवण्याऐवजी त्याची गणना का करू नये? पण तुम्हाला नेमके काय हवे आहे हे तुम्हाला माहीत असेल तरच.

तसे, वेळ मालिका संचयित करण्यासाठी डेटाबेस एकत्रित गणना करण्यास समर्थन देतात. उदाहरणार्थ, प्रोमिथियस समर्थन करतो रेकॉर्डिंग नियम. म्हणजेच, आपल्याला कोणत्या युनिट्सची आवश्यकता असेल हे माहित असल्यास हे केले जाऊ शकते. VictoriaMetrics कडे अद्याप हे नाही, परंतु हे सहसा प्रोमिथियसच्या आधी असते, ज्यामध्ये हे रेकोडिंग नियमांमध्ये केले जाऊ शकते.

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

आणि आणखी एक प्रश्न. आम्ही फक्त सरासरीबद्दल बोलत होतो आणि मला आठवले की कार्बन बॅकएंडसह ग्रेफाइट सारखी गोष्ट एकदा होती. आणि जुना डेटा कसा कमी करायचा हे त्याला माहीत होते, म्हणजे प्रति मिनिट एक पॉइंट, तासाला एक पॉइंट इ. पातळ करणे परंतु Prometheus आणि VictoriaMetrics या कार्यक्षमतेला समर्थन देत नाहीत. त्याचे समर्थन करण्याचे नियोजन आहे का? नसेल तर का नाही?

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

आणि दुसरी गोष्ट अशी आहे की VictoriaMetrics, ClickHouse सारखे, मोठ्या प्रमाणात कच्च्या डेटावर काम करण्यासाठी ऑप्टिमाइझ केले आहे, त्यामुळे तुमच्या सिस्टममध्ये अनेक कोर असल्यास ते एका सेकंदापेक्षा कमी वेळात एक अब्ज ओळी काढू शकते. व्हिक्टोरियामेट्रिक्समध्ये स्कॅनिंग टाइम सीरीज पॉइंट्स - 50 पॉइंट्स प्रति सेकंद प्रति कोर. आणि हे कार्यप्रदर्शन विद्यमान कोरांवर मोजले जाते. म्हणजेच, आपल्याकडे 000 कोर असल्यास, उदाहरणार्थ, आपण प्रति सेकंद एक अब्ज गुण स्कॅन कराल. आणि VictoriaMetrics आणि ClickHouse ची ही मालमत्ता डाउनसॅमलिंगची गरज कमी करते.

आणखी एक वैशिष्ट्य म्हणजे VictoriaMetrics हा डेटा प्रभावीपणे संकुचित करते. उत्पादनात सरासरी कॉम्प्रेशन ०.४ ते ०.८ बाइट्स प्रति बिंदू आहे. प्रत्येक बिंदू एक टाइमस्टॅम्प + मूल्य आहे. आणि ते सरासरी एक बाइटपेक्षा कमी संकुचित केले जाते.

सर्जी. माझा एक प्रश्न आहे. किमान रेकॉर्डिंग वेळ क्वांटम किती आहे?

एक मिलिसेकंद. आम्ही अलीकडे इतर वेळ मालिका डेटाबेस विकासकांशी संभाषण केले. त्यांचा किमान वेळ स्लाइस एक सेकंद आहे. आणि ग्रेफाइटमध्ये, उदाहरणार्थ, ते देखील एक सेकंद आहे. OpenTSDB मध्ये ते देखील एक सेकंद आहे. InfluxDB मध्ये नॅनोसेकंद अचूकता आहे. व्हिक्टोरियामेट्रिक्समध्ये ते एक मिलिसेकंद आहे, कारण प्रोमिथियसमध्ये ते एक मिलिसेकंद आहे. आणि VictoriaMetrics मूलतः Prometheus साठी रिमोट स्टोरेज म्हणून विकसित केले होते. पण आता ते इतर प्रणालींमधून डेटा वाचवू शकते.

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

VictoriaMetrics मधील मिलिसेकंद अचूकता देखील DevOps केससाठी योग्य आहे आणि मी अहवालाच्या सुरुवातीला नमूद केलेल्या बहुतेक प्रकरणांसाठी योग्य असू शकते. फक्त एकच गोष्ट ज्यासाठी ती योग्य असू शकत नाही ती म्हणजे उच्च वारंवारता व्यापार प्रणाली.

धन्यवाद! आणि दुसरा प्रश्न. PromQL मध्ये सुसंगतता काय आहे?

पूर्ण बॅकवर्ड सुसंगतता. VictoriaMetrics पूर्णपणे PromQL चे समर्थन करते. याव्यतिरिक्त, ते PromQL मध्ये अतिरिक्त प्रगत कार्यक्षमता जोडते, ज्याला म्हणतात मेट्रिक्सक्यूएल. या विस्तारित कार्यक्षमतेबद्दल YouTube वर चर्चा आहे. मी सेंट पीटर्सबर्गमध्ये वसंत ऋतूतील मॉनिटरिंग मीटअपमध्ये बोललो.

टेलिग्राम चॅनेल व्हिक्टोरियामेट्रिक्स.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

Prometheus साठी तुमचे दीर्घकालीन स्टोरेज म्हणून VictoriaMetrics वर जाण्यापासून तुम्हाला काय थांबवत आहे? (टिप्पण्यांमध्ये लिहा, मी ते मतदानात जोडेन))

• 71,4%मी Prometheus5 वापरत नाही

• 28,6%VictoriaMetrics2 बद्दल माहित नव्हते

7 वापरकर्त्यांनी मतदान केले. 12 वापरकर्ते दूर राहिले.

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