विक्टोरियामेट्रिक्स में गो अनुकूलन। अलेक्जेंडर वाल्यालकिन

मेरा सुझाव है कि आप अलेक्जेंडर वाल्याल्किन की 2019 के अंत की रिपोर्ट "विक्टोरियामेट्रिक्स में गो ऑप्टिमाइज़ेशन" की प्रतिलेख पढ़ें।

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

इस रिपोर्ट के वीडियो का लिंक यहां दिया गया है - https://youtu.be/MZ5P21j_HLE

स्लाइड्स

अपने बारे में हमें बताएं। मैं अलेक्जेंडर वाल्यालकिन हूं। यहाँ मेरा GitHub खाता. मुझे गो और प्रदर्शन अनुकूलन का शौक है। मैंने बहुत सी उपयोगी और कम उपयोगी लाइब्रेरीज़ लिखीं। वे या तो से शुरू करते हैं fast, या साथ quick उपसर्ग.

मैं वर्तमान में विक्टोरियामेट्रिक्स पर काम कर रहा हूं। यह क्या है और मैं वहां क्या कर रहा हूं? मैं इस प्रेजेंटेशन में इस बारे में बात करूंगा.

रिपोर्ट की रूपरेखा इस प्रकार है:

• सबसे पहले, मैं आपको बताऊंगा कि विक्टोरियामेट्रिक्स क्या है।
• फिर मैं आपको बताऊंगा कि समय श्रृंखला क्या हैं।
• फिर मैं आपको बताऊंगा कि समय श्रृंखला डेटाबेस कैसे काम करता है।
• आगे, मैं आपको डेटाबेस आर्किटेक्चर के बारे में बताऊंगा: इसमें क्या शामिल है।
• और फिर चलिए विक्टोरियामेट्रिक्स के अनुकूलन की ओर बढ़ते हैं। यह उल्टे सूचकांक के लिए एक अनुकूलन और गो में बिटसेट कार्यान्वयन के लिए एक अनुकूलन है।

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

विक्टोरियामेट्रिक्स अन्य समय श्रृंखला डेटाबेस की तुलना में बेहतर डेटा संपीड़न प्रदान करता है।

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

विक्टोरियामेट्रिक्स क्षैतिज रूप से भी स्केल करता है - यानी, आप विक्टोरियामेट्रिक्स क्लस्टर में अतिरिक्त नोड्स जोड़ सकते हैं, और इसका प्रदर्शन लगभग रैखिक रूप से बढ़ जाएगा।

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

कौन जानता है कि समय श्रृंखला क्या है? वह कई लोगों को जानता भी है. समय श्रृंखला जोड़ियों की एक श्रृंखला है (timestamp, значение), जहां इन जोड़ियों को समय के अनुसार क्रमबद्ध किया जाता है। मान एक फ़्लोटिंग पॉइंट नंबर है - फ़्लोट64।

प्रत्येक समय श्रृंखला को एक कुंजी द्वारा विशिष्ट रूप से पहचाना जाता है। इस कुंजी में क्या शामिल है? इसमें कुंजी-मूल्य जोड़े का एक गैर-रिक्त सेट होता है।

यहां समय श्रृंखला का एक उदाहरण दिया गया है. इस श्रृंखला की कुंजी जोड़ियों की एक सूची है: __name__="cpu_usage" मीट्रिक का नाम है, instance="my-server" - यह वह कंप्यूटर है जिस पर यह मीट्रिक एकत्र की जाती है, datacenter="us-east" - यह वह डेटा सेंटर है जहां यह कंप्यूटर स्थित है।

हम एक समय श्रृंखला नाम के साथ समाप्त हुए जिसमें तीन कुंजी-मूल्य जोड़े शामिल थे। यह कुंजी जोड़ियों की सूची से मेल खाती है (timestamp, value). t1, t3, t3, ..., tN - ये टाइमस्टैम्प हैं, 10, 20, 12, ..., 15 - संगत मान. यह किसी दी गई पंक्ति के लिए किसी निश्चित समय पर सीपीयू-उपयोग है।

समय श्रृंखला का उपयोग कहाँ किया जा सकता है? क्या किसी को कोई ख़याल है?

• DevOps में, आप सीपीयू, रैम, नेटवर्क, आरपीएस, त्रुटियों की संख्या आदि को माप सकते हैं।
• IoT - हम तापमान, दबाव, भौगोलिक निर्देशांक और कुछ और माप सकते हैं।
• वित्त के अलावा - हम सभी प्रकार के स्टॉक और मुद्राओं की कीमतों की निगरानी कर सकते हैं।
• इसके अलावा, समय श्रृंखला का उपयोग कारखानों में उत्पादन प्रक्रियाओं की निगरानी में किया जा सकता है। हमारे पास ऐसे उपयोगकर्ता हैं जो रोबोट के लिए पवन टरबाइन की निगरानी के लिए विक्टोरियामेट्रिक्स का उपयोग करते हैं।
• समय श्रृंखला विभिन्न उपकरणों के सेंसर से जानकारी एकत्र करने के लिए भी उपयोगी है। उदाहरण के लिए, एक इंजन के लिए; टायर के दबाव को मापने के लिए; गति, दूरी मापने के लिए; गैसोलीन की खपत आदि को मापने के लिए।
• समय श्रृंखला का उपयोग विमान की निगरानी के लिए भी किया जा सकता है। प्रत्येक विमान में एक ब्लैक बॉक्स होता है जो विमान के स्वास्थ्य के विभिन्न मापदंडों के लिए समय श्रृंखला एकत्र करता है। समय श्रृंखला का उपयोग एयरोस्पेस उद्योग में भी किया जाता है।
• स्वास्थ्य देखभाल रक्तचाप, नाड़ी, आदि है।

ऐसे और भी एप्लिकेशन हो सकते हैं जिनके बारे में मैं भूल गया हूं, लेकिन मुझे आशा है कि आप समझ गए होंगे कि आधुनिक दुनिया में समय श्रृंखला का सक्रिय रूप से उपयोग किया जाता है। और उनके उपयोग की मात्रा हर साल बढ़ रही है।

आपको समय श्रृंखला डेटाबेस की आवश्यकता क्यों है? आप समय श्रृंखला को संग्रहीत करने के लिए नियमित संबंधपरक डेटाबेस का उपयोग क्यों नहीं कर सकते?

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

आमतौर पर समय श्रृंखला डेटाबेस विशेष क्वेरी भाषाएँ प्रदान करते हैं क्योंकि समय श्रृंखला SQL बहुत उपयुक्त नहीं है। हालाँकि ऐसे डेटाबेस हैं जो SQL का समर्थन करते हैं, यह बहुत उपयुक्त नहीं है। क्वेरी भाषाएँ जैसे प्रोमक्यूएल, इन्फ्लक्सक्यूएल, प्रवाह, Q. मुझे आशा है कि किसी ने इनमें से कम से कम एक भाषा तो सुनी होगी। बहुत से लोगों ने शायद PromQL के बारे में सुना होगा। यह प्रोमेथियस क्वेरी भाषा है.

उदाहरण के तौर पर विक्टोरियामेट्रिक्स का उपयोग करते हुए आधुनिक समय श्रृंखला डेटाबेस आर्किटेक्चर ऐसा दिखता है।

यह दो हिस्सों से मिलकर बना है। यह उल्टे सूचकांक के लिए भंडारण और समय श्रृंखला मूल्यों के लिए भंडारण है। ये रिपॉजिटरी अलग हो गई हैं।

जब डेटाबेस में कोई नया रिकॉर्ड आता है, तो हम किसी दिए गए सेट के लिए समय श्रृंखला पहचानकर्ता को खोजने के लिए सबसे पहले उल्टे सूचकांक तक पहुंचते हैं label=value किसी दिए गए मीट्रिक के लिए. हम इस पहचानकर्ता को ढूंढते हैं और डेटा स्टोर में मान सहेजते हैं।

जब TSDB से डेटा पुनर्प्राप्त करने का अनुरोध आता है, तो हम सबसे पहले इनवर्टेड इंडेक्स पर जाते हैं। चलो सब कुछ पा लेते हैं timeseries_ids रिकॉर्ड जो इस सेट से मेल खाते हैं label=value. और फिर हम डेटा वेयरहाउस से अनुक्रमित सभी आवश्यक डेटा प्राप्त करते हैं timeseries_ids.

आइए एक उदाहरण देखें कि समय श्रृंखला डेटाबेस आने वाली चयनित क्वेरी को कैसे संसाधित करता है।

• सबसे पहले उसे सब कुछ मिलता है timeseries_ids एक उल्टे सूचकांक से जिसमें दिए गए जोड़े शामिल हैं label=value, या किसी दिए गए नियमित अभिव्यक्ति को संतुष्ट करें।
• फिर यह डेटा स्टोरेज से पाए गए सभी डेटा बिंदुओं को एक निश्चित समय अंतराल पर पुनर्प्राप्त करता है timeseries_ids.
• इसके बाद, डेटाबेस उपयोगकर्ता के अनुरोध के अनुसार, इन डेटा बिंदुओं पर कुछ गणना करता है। और उसके बाद यह उत्तर लौटाता है।

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

आइए उल्टे सूचकांक पर चलते हैं। कई लोग सोच सकते हैं कि यह सरल है। कौन जानता है कि उलटा सूचकांक क्या है और यह कैसे काम करता है? ओह, अब इतने सारे लोग नहीं हैं। आइए समझने की कोशिश करें कि यह क्या है।

यह वास्तव में सरल है. यह बस एक शब्दकोश है जो किसी कुंजी को किसी मान से मैप करता है। कुंजी क्या है? ये जोड़ा 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, जिस पर नीचे चर्चा की जाएगी। और यह फ़ंक्शन इन सूचियों का प्रतिच्छेदन लौटाता है।

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

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

जैसे तैयार समाधानों का उपयोग करके इस समस्या को हल किया जा सकता है लेवलडीबीया रॉक्सडीबी.

संक्षेप में, हमें एक ऐसे डेटाबेस की आवश्यकता है जो हमें तीन ऑपरेशन शीघ्रता से करने की अनुमति दे।

• पहला ऑपरेशन रिकॉर्डिंग है ключ-значение इस डेटाबेस को. वह ऐसा बहुत तेजी से करती है, जहां ключ-значение मनमाना तार हैं.
• दूसरा ऑपरेशन किसी दी गई कुंजी का उपयोग करके किसी मान की त्वरित खोज है।
• और तीसरा ऑपरेशन किसी दिए गए उपसर्ग द्वारा सभी मानों की त्वरित खोज है।

लेवलडीबी और रॉक्सडीबी - ये डेटाबेस Google और Facebook द्वारा विकसित किए गए थे। सबसे पहले लेवलडीबी आया। फिर फेसबुक के लोगों ने लेवलडीबी लिया और उसमें सुधार करना शुरू किया, उन्होंने रॉक्सडीबी बनाया। अब लगभग सभी आंतरिक डेटाबेस फेसबुक के अंदर RocksDB पर काम करते हैं, जिनमें RocksDB और MySQL में स्थानांतरित किए गए डेटाबेस भी शामिल हैं। उन्होंने उसका नाम रखा मायरॉक्स.

लेवलडीबी का उपयोग करके एक उलटा सूचकांक लागू किया जा सकता है। इसे कैसे करना है? हम कुंजी के रूप में सहेजते हैं label=value. और मान उस समय श्रृंखला का पहचानकर्ता है जहां जोड़ी मौजूद है label=value.

यदि हमारे पास किसी दिए गए जोड़े के साथ कई समय श्रृंखला है label=value, तो इस डेटाबेस में एक ही कुंजी और अलग-अलग कई पंक्तियाँ होंगी timeseries_ids. सभी की एक सूची प्राप्त करने के लिए timeseries_ids, जो इसी से शुरू होती है label=prefix, हम एक रेंज स्कैन करते हैं जिसके लिए यह डेटाबेस अनुकूलित है। यानी हम उन सभी पंक्तियों का चयन करते हैं जो इससे शुरू होती हैं label=prefix और आवश्यक प्राप्त करें timeseries_ids.

गो में यह कैसा दिखेगा इसका एक नमूना कार्यान्वयन यहां दिया गया है। हमारे पास एक उलटा सूचकांक है। यह लेवलडीबी है।

यह कार्य अनुभवहीन कार्यान्वयन के समान ही है। यह लगभग लाइन दर लाइन अनुभवहीन कार्यान्वयन को दोहराता है। एकमात्र मुद्दा यह है कि मुड़ने के बजाय map हम उल्टे सूचकांक तक पहुँचते हैं। हमें पहले के लिए सभी मान मिलते हैं label=value. फिर हम शेष सभी जोड़ियों से गुजरते हैं label=value और उनके लिए मेट्रिकआईडी के संगत सेट प्राप्त करें। फिर हम चौराहा ढूंढते हैं।

सब कुछ ठीक लग रहा है, लेकिन इस समाधान में कमियां हैं। विक्टोरियामेट्रिक्स ने शुरुआत में लेवलडीबी पर आधारित एक उलटा सूचकांक लागू किया। लेकिन आख़िर में मुझे इसे छोड़ना पड़ा.

क्यों? क्योंकि लेवलडीबी अनुभवहीन कार्यान्वयन की तुलना में धीमा है। एक सरल कार्यान्वयन में, एक दी गई कुंजी दिए जाने पर, हम तुरंत पूरा टुकड़ा पुनः प्राप्त कर लेते हैं metricIDs. यह एक बहुत तेज़ ऑपरेशन है - पूरा टुकड़ा उपयोग के लिए तैयार है।

लेवलडीबी में, हर बार एक फ़ंक्शन को कॉल किया जाता है GetValues आपको आरंभ होने वाली सभी पंक्तियों से गुजरना होगा label=value. और प्रत्येक पंक्ति के लिए मान प्राप्त करें timeseries_ids. इस तरह की timeseries_ids इनमें से एक टुकड़ा इकट्ठा करें timeseries_ids. जाहिर है, यह कुंजी द्वारा नियमित मानचित्र तक पहुंचने की तुलना में बहुत धीमा है।

दूसरा दोष यह है कि लेवलडीबी सी में लिखा गया है। गो से सी फ़ंक्शन को कॉल करना बहुत तेज़ नहीं है। इसमें सैकड़ों नैनोसेकेंड लगते हैं। यह बहुत तेज़ नहीं है, क्योंकि गो में लिखे गए नियमित फ़ंक्शन कॉल की तुलना में, जिसमें 1-5 नैनोसेकंड लगते हैं, प्रदर्शन में अंतर दसियों गुना है। विक्टोरियामेट्रिक्स के लिए यह एक घातक दोष था :)

इसलिए मैंने उल्टे सूचकांक का अपना स्वयं का कार्यान्वयन लिखा। और उसने उसे बुलाया मर्जसेट.

मर्जसेट मर्जट्री डेटा संरचना पर आधारित है। यह डेटा संरचना ClickHouse से उधार ली गई है। जाहिर है, तेज खोज के लिए मर्जसेट को अनुकूलित किया जाना चाहिए timeseries_ids दी गई कुंजी के अनुसार. मर्जसेट पूरी तरह से गो में लिखा गया है। आप देख सकते हैं GitHub पर विक्टोरियामेट्रिक्स स्रोत. मर्जसेट का कार्यान्वयन फ़ोल्डर में है /lib/mergeset. आप यह जानने का प्रयास कर सकते हैं कि वहां क्या हो रहा है।

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

हम मर्जसेट के नुकसान के बारे में बाद में बात करेंगे। अब बात करते हैं कि उल्टे सूचकांक को लागू करते समय विक्टोरियामेट्रिक्स के उत्पादन में क्या समस्याएँ उत्पन्न हुईं।

वे क्यों उत्पन्न हुए?

पहला कारण उच्च मंथन दर है। रूसी में अनुवादित, यह समय श्रृंखला में बार-बार होने वाला परिवर्तन है। यह तब होता है जब एक समय श्रृंखला समाप्त होती है और एक नई श्रृंखला शुरू होती है, या कई नई समय श्रृंखला शुरू होती है। और ऐसा अक्सर होता है.

दूसरा कारण समय श्रृंखला की बड़ी संख्या है। शुरुआत में, जब निगरानी लोकप्रियता हासिल कर रही थी, समय श्रृंखला की संख्या कम थी। उदाहरण के लिए, प्रत्येक कंप्यूटर के लिए आपको सीपीयू, मेमोरी, नेटवर्क और डिस्क लोड की निगरानी करने की आवश्यकता होती है। प्रति कंप्यूटर 4 समय श्रृंखला। मान लीजिए कि आपके पास 100 कंप्यूटर और 400 टाइम सीरीज़ हैं। ये तो बहुत कम है.

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

लेकिन यह बिलकुल भी नहीं है। प्रत्येक प्रोसेसर कोर में कई अवस्थाएँ हो सकती हैं, जैसे निष्क्रिय, जब यह निष्क्रिय होता है। और यूजर स्पेस में भी काम करते हैं, कर्नेल स्पेस और अन्य राज्यों में भी काम करते हैं। और ऐसी प्रत्येक अवस्था को एक अलग समय श्रृंखला के रूप में भी मापा जा सकता है। इससे पंक्तियों की संख्या 7-8 गुना बढ़ जाती है।

एक मीट्रिक से हमें केवल एक कंप्यूटर के लिए 40 x 8 = 320 मीट्रिक प्राप्त हुए। 100 से गुणा करने पर 32 के स्थान पर 000 प्राप्त होता है।

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

आइए उच्च मंथन दर पर करीब से नज़र डालें। उत्पादन में उच्च मंथन दर का क्या कारण है? क्योंकि लेबल और टैग के कुछ अर्थ लगातार बदलते रहते हैं।

उदाहरण के लिए, कुबेरनेट्स को लें, जिसकी अवधारणा है deployment, यानी जब आपके एप्लिकेशन का एक नया संस्करण लॉन्च किया जाता है। किसी कारण से, कुबेरनेट्स डेवलपर्स ने लेबल में परिनियोजन आईडी जोड़ने का निर्णय लिया।

इससे क्या हुआ? इसके अलावा, प्रत्येक नई तैनाती के साथ, सभी पुरानी समय श्रृंखला बाधित हो जाती है, और उनके बजाय, नई समय श्रृंखला एक नए लेबल मान के साथ शुरू होती है deployment_id. ऐसी पंक्तियाँ सैकड़ों-हजारों और यहाँ तक कि लाखों भी हो सकती हैं।

इस सबके बारे में महत्वपूर्ण बात यह है कि समय श्रृंखला की कुल संख्या बढ़ती है, लेकिन वर्तमान में सक्रिय और डेटा प्राप्त करने वाली समय श्रृंखला की संख्या स्थिर रहती है। इस अवस्था को उच्च मंथन दर कहा जाता है।

उच्च मंथन दर की मुख्य समस्या एक निश्चित समय अंतराल पर लेबल के दिए गए सेट के लिए सभी समय श्रृंखला के लिए निरंतर खोज गति सुनिश्चित करना है। आमतौर पर यह आखिरी घंटे या आखिरी दिन का समय अंतराल होता है।

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

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

इससे संसाधनों की बचत होती है क्योंकि हमें उन हिस्सों को नहीं देखना पड़ता जो दिए गए अंतराल में नहीं आते। अर्थात्, आमतौर पर, यदि हम अंतिम घंटे के लिए डेटा का चयन करते हैं, तो पिछले समय अंतराल के लिए हम अनुरोधों को छोड़ देते हैं।

इस समस्या के समाधान के लिए एक और विकल्प है. इसका उद्देश्य प्रत्येक दिन के लिए उस दिन हुई समय श्रृंखला की आईडी की एक अलग सूची संग्रहीत करना है।

पिछले समाधान की तुलना में इस समाधान का लाभ यह है कि हम समय श्रृंखला की जानकारी की नकल नहीं करते हैं जो समय के साथ गायब नहीं होती है। वे निरंतर मौजूद रहते हैं और बदलते नहीं हैं।

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

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

हमने इस समस्या का समाधान कैसे किया? हमने इसे मूल तरीके से हल किया - एक पहचानकर्ता के बजाय प्रत्येक उल्टे सूचकांक प्रविष्टि में कई समय श्रृंखला पहचानकर्ताओं को संग्रहीत करके। यानी हमारे पास एक चाबी है label=value, जो हर समय श्रृंखला में होता है। और अब हम कई बचाते हैं timeseries_ids एक प्रविष्टि में.

यहाँ एक उदाहरण है. पहले हमारे पास N प्रविष्टियाँ थीं, लेकिन अब हमारे पास एक प्रविष्टि है जिसका उपसर्ग अन्य सभी के समान है। पिछली प्रविष्टि के लिए, मान में सभी समय श्रृंखला आईडी शामिल हैं।

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

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

आइए अब अपनी भेड़ों की ओर लौटते हैं - प्रतिच्छेदन समारोह की ओर timeseries_ids. आइए विचार करें कि वहां क्या कार्यान्वयन हो सकते हैं। यह फ़ंक्शन आपको ढूंढने की अनुमति देता है timeseries_ids किसी दिए गए सेट के लिए label=value.

पहला विकल्प एक सहज कार्यान्वयन है। दो नेस्टेड लूप. यहां हमें फ़ंक्शन इनपुट मिलता है intersectInts दो टुकड़े - a и b. आउटपुट पर, इसे इन स्लाइसों का प्रतिच्छेदन हमारे पास वापस आना चाहिए।

एक अनुभवहीन कार्यान्वयन इस तरह दिखता है. हम स्लाइस से सभी मानों को पुनरावृत्त करते हैं a, इस लूप के अंदर हम स्लाइस के सभी मानों से गुजरते हैं b. और हम उनकी तुलना करते हैं. यदि वे मेल खाते हैं, तो हमें एक प्रतिच्छेदन मिल गया है। और इसे सेव करें result.

क्या हैं नुकसान? द्विघात जटिलता इसका मुख्य दोष है। उदाहरण के लिए, यदि आपके आयाम स्लाइस हैं a и b एक बार में दस लाख, तो यह फ़ंक्शन आपको कभी भी उत्तर नहीं देगा। क्योंकि इसके लिए एक ट्रिलियन पुनरावृत्तियाँ बनाने की आवश्यकता होगी, जो आधुनिक कंप्यूटरों के लिए भी बहुत है।

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

क्या लाभ हैं? लाभ यह है कि इसमें केवल रैखिक जटिलता है। यानी, बड़े स्लाइस के लिए फ़ंक्शन बहुत तेज़ी से निष्पादित होगा। एक मिलियन आकार के स्लाइस के लिए, यह फ़ंक्शन पिछले फ़ंक्शन के ट्रिलियन पुनरावृत्तियों के विपरीत, 2 मिलियन पुनरावृत्तियों में निष्पादित होगा।

नकारात्मक पक्ष यह है कि इस मानचित्र को बनाने के लिए इस फ़ंक्शन को अधिक मेमोरी की आवश्यकता होती है।

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

इन जगहों पर CPU का समय क्यों बर्बाद होता है? क्योंकि गो इन पंक्तियों पर हैशिंग ऑपरेशन करता है। अर्थात्, यह कुंजी के हैश की गणना करता है ताकि उसे HashMap में किसी दिए गए इंडेक्स पर एक्सेस किया जा सके। हैश गणना ऑपरेशन दसियों नैनोसेकंड में पूरा हो जाता है। विक्टोरियामेट्रिक्स के लिए यह धीमा है।

मैंने इस मामले के लिए विशेष रूप से अनुकूलित एक बिटसेट लागू करने का निर्णय लिया। दो स्लाइसों का प्रतिच्छेदन अब इस प्रकार दिखता है। यहां हम एक बिटसेट बनाते हैं। हम इसमें पहले स्लाइस से तत्व जोड़ते हैं। फिर हम दूसरे स्लाइस में इन तत्वों की उपस्थिति की जाँच करते हैं। और उन्हें परिणाम में जोड़ें. यानी यह पिछले उदाहरण से लगभग अलग नहीं है। यहां एकमात्र बात यह है कि हमने मानचित्र तक पहुंच को कस्टम फ़ंक्शन से बदल दिया है add и has.

पहली नज़र में, ऐसा लगता है कि इसे धीमी गति से काम करना चाहिए, अगर पहले वहां एक मानक मानचित्र का उपयोग किया गया था, और फिर कुछ अन्य फ़ंक्शन कॉल किए जाते हैं, लेकिन प्रोफाइलिंग से पता चलता है कि विक्टोरियामेट्रिक्स के मामले में यह चीज़ मानक मानचित्र की तुलना में 10 गुना तेजी से काम करती है।

इसके अलावा, यह मानचित्र कार्यान्वयन की तुलना में बहुत कम मेमोरी का उपयोग करता है। क्योंकि हम यहां आठ-बाइट मानों के बजाय बिट्स संग्रहीत कर रहे हैं।

इस कार्यान्वयन का नुकसान यह है कि यह इतना स्पष्ट नहीं है, तुच्छ नहीं है।

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

आइए इस संरचना के कार्यान्वयन पर विचार करें। यदि आप देखना चाहें, तो यह विक्टोरियामेट्रिक्स स्रोतों के फ़ोल्डर में स्थित है lib/uint64set. इसे विशेष रूप से विक्टोरियामेट्रिक्स मामले के लिए अनुकूलित किया गया है, जहां timeseries_id एक 64-बिट मान है, जहां पहले 32 बिट मूल रूप से स्थिर होते हैं और केवल अंतिम 32 बिट बदलते हैं।

यह डेटा संरचना डिस्क पर संग्रहीत नहीं है, यह केवल मेमोरी में संचालित होती है।

यहाँ इसकी एपीआई है. यह बहुत जटिल नहीं है. एपीआई को विशेष रूप से विक्टोरियामेट्रिक्स का उपयोग करने के एक विशिष्ट उदाहरण के लिए तैयार किया गया है। यानी यहां कोई अनावश्यक कार्य नहीं हैं. यहां वे फ़ंक्शन हैं जो विक्टोरियामेट्रिक्स द्वारा स्पष्ट रूप से उपयोग किए जाते हैं।

कार्य हैं add, जो नए मान जोड़ता है। एक फंक्शन है has, जो नए मानों की जाँच करता है। और एक फंक्शन है del, जो मूल्यों को हटा देता है। एक सहायक कार्य है len, जो सेट का आकार लौटाता है। समारोह clone बहुत सारे क्लोन. और कार्य appendto इस सेट को स्लाइस में परिवर्तित करता है timeseries_ids.

इस डेटा संरचना का कार्यान्वयन इस प्रकार दिखता है। सेट में दो तत्व हैं:

• ItemsCount एक सेट में तत्वों की संख्या को तुरंत वापस करने के लिए एक सहायक फ़ील्ड है। इस सहायक फ़ील्ड के बिना ऐसा करना संभव होगा, लेकिन इसे यहां जोड़ना पड़ा क्योंकि विक्टोरियामेट्रिक्स अक्सर अपने एल्गोरिदम में बिटसेट लंबाई पर सवाल उठाता है।

• दूसरा क्षेत्र है buckets. यह संरचना से टुकड़ा है bucket32. प्रत्येक संरचना संग्रहित होती है hi मैदान। ये ऊपरी 32 बिट्स हैं. और दो टुकड़े - b16his и buckets से bucket16 संरचनाएँ।

16-बिट संरचना के दूसरे भाग के शीर्ष 64 बिट्स यहां संग्रहीत हैं। और यहां प्रत्येक बाइट के निचले 16 बिट्स के लिए बिटसेट संग्रहीत किए जाते हैं।

Bucket64 एक सरणी से मिलकर बनता है uint64. इन स्थिरांकों का उपयोग करके लंबाई की गणना की जाती है। एक में bucket16 अधिकतम भण्डारित किया जा सकता है 2^16=65536 अंश। अगर इसे 8 से भाग दें तो 8 किलोबाइट होता है. यदि आप पुनः 8 से विभाजित करें, तो यह 1000 होता है uint64 अर्थ। वह है Bucket16 - यह हमारी 8-किलोबाइट संरचना है।

आइए देखें कि नया मान जोड़ने के लिए इस संरचना की विधियों में से एक को कैसे कार्यान्वित किया जाता है।

यह सब शुरू होता है uint64 अर्थ. हम ऊपरी 32 बिट्स की गणना करते हैं, हम निचले 32 बिट्स की गणना करते हैं। आइए सब कुछ देखें buckets. हम प्रत्येक बकेट में शीर्ष 32 बिट्स की तुलना जोड़े जाने वाले मूल्य से करते हैं। और यदि वे मेल खाते हैं, तो हम फ़ंक्शन को कॉल करते हैं add संरचना बी32 में buckets. और वहां निचले 32 बिट्स जोड़ें। और अगर यह वापस आ गया true, तो इसका मतलब है कि हमने वहां ऐसा मूल्य जोड़ा और हमारे पास ऐसा कोई मूल्य नहीं था। अगर यह वापस आता है false, तो ऐसा अर्थ पहले से ही मौजूद था। फिर हम संरचना में तत्वों की संख्या बढ़ाते हैं।

यदि हमें वह नहीं मिला जिसकी आपको आवश्यकता है bucket आवश्यक हाई-वैल्यू के साथ, फिर हम फ़ंक्शन को कॉल करते हैं addAlloc, जो एक नया उत्पादन करेगा bucket, इसे बाल्टी संरचना में जोड़ना।

यह फ़ंक्शन का कार्यान्वयन है b32.add. यह पिछले कार्यान्वयन के समान है. हम सबसे महत्वपूर्ण 16 बिट्स, सबसे कम महत्वपूर्ण 16 बिट्स की गणना करते हैं।

फिर हम सभी ऊपरी 16 बिट्स से गुजरते हैं। हम मैच ढूंढते हैं। और यदि कोई मेल है, तो हम ऐड विधि को कॉल करते हैं, जिस पर हम अगले पृष्ठ पर विचार करेंगे bucket16.

और यहां सबसे निचला स्तर है, जिसे यथासंभव अनुकूलित किया जाना चाहिए। हम इसके लिए गणना करते हैं uint64 स्लाइस बिट में आईडी मान भी bitmask. यह दिए गए 64-बिट मान के लिए एक मास्क है, जिसका उपयोग इस बिट की उपस्थिति की जांच करने या इसे सेट करने के लिए किया जा सकता है। हम यह देखने के लिए जांच करते हैं कि क्या यह बिट सेट है और इसे सेट करते हैं, और उपस्थिति लौटाते हैं। यह हमारा कार्यान्वयन है, जिसने हमें पारंपरिक मानचित्रों की तुलना में समय श्रृंखला की आईडी को प्रतिच्छेद करने के संचालन को 10 गुना तेज करने की अनुमति दी है।

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

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

मेरे पास बिटसेट के बारे में एक प्रश्न है। C++ वेक्टर बूल कार्यान्वयन, अनुकूलित बिटसेट के समान। क्या आपने वहां से कार्यान्वयन लिया?

नहीं, वहां से नहीं. इस बिटसेट को लागू करते समय, मुझे इन आईडी टाइमसीरीज़ की संरचना के ज्ञान द्वारा निर्देशित किया गया था, जिसका उपयोग विक्टोरियामेट्रिक्स में किया जाता है। और उनकी संरचना ऐसी है कि ऊपरी 32 बिट मूलतः स्थिर हैं। निचले 32 बिट परिवर्तन के अधीन हैं। बिट जितना कम होगा, उतनी अधिक बार यह बदल सकता है। इसलिए, यह कार्यान्वयन इस डेटा संरचना के लिए विशेष रूप से अनुकूलित है। जहाँ तक मुझे पता है C++ कार्यान्वयन, सामान्य मामले के लिए अनुकूलित है। यदि आप सामान्य मामले के लिए अनुकूलन करते हैं, तो इसका मतलब है कि यह किसी विशिष्ट मामले के लिए सबसे इष्टतम नहीं होगा।

मैं आपको एलेक्सी मिलोविड की रिपोर्ट देखने की भी सलाह देता हूं। लगभग एक महीने पहले, उन्होंने विशिष्ट विशेषज्ञताओं के लिए ClickHouse में अनुकूलन के बारे में बात की थी। वह बस इतना कहते हैं कि सामान्य मामले में, C++ कार्यान्वयन या कोई अन्य कार्यान्वयन एक अस्पताल में औसतन अच्छा काम करने के लिए तैयार किया जाता है। यह हमारे जैसे ज्ञान-विशिष्ट कार्यान्वयन से भी बदतर प्रदर्शन कर सकता है, जहां हम जानते हैं कि शीर्ष 32 बिट्स अधिकतर स्थिर हैं।

मेरा दूसरा प्रश्न है. InfluxDB से मूलभूत अंतर क्या है?

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

दूसरा मूलभूत अंतर यह है कि InfluxDB में अजीब क्वेरी भाषाएँ हैं - फ्लक्स और InfluxQL। वे समय श्रृंखला की तुलना में काम करने के लिए बहुत सुविधाजनक नहीं हैं प्रोमक्यूएल, जो विक्टोरियामेट्रिक्स द्वारा समर्थित है। PromQL प्रोमेथियस की एक क्वेरी भाषा है।

और एक और अंतर यह है कि InfluxDB में थोड़ा अजीब डेटा मॉडल है, जहां प्रत्येक पंक्ति टैग के एक अलग सेट के साथ कई फ़ील्ड संग्रहीत कर सकती है। इन पंक्तियों को आगे विभिन्न तालिकाओं में विभाजित किया गया है। ये अतिरिक्त जटिलताएँ इस डेटाबेस के साथ बाद के काम को जटिल बनाती हैं। इसका समर्थन करना और समझना कठिन है।

विक्टोरियामेट्रिक्स में सब कुछ बहुत सरल है। वहां, प्रत्येक समय श्रृंखला एक कुंजी-मूल्य है। मान बिंदुओं का एक सेट है - (timestamp, value), और कुंजी सेट है label=value. फ़ील्ड और माप के बीच कोई अलगाव नहीं है। यह आपको किसी भी डेटा का चयन करने और फिर उसे जोड़ने, जोड़ने, घटाने, गुणा करने, विभाजित करने की अनुमति देता है, इन्फ्लक्सडीबी के विपरीत जहां विभिन्न पंक्तियों के बीच गणना अभी भी लागू नहीं की गई है जहां तक ​​​​मुझे पता है। अगर इन्हें लागू भी किया जाए तो भी यह मुश्किल है, आपको बहुत सारे कोड लिखने होंगे।

मेरे पास एक स्पष्ट प्रश्न है. क्या मैं सही ढंग से समझ पाया कि किसी प्रकार की समस्या थी जिसके बारे में आपने बात की थी, कि यह उलटा सूचकांक मेमोरी में फिट नहीं होता है, इसलिए वहां विभाजन हो रहा है?

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

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

मैं तुरंत दूसरे का उत्तर दूँगा। हम अभी तक उस बिंदु तक नहीं पहुंचे हैं. लेकिन यदि आवश्यक हुआ तो हम वहां पहुंचेंगे।' और पहला, सवाल क्या था?

आपने दो परिदृश्यों पर चर्चा की. और उन्होंने कहा कि उन्होंने अधिक जटिल कार्यान्वयन वाले दूसरे को चुना। और उन्होंने पहले वाले को पसंद नहीं किया, जहां डेटा को समय के अनुसार विभाजित किया जाता है।

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

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

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

हम डेटा को पार करने के लिए कर्सर का उपयोग क्यों नहीं करते?

हां.

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

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

मैं इसे स्पष्ट करने के लिए एक उदाहरण दूँगा। आइए बताते हैं कि एक छोटा खिलौना स्पीडोमीटर कैसे काम करता है? यह आपके द्वारा तय की गई दूरी को रिकॉर्ड करता है, हर समय इसे एक मान में जोड़ता है, और दूसरे में - समय। और बांट देता है. और औसत स्पीड मिलती है. आप लगभग वही कार्य कर सकते हैं. तुरंत सभी आवश्यक तथ्य जोड़ें।

ठीक है, मैं प्रश्न समझता हूँ। आपका उदाहरण अपनी जगह है. यदि आप जानते हैं कि आपको किन समुच्चय की आवश्यकता है, तो यह सर्वोत्तम कार्यान्वयन है। लेकिन समस्या यह है कि लोग इन मेट्रिक्स, कुछ डेटा को ClickHouse में सहेजते हैं और वे अभी तक नहीं जानते हैं कि वे भविष्य में उन्हें कैसे एकत्रित और फ़िल्टर करेंगे, इसलिए उन्हें सभी कच्चे डेटा को सहेजना होगा। लेकिन अगर आप जानते हैं कि आपको औसत में कुछ गणना करने की आवश्यकता है, तो वहां कच्चे मूल्यों का एक समूह संग्रहीत करने के बजाय इसकी गणना क्यों न करें? लेकिन यह तभी है जब आप ठीक-ठीक जानते हों कि आपको क्या चाहिए।

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

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

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

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

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

एक अन्य विशेषता यह है कि विक्टोरियामेट्रिक्स इस डेटा को प्रभावी ढंग से संपीड़ित करता है। उत्पादन में औसतन संपीड़न 0,4 से 0,8 बाइट्स प्रति बिंदु है। प्रत्येक बिंदु एक टाइमस्टैम्प + मान है। और यह औसतन एक बाइट से भी कम में संपीड़ित होता है।

सेर्गेई. मेरा एक सवाल है। न्यूनतम रिकॉर्डिंग समय मात्रा क्या है?

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

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

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

धन्यवाद! और दूसरा प्रश्न. PromQL में अनुकूलता क्या है?

पूर्ण पश्चगामी अनुकूलता. विक्टोरियामेट्रिक्स पूरी तरह से PromQL का समर्थन करता है। इसके अलावा, यह PromQL में अतिरिक्त उन्नत कार्यक्षमता जोड़ता है, जिसे कहा जाता है मेट्रिक्सक्यूएल. इस विस्तारित कार्यक्षमता के बारे में YouTube पर चर्चा चल रही है। मैंने सेंट पीटर्सबर्ग में वसंत ऋतु में मॉनिटरिंग मीटअप में बात की थी।

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

आपको प्रोमेथियस के लिए दीर्घकालिक भंडारण के रूप में विक्टोरियामेट्रिक्स पर स्विच करने से कौन रोक रहा है? (टिप्पणियों में लिखें, मैं इसे मतदान में जोड़ दूंगा))

• 71,4% तक मैं प्रोमेथियस5 का उपयोग नहीं करता

• 28,6% तक विक्टोरियामेट्रिक्स2 के बारे में नहीं पता था

7 उपयोगकर्ताओं ने मतदान किया। 12 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com