VictoriaMetrics मा अनुकूलन जानुहोस्। अलेक्जेंडर Valyalkin

म तपाईंलाई अलेक्ज्याण्डर भ्याल्किन "भिक्टोरियामेट्रिक्समा अप्टिमाइजेसनहरू जानुहोस्" द्वारा लेट 2019 रिपोर्टको ट्रान्सक्रिप्ट पढ्न सुझाव दिन्छु।

भिक्टोरियामेट्रिक्स - एक समय श्रृंखला को रूप मा डाटा भण्डारण र प्रशोधन को लागी एक छिटो र स्केलेबल DBMS (रेकर्ड फारम समय र यस समय संगत मान को एक सेट, उदाहरण को लागी, सेन्सर को स्थिति को आवधिक मतदान द्वारा प्राप्त वा को संग्रह। मेट्रिक्स)।

यो रिपोर्टको भिडियोको लिङ्क यहाँ छ- https://youtu.be/MZ5P21j_HLE

स्लाइड

हामीलाई आफ्नो बारेमा बताउनुहोस्। म अलेक्जेंडर Valyalkin हुँ। यहाँ मेरो GitHub खाता। म गो र कार्यसम्पादन अप्टिमाइजेसनको बारेमा भावुक छु। मैले धेरै उपयोगी र धेरै उपयोगी पुस्तकालयहरू लेखें। तिनीहरू दुवैबाट सुरु गर्छन् fast, वा संग quick उपसर्ग।

म हाल VictoriaMetrics मा काम गर्दैछु। यो के हो र म त्यहाँ के गर्दै छु? म यस प्रस्तुतिमा यस बारे कुरा गर्नेछु।

प्रतिवेदनको रूपरेखा यस प्रकार छ:

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

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

VictoriaMetrics ले अन्य समय श्रृंखला डेटाबेसहरू भन्दा राम्रो डेटा सङ्कुचन प्रदान गर्दछ।

यो ठाडो मापन गर्दछ - त्यो हो, तपाइँ एक कम्प्युटरमा थप प्रोसेसरहरू, थप RAM थप्न सक्नुहुन्छ। VictoriaMetrics ले यी उपलब्ध स्रोतहरू सफलतापूर्वक प्रयोग गर्नेछ र रैखिक उत्पादकता सुधार गर्नेछ।

VictoriaMetrics ले तेर्सो मापन पनि गर्छ - त्यो हो, तपाईंले VictoriaMetrics क्लस्टरमा थप नोडहरू थप्न सक्नुहुन्छ, र यसको कार्यसम्पादन लगभग रेखीय रूपमा बढ्नेछ।

तपाईंले अनुमान गरे अनुसार, VictoriaMetrics एक द्रुत डाटाबेस हो, किनकि म अरूलाई लेख्न सक्दिन। र यो Go मा लेखिएको छ, त्यसैले म यस भेटमा यसको बारेमा कुरा गर्दैछु।

समय श्रृंखला के हो कसलाई थाहा छ? उसले पनि धेरैलाई चिन्छ । एक समय श्रृंखला जोडी को एक श्रृंखला हो (timestamp, значение), जहाँ यी जोडीहरू समय अनुसार क्रमबद्ध हुन्छन्। मान फ्लोटिंग बिन्दु नम्बर हो - float64।

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

यहाँ समय श्रृंखला को एक उदाहरण हो। यस श्रृंखलाको कुञ्जी जोडीहरूको सूची हो: __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 बारेमा सुनेका छन्। यो प्रोमेथियस क्वेरी भाषा हो।

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

यो दुई भाग मिलेर बनेको छ। यो उल्टो अनुक्रमणिकाको लागि भण्डारण र समय श्रृंखला मानहरूको लागि भण्डारण हो। यी भण्डारहरू अलग छन्।

जब डाटाबेसमा नयाँ रेकर्ड आउँछ, हामी पहिले दिइएको सेटको लागि समय श्रृंखला पहिचानकर्ता फेला पार्न उल्टो अनुक्रमणिका पहुँच गर्छौं। 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), जसले स्ट्रिङलाई स्लाइस ints मा नक्सा गर्नेछ। रेखा समावेश छ label=value.

प्रकार्य कार्यान्वयन: प्राप्त गर्नुहोस् metricIDs पहिलो को लागी label=value, त्यसपछि हामी सबै कुरा मार्फत जान्छौं label=value, हामीले पाउँछौं metricIDs उनीहरुको लागि। र समारोह कल गर्नुहोस् intersectInts, जुन तल छलफल गरिनेछ। र यो प्रकार्यले यी सूचीहरूको प्रतिच्छेदन फर्काउँछ।

तपाईले देख्न सक्नुहुने रूपमा, उल्टो अनुक्रमणिका लागू गर्नु धेरै जटिल छैन। तर यो निष्कपट कार्यान्वयन हो । यसका के बेफाइदाहरू छन्? सरल कार्यान्वयनको मुख्य हानि भनेको यस्तो उल्टो अनुक्रमणिका RAM मा भण्डारण गरिएको छ। अनुप्रयोग पुन: सुरु गरेपछि हामीले यो अनुक्रमणिका गुमाउँछौं। डिस्कमा यो अनुक्रमणिकाको कुनै बचत छैन। यस्तो उल्टो सूचकांक डाटाबेसको लागि उपयुक्त हुने सम्भावना छैन।

दोस्रो कमजोरी पनि मेमोरीसँग सम्बन्धित छ। उल्टो अनुक्रमणिका RAM मा फिट हुनुपर्छ। यदि यसले RAM को आकार नाघ्यो भने, स्पष्ट रूपमा हामी प्राप्त गर्नेछौं - मेमोरी त्रुटिबाट बाहिर। र कार्यक्रम काम गर्दैन।

यो समस्या तयार समाधान जस्तै प्रयोग गरेर हल गर्न सकिन्छ स्तरडीबी, वा RocksDB.

छोटकरीमा, हामीलाई एक डाटाबेस चाहिन्छ जसले हामीलाई तीनवटा अपरेशनहरू छिटो गर्न अनुमति दिन्छ।

• पहिलो अपरेशन रेकर्डिङ हो ключ-значение यस डेटाबेसमा। उनी यो धेरै छिटो गर्छिन्, जहाँ ключ-значение स्वैच्छिक तारहरू छन्।
• दोस्रो अपरेशन दिइएको कुञ्जी प्रयोग गरी मानको लागि द्रुत खोज हो।
• र तेस्रो अपरेशन दिइएको उपसर्ग द्वारा सबै मानहरूको लागि द्रुत खोज हो।

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

लेवलडीबी प्रयोग गरेर उल्टो अनुक्रमणिका लागू गर्न सकिन्छ। यो कसरी गर्ने? हामी कुञ्जीको रूपमा बचत गर्छौं label=value। र मान समय श्रृंखला को पहिचानकर्ता हो जहाँ जोडी उपस्थित छ label=value.

यदि हामीसँग दिइएको जोडीसँग धेरै समय श्रृंखला छ label=value, त्यसपछि यो डाटाबेसमा एउटै कुञ्जी र फरकसँग धेरै पङ्क्तिहरू हुनेछन् timeseries_ids। सबैको सूची प्राप्त गर्न timeseries_ids, जुन यसबाट सुरु हुन्छ label=prefix, हामी दायरा स्क्यान गर्छौं जसको लागि यो डाटाबेस अप्टिमाइज गरिएको छ। त्यो हो, हामी सुरु हुने सबै रेखाहरू चयन गर्छौं label=prefix र आवश्यक पाउनुहोस् timeseries_ids.

यो Go मा कस्तो देखिनेछ भन्ने बारे यहाँ एउटा नमूना कार्यान्वयन छ। हामीसँग उल्टो सूचकांक छ। यो LevelDB हो।

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

सबै कुरा ठीक देखिन्छ, तर यस समाधानमा कमजोरीहरू छन्। VictoriaMetrics ले सुरुमा LevelDB मा आधारित एक उल्टो सूचकांक लागू गर्यो। तर अन्तमा मैले त्यसलाई त्याग्नुपर्‍यो।

किन? किनभने LevelDB सरल कार्यान्वयन भन्दा ढिलो छ। एक सरल कार्यान्वयनमा, दिइएको कुञ्जी दिएर, हामी तुरुन्तै सम्पूर्ण टुक्रा पुन: प्राप्त गर्छौं metricIDs। यो एक धेरै छिटो सञ्चालन छ - सम्पूर्ण टुक्रा प्रयोगको लागि तयार छ।

LevelDB मा, प्रत्येक पटक एक प्रकार्य कल गरिन्छ GetValues तपाईंले सुरु हुने सबै लाइनहरू मार्फत जान आवश्यक छ label=value। र प्रत्येक रेखाको लागि मूल्य प्राप्त गर्नुहोस् timeseries_ids। यस्तो timeseries_ids यी एक टुक्रा सङ्कलन timeseries_ids। जाहिर छ, यो कुञ्जी द्वारा नियमित नक्सा पहुँच गर्नु भन्दा धेरै ढिलो छ।

दोस्रो कमजोरी यो हो कि LevelDB C मा लेखिएको छ। Go बाट C प्रकार्यहरू कल गर्ने धेरै छिटो हुँदैन। यसले सयौं नानोसेकेन्डहरू लिन्छ। यो धेरै छिटो छैन, किनकि गो मा लेखिएको नियमित प्रकार्य कलको तुलनामा, जसमा १-५ नानोसेकेन्ड लाग्छ, प्रदर्शनमा फरक दशौं पटक हुन्छ। VictoriaMetrics को लागि यो एक घातक दोष थियो :)

त्यसैले मैले उल्टो अनुक्रमणिकाको आफ्नै कार्यान्वयन लेखें। अनि उसलाई बोलायो मर्जसेट.

Mergeset MergeTree डाटा संरचनामा आधारित छ। यो डाटा संरचना ClickHouse बाट उधारिएको हो। स्पष्ट रूपमा, मर्जसेट छिटो खोजको लागि अनुकूलित हुनुपर्छ timeseries_ids दिइएको कुञ्जी अनुसार। मर्जसेट पूर्ण रूपमा Go मा लेखिएको छ। तपाईं हेर्न सक्नुहुन्छ GitHub मा VictoriaMetrics स्रोतहरू। मर्जसेटको कार्यान्वयन फोल्डरमा छ /lib/mergeset। तपाईं त्यहाँ के भइरहेको छ भनेर पत्ता लगाउन प्रयास गर्न सक्नुहुन्छ।

मर्जसेट API LevelDB र RocksDB सँग धेरै मिल्दोजुल्दो छ। त्यो हो, यसले तपाइँलाई त्यहाँ नयाँ रेकर्डहरू द्रुत रूपमा बचत गर्न र दिइएको उपसर्गद्वारा द्रुत रूपमा रेकर्डहरू चयन गर्न अनुमति दिन्छ।

मर्जसेटका बेफाइदाहरूको बारेमा हामी पछि कुरा गर्नेछौं। अब एक उल्टो अनुक्रमणिका लागू गर्दा उत्पादन मा VictoriaMetrics संग के समस्या उत्पन्न भएको बारे कुरा गरौं।

तिनीहरू किन उठे?

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

दोस्रो कारण समय श्रृंखला को ठूलो संख्या हो। सुरुमा, जब अनुगमन लोकप्रियता प्राप्त गर्दै थियो, समय श्रृंखला को संख्या सानो थियो। उदाहरणका लागि, प्रत्येक कम्प्युटरको लागि तपाईंले CPU, मेमोरी, नेटवर्क र डिस्क लोड निगरानी गर्न आवश्यक छ। प्रति कम्प्यूटर 4 समय श्रृंखला। मानौं तपाईसँग 100 कम्प्युटर र 400 टाइम शृङ्खलाहरू छन्। यो धेरै थोरै हो।

समयको साथ, मानिसहरूले पत्ता लगाए कि उनीहरूले थप दानेदार जानकारी मापन गर्न सक्छन्। उदाहरण को लागी, सम्पूर्ण प्रोसेसर को लोड मापन गर्नुहोस्, तर प्रत्येक प्रोसेसर कोर को अलग। यदि तपाइँसँग 40 प्रोसेसर कोर छ भने, तपाइँसँग प्रोसेसर लोड मापन गर्न 40 गुणा बढी समय श्रृंखला छ।

तर त्यो सबै होइन। प्रत्येक प्रोसेसर कोरमा धेरै अवस्थाहरू हुन सक्छन्, जस्तै निष्क्रिय, जब यो निष्क्रिय हुन्छ। र प्रयोगकर्ता स्पेसमा पनि काम गर्नुहोस्, कर्नेल स्पेस र अन्य राज्यहरूमा काम गर्नुहोस्। र त्यस्ता प्रत्येक अवस्थालाई छुट्टै समय श्रृंखलाको रूपमा पनि मापन गर्न सकिन्छ। यसले पङ्क्तिहरूको संख्या 7-8 पटक बढाउँछ।

एउटा मेट्रिकबाट हामीले एउटा कम्प्युटरको लागि 40 x 8 = 320 मेट्रिक्स पायौं। 100 ले गुणन गर्दा 32 को सट्टा 000 प्राप्त हुन्छ।

त्यसपछि Kubernetes पनि आए। र यो खराब भयो किनभने Kubernetes ले धेरै फरक सेवाहरू होस्ट गर्न सक्छ। Kubernetes मा प्रत्येक सेवामा धेरै पोडहरू हुन्छन्। र यो सबै अनुगमन गर्न आवश्यक छ। थप रूपमा, हामीसँग तपाईंको सेवाहरूको नयाँ संस्करणहरूको निरन्तर तैनाती छ। प्रत्येक नयाँ संस्करणको लागि, नयाँ समय श्रृंखला सिर्जना गर्नुपर्छ। नतिजाको रूपमा, समय श्रृंखलाहरूको संख्या द्रुत रूपमा बढ्छ र हामीले ठूलो संख्याको समय श्रृंखलाको समस्याको सामना गरिरहेका छौं, जसलाई उच्च-कार्डिनलिटी भनिन्छ। VictoriaMetrics ले अन्य समय श्रृंखला डाटाबेसहरूको तुलनामा सफलतापूर्वक यसको सामना गर्दछ।

उच्च मन्थन दरमा नजिकबाट हेरौं। उत्पादनमा उच्च मन्थन दरको कारण के हो? किनभने लेबल र ट्यागका केही अर्थहरू निरन्तर परिवर्तन भइरहेका छन्।

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

यसले के निम्त्यायो? यसबाहेक, प्रत्येक नयाँ परिनियोजनको साथ, सबै पुरानो समय श्रृंखलाहरू अवरुद्ध हुन्छन्, र तिनीहरूको सट्टा, नयाँ समय श्रृंखला नयाँ लेबल मानको साथ सुरु हुन्छ। deployment_id। त्यस्ता पङ्क्तिहरू हजारौं र लाखौं हुन सक्छन्।

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

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

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

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

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

यो समस्या समाधान गर्न अर्को विकल्प छ। यो प्रत्येक दिनको लागि त्यो दिन भएको समय श्रृंखला को आईडी को एक अलग सूची भण्डारण गर्न को लागी हो।

अघिल्लो समाधानको तुलनामा यस समाधानको फाइदा यो हो कि हामी समय श्रृङ्खला जानकारी नक्कल गर्दैनौं जुन समयसँगै गायब हुँदैन। तिनीहरू निरन्तर उपस्थित छन् र परिवर्तन गर्दैनन्।

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

मैले उनीसँग लड्नु परेको थियो । संघर्ष यो थियो कि यो कार्यान्वयनमा तपाईले अझै धेरै ठूलो संख्या रोज्नु पर्छ timeseries_ids उल्टो अनुक्रमणिका समय विभाजन भएको भन्दा डाटाको लागि।

हामीले यो समस्या कसरी समाधान गर्यौं? हामीले यसलाई मौलिक तरिकामा समाधान गर्यौं - एक पहिचानकर्ताको सट्टा प्रत्येक उल्टो अनुक्रमणिका प्रविष्टिमा धेरै समय श्रृंखला पहिचानकर्ताहरू भण्डारण गरेर। त्यो हो, हामीसँग एउटा चाबी छ label=value, जुन हरेक समय श्रृंखलामा हुन्छ। र अब हामी धेरै बचत गर्छौं timeseries_ids एक प्रविष्टि मा।

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

यसले यस्तो उल्टो अनुक्रमणिकाको स्क्यानिङ गतिलाई १० पटकसम्म बढाउन सम्भव बनायो। र यसले हामीलाई क्यासको लागि मेमोरी खपत कम गर्न अनुमति दियो, किनकि अब हामी स्ट्रिङ भण्डार गर्छौं label=value क्यासमा सँगै N पटक मात्र एक पटक। र यो रेखा ठूलो हुन सक्छ यदि तपाइँ तपाइँको ट्याग र लेबलहरूमा लामो लाइनहरू भण्डार गर्नुहुन्छ, जसलाई कुबर्नेट्सले त्यहाँ धकेल्न मन पराउँछन्।

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

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

पहिलो विकल्प सरल कार्यान्वयन हो। दुई नेस्टेड लूपहरू। यहाँ हामीले प्रकार्य इनपुट पाउँछौं intersectInts दुई टुक्रा - a и b। आउटपुटमा, यसले हामीलाई यी स्लाइसहरूको प्रतिच्छेदनमा फर्काउनु पर्छ।

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

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

दोस्रो कार्यान्वयन नक्सामा आधारित छ। नक्सा बनाउँछौं । हामीले यस नक्सामा टुक्राबाट सबै मानहरू राख्यौं a। त्यसपछि हामी छुट्टै लूपमा टुक्रा मार्फत जान्छौं b। र हामी जाँच गर्छौं कि यो मान टुक्राबाट हो b नक्सामा। यदि यो अवस्थित छ भने, त्यसपछि परिणाममा थप्नुहोस्।

के फाइदाहरू छन्? फाइदा यो छ कि त्यहाँ केवल रैखिक जटिलता छ। त्यो हो, प्रकार्यले ठूला स्लाइसहरूको लागि धेरै छिटो कार्यान्वयन गर्नेछ। एक मिलियन-साइज स्लाइसको लागि, यो प्रकार्यले अघिल्लो प्रकार्यको ट्रिलियन पुनरावृत्तिको विपरीत, 2 मिलियन पुनरावृत्तिहरूमा कार्यान्वयन गर्नेछ।

नकारात्मक पक्ष यो हो कि यो नक्सा सिर्जना गर्न यस प्रकार्यलाई थप मेमोरी चाहिन्छ।

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

किन यी ठाउँहरूमा CPU समय बर्बाद हुन्छ? किनभने Go ले यी लाइनहरूमा ह्यासिङ अपरेशन गर्दछ। त्यो हो, यसले HashMap मा दिइएको अनुक्रमणिकामा पहुँच गर्न कुञ्जीको ह्यास गणना गर्दछ। ह्यास गणना कार्य दसौं नानोसेकेन्डमा पूरा हुन्छ। यो VictoriaMetrics को लागि ढिलो छ।

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

पहिलो नजरमा, यस्तो देखिन्छ कि यसले ढिलो काम गर्नुपर्छ, यदि पहिले त्यहाँ मानक नक्सा प्रयोग गरिएको थियो, र त्यसपछि केही अन्य प्रकार्यहरू बोलाइन्छ, तर प्रोफाइलिङले देखाउँछ कि यो चीज VictoriaMetrics को मामला मा मानक नक्सा भन्दा 10 गुणा छिटो काम गर्दछ।

थप रूपमा, यसले नक्सा कार्यान्वयनको तुलनामा धेरै कम मेमोरी प्रयोग गर्दछ। किनभने हामी यहाँ आठ-बाइट मानहरूको सट्टा बिटहरू भण्डारण गर्दैछौं।

यो कार्यान्वयनको बेफाइदा यो हो कि यो स्पष्ट छैन, मामूली छैन।

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

यो संरचना को कार्यान्वयन विचार गरौं। यदि तपाइँ हेर्न चाहनुहुन्छ भने, यो फोल्डरमा VictoriaMetrics स्रोतहरूमा अवस्थित छ lib/uint64set। यो विशेष गरी VictoriaMetrics मामला को लागी अनुकूलित छ, जहाँ timeseries_id एक 64-बिट मान हो, जहाँ पहिलो 32 बिटहरू मूल रूपमा स्थिर हुन्छन् र केवल अन्तिम 32 बिटहरू परिवर्तन हुन्छन्।

यो डाटा संरचना डिस्कमा भण्डार गरिएको छैन, यो केवल मेमोरीमा सञ्चालन हुन्छ।

यहाँ यसको API छ। यो धेरै जटिल छैन। एपीआई विशेष रूपमा VictoriaMetrics प्रयोग गर्ने एक विशेष उदाहरण अनुरूप बनाइएको छ। अर्थात्, यहाँ कुनै अनावश्यक कार्यहरू छैनन्। यहाँ कार्यहरू छन् जुन स्पष्ट रूपमा 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। र त्यहाँ तल्लो 32 बिट थप्नुहोस्। र यदि यो फिर्ता भयो true, त्यसोभए यसको मतलब हामीले त्यहाँ त्यस्तो मान थप्यौं र हामीसँग त्यस्तो मूल्य छैन। यदि यो फर्काउँछ false, त्यसपछि यस्तो अर्थ पहिले नै अवस्थित थियो। त्यसपछि हामी संरचनामा तत्वहरूको संख्या बढाउँछौं।

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

यो कार्य को कार्यान्वयन हो b32.add। यो अघिल्लो कार्यान्वयन जस्तै छ। हामी सबैभन्दा महत्त्वपूर्ण 16 बिटहरू, सबैभन्दा महत्त्वपूर्ण 16 बिटहरू गणना गर्छौं।

त्यसपछि हामी सबै माथिल्लो 16 बिट्स मार्फत जान्छौं। हामी मिल्दोजुल्दो फेला पार्छौं। र यदि त्यहाँ मिल्दोजुल्दो छ भने, हामी थप विधिलाई कल गर्छौं, जसको लागि हामी अर्को पृष्ठमा विचार गर्नेछौं bucket16.

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

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

यो अप्टिमाइजेसनको मुख्य नियम हो - अप्टिमाइजेसन थप नगर्नुहोस् कि यहाँ कुनै बाधा हुनेछ, किनकि यसले त्यहाँ कुनै बाधा नहुन सक्छ। अप्टिमाइजेसनले सामान्यतया कोडको गुणस्तर घटाउँछ। तसर्थ, यो प्रोफाईल र अधिमानतः उत्पादन पछि मात्र अनुकूलन लायक छ, ताकि यो वास्तविक डाटा हो। यदि कसैलाई रुचि छ भने, तपाईंले VictoriaMetrics स्रोत कोड हेर्न सक्नुहुन्छ र त्यहाँ रहेका अन्य अप्टिमाइजेसनहरू अन्वेषण गर्न सक्नुहुन्छ।

मसँग बिटसेटको बारेमा प्रश्न छ। C++ भेक्टर बूल कार्यान्वयन, अनुकूलित बिटसेटसँग धेरै मिल्दोजुल्दो। त्यहाँबाट कार्यान्वयनमा ल्याउनुभएको हो ?

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

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

मसँग दोस्रो प्रश्न छ। InfluxDB बाट आधारभूत भिन्नता के हो?

त्यहाँ धेरै आधारभूत भिन्नताहरू छन्। प्रदर्शन र मेमोरी खपतको सन्दर्भमा, परीक्षणहरूमा InfluxDB ले उच्च कार्डिनलिटी समय श्रृंखलाको लागि १० गुणा बढी मेमोरी खपत देखाउँछ, जब तपाईंसँग ती धेरै छन्, उदाहरणका लागि, लाखौं। उदाहरणका लागि, VictoriaMetrics ले 10 GB प्रति मिलियन सक्रिय पङ्क्तिहरू खपत गर्छ, जबकि InfluxDB ले 1 GB खपत गर्छ। र त्यो ठूलो भिन्नता हो।

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

र एउटा थप भिन्नता यो हो कि InfluxDB सँग थोरै अनौठो डाटा मोडेल छ, जहाँ प्रत्येक रेखाले ट्यागहरूको फरक सेटसँग धेरै क्षेत्रहरू भण्डारण गर्न सक्छ। यी रेखाहरू थप विभिन्न तालिकाहरूमा विभाजित छन्। यी अतिरिक्त जटिलताहरूले यस डाटाबेसको साथ पछिको कामलाई जटिल बनाउँछ। समर्थन गर्न र बुझ्न गाह्रो छ।

VictoriaMetrics मा सबै धेरै सरल छ। त्यहाँ, प्रत्येक पटक श्रृंखला एक प्रमुख-मान हो। मान बिन्दुहरूको सेट हो - (timestamp, value), र कुञ्जी सेट हो label=value। क्षेत्र र मापन बीच कुनै विभाजन छैन। यसले तपाईंलाई कुनै पनि डेटा चयन गर्न र त्यसपछि संयोजन, थप, घटाउ, गुणन, विभाजन गर्न अनुमति दिन्छ, InfluxDB को विपरीत जहाँसम्म मलाई थाहा भएसम्म विभिन्न पङ्क्तिहरू बीचको गणनाहरू लागू गरिएको छैन। तिनीहरू लागू भए पनि, यो गाह्रो छ, तपाईंले धेरै कोड लेख्नुपर्छ।

मसँग स्पष्ट प्रश्न छ। के मैले ठीकसँग बुझें कि त्यहाँ केहि प्रकारको समस्या थियो जसको बारेमा तपाईंले कुरा गर्नुभयो, कि यो उल्टो अनुक्रमणिका मेमोरीमा फिट हुँदैन, त्यसैले त्यहाँ विभाजन भइरहेको छ?

पहिले, मैले मानक गो नक्सामा उल्टो अनुक्रमणिकाको सरल कार्यान्वयन देखाएँ। यो कार्यान्वयन डेटाबेसहरूको लागि उपयुक्त छैन किनभने यो उल्टो अनुक्रमणिका डिस्कमा बचत गरिएको छैन, र डाटाबेसले डिस्कमा बचत गर्नुपर्छ ताकि यो डाटा पुन: सुरु गर्दा उपलब्ध रहन्छ। यो कार्यान्वयनमा, जब तपाइँ अनुप्रयोग पुन: सुरु गर्नुहुन्छ, तपाइँको उल्टो अनुक्रमणिका गायब हुनेछ। र तपाईंले सबै डेटामा पहुँच गुमाउनुहुनेछ किनभने तपाईंले यसलाई फेला पार्न सक्नुहुन्न।

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

म तुरुन्तै दोस्रो जवाफ दिनेछु। हामी अहिलेसम्म त्यो बिन्दुमा पुगेका छैनौं। तर आवश्यक भएमा हामी त्यहाँ पुग्छौं। र पहिलो, प्रश्न के थियो?

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

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

र त्यसैले - हो, समय विभाजन एक राम्रो विकल्प हो। प्रोमेथियसले यसलाई प्रयोग गर्दछ। तर प्रोमेथियसको अर्को कमजोरी छ। डाटाका यी टुक्राहरू मर्ज गर्दा, यसले सबै लेबल र टाइम्सरीहरूको लागि मेमोरी मेटा जानकारी राख्न आवश्यक छ। त्यसकारण, यदि यसले मर्ज गर्ने डाटाका टुक्राहरू ठूला हुन्छन् भने, विक्टोरियामेट्रिक्सको विपरीत, मर्ज गर्दा मेमोरी खपत धेरै बढ्छ। मर्ज गर्दा, VictoriaMetrics ले मेमोरी उपभोग गर्दैन; डेटाको मर्ज गरिएका टुक्राहरूको आकारलाई ध्यान नदिई केही किलोबाइट मात्र खपत हुन्छ।

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

हामी किन डाटा ट्र्याभर गर्न कर्सर प्रयोग गर्दैनौं?

हो।

हामी LevelDB वा मर्जसेटमा क्रमबद्ध पङ्क्तिहरू भण्डार गर्छौं। हामी कर्सर सार्न सक्छौं र प्रतिच्छेदन फेला पार्न सक्छौं। हामी यसलाई किन प्रयोग गर्दैनौं? किनभने यो ढिलो छ। किनभने कर्सरहरूले प्रत्येक रेखाको लागि प्रकार्य कल गर्न आवश्यक छ। एक प्रकार्य कल 5 न्यानोसेकेन्ड छ। र यदि तपाईंसँग 100 लाइनहरू छन् भने, त्यसपछि यो बाहिर जान्छ कि हामी केवल प्रकार्य कल गर्न आधा सेकेन्ड खर्च गर्छौं।

त्यहाँ यस्तो चीज छ, हो। र मेरो अन्तिम प्रश्न। प्रश्न अलि अनौठो लाग्न सक्छ। डाटा आइपुग्दा सबै आवश्यक एग्रीगेटहरू पढ्न र आवश्यक फारममा बचत गर्न किन सम्भव छैन? VictoriaMetrics, ClickHouse, आदि जस्ता केही प्रणालीहरूमा किन ठूलो मात्राहरू बचत गर्ने, र त्यसपछि तिनीहरूमा धेरै समय खर्च गर्ने?

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

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

वैसे, समय शृङ्खला भण्डारण गर्नका लागि डाटाबेसहरूले समुच्चयहरूको गणना समर्थन गर्दछ। उदाहरणका लागि, प्रोमेथियसले समर्थन गर्दछ रेकर्डिङ नियम। त्यो हो, यो गर्न सकिन्छ यदि तपाईलाई थाहा छ तपाईलाई कुन एकाइहरू चाहिन्छ। VictoriaMetrics सँग यो अझै छैन, तर यो सामान्यतया प्रोमेथियसको अगाडि हुन्छ, जसमा यो रिकोडिङ नियमहरूमा गर्न सकिन्छ।

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

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

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

र दोस्रो कुरा यो हो कि VictoriaMetrics, ClickHouse जस्तै, ठूलो मात्रामा कच्चा डाटामा काम गर्नको लागि अनुकूलित छ, त्यसैले यदि तपाइँसँग तपाइँको प्रणालीमा धेरै कोरहरू छन् भने यसले एक सेकेन्ड भन्दा कममा एक अरब लाइनहरू फाल्न सक्छ। VictoriaMetrics मा स्क्यानिङ समय श्रृंखला अंक - 50 अंक प्रति सेकेन्ड प्रति कोर। र यो प्रदर्शन विद्यमान कोरहरूमा मापन गर्दछ। त्यो हो, यदि तपाईंसँग 000 कोरहरू छन्, उदाहरणका लागि, तपाईंले प्रति सेकेन्ड एक अरब अंक स्क्यान गर्नुहुनेछ। र VictoriaMetrics र ClickHouse को यो सम्पत्तीले downsamling को आवश्यकता कम गर्दछ।

अर्को विशेषता भनेको VictoriaMetrics ले यो डाटालाई प्रभावकारी रूपमा कम्प्रेस गर्छ। उत्पादनमा औसतमा कम्प्रेसन ०.४ देखि ०.८ बाइट्स प्रति बिन्दु हो। प्रत्येक बिन्दु टाइमस्ट्याम्प + मान हो। र यो औसतमा एक बाइट भन्दा कम मा संकुचित छ।

सर्गेई। मलाई केहि सोध्नु छ। न्यूनतम रेकर्डिङ समय क्वान्टम के हो?

एक मिलिसेकेन्ड। हामीले भर्खरै अन्य समय श्रृंखला डाटाबेस विकासकर्ताहरूसँग कुराकानी गरेका थियौं। तिनीहरूको न्यूनतम समय स्लाइस एक सेकेन्ड हो। र ग्रेफाइटमा, उदाहरणका लागि, यो पनि एक सेकेन्ड हो। OpenTSDB मा यो पनि एक सेकेन्ड हो। InfluxDB सँग नानोसेकेन्ड परिशुद्धता छ। VictoriaMetrics मा यो एक मिलिसेकेन्ड हो, किनभने Prometheus मा यो एक मिलिसेकेन्ड हो। र VictoriaMetrics मूल रूपमा Prometheus को लागि रिमोट भण्डारण को रूप मा विकसित गरिएको थियो। तर अब यसले अन्य प्रणालीबाट डाटा बचत गर्न सक्छ।

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

VictoriaMetrics मा मिलिसेकेन्ड शुद्धता DevOps केसको लागि पनि उपयुक्त छ, र मैले रिपोर्टको सुरुमा उल्लेख गरेको धेरै जसो केसहरूको लागि उपयुक्त हुन सक्छ। एक मात्र चीज जसको लागि यो उपयुक्त नहुन सक्छ उच्च आवृत्ति व्यापार प्रणाली हो।

धन्यवाद! र अर्को प्रश्न। PromQL मा अनुकूलता के हो?

पूर्ण पछाडि अनुकूलता। VictoriaMetrics ले PromQL लाई पूर्ण रूपमा समर्थन गर्दछ। थप रूपमा, यसले PromQL मा थप उन्नत कार्यक्षमता थप्छ, जसलाई भनिन्छ MetricsQL। यो विस्तारित कार्यक्षमता बारे YouTube मा कुराकानी छ। मैले सेन्ट पिटर्सबर्गको वसन्तमा मनिटरिङ मिटअपमा बोलेको थिएँ।

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

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

प्रोमिथियसको लागि तपाईंको दीर्घकालीन भण्डारणको रूपमा VictoriaMetrics मा स्विच गर्न तपाईंलाई कुन कुराले रोकेको छ? (टिप्पणीमा लेख्नुहोस्, म यसलाई मतदानमा थप्नेछु))

• 71,4%म Prometheus5 प्रयोग गर्दिन

• 28,6%VictoriaMetrics2 को बारेमा थाहा थिएन

7 प्रयोगकर्ताहरूले मतदान गरे। 12 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com