HighLoad++, Andrey Gushchin (Zabbix): उच्च प्रदर्शन र नेटिभ विभाजन

हामी Zabbix ले ब्याकइन्डको रूपमा TimescaleDB डाटाबेससँग कसरी काम गर्छ भनेर हेर्नेछौं। हामी तपाईंलाई कसरी स्क्र्याचबाट सुरु गर्ने र PostgreSQL बाट कसरी माइग्रेट गर्ने भनेर देखाउनेछौं। हामी दुई कन्फिगरेसनहरूको तुलनात्मक प्रदर्शन परीक्षणहरू पनि प्रदान गर्नेछौं।

हाईलोड++ साइबेरिया २०१९। टमस्क हल। जुन 2019, 24:16। थेसिस र प्रस्तुति। अर्को HighLoad++ सम्मेलन अप्रिल 6 र 7, 2020 मा सेन्ट पिटर्सबर्गमा हुनेछ। विवरण र टिकटहरू लिङ्क.

एन्ड्री गुश्चिन (यसपछि - एजी): - म एक ZABBIX प्राविधिक समर्थन इन्जिनियर हुँ (यसपछि "Zabbix" भनिन्छ), एक प्रशिक्षक। म 6 वर्ष भन्दा बढीको लागि प्राविधिक सहयोगमा काम गरिरहेको छु र प्रदर्शन संग प्रत्यक्ष अनुभव भएको छ। आज म नियमित PostgreSQL 10 सँग तुलना गर्दा TimescaleDB ले प्रदान गर्न सक्ने कार्यसम्पादनको बारेमा कुरा गर्नेछु। साथै, यसले सामान्यमा कसरी काम गर्छ भन्ने बारे केही परिचयात्मक अंश।

शीर्ष उत्पादकता चुनौतिहरू: डाटा सङ्कलनदेखि डाटा सफा गर्न

सुरुमा, त्यहाँ केहि प्रदर्शन चुनौतीहरू छन् जुन प्रत्येक अनुगमन प्रणालीले सामना गर्दछ। पहिलो उत्पादकता चुनौती भनेको छिट्टै डाटा सङ्कलन र प्रशोधन गर्नु हो।

राम्रो निगरानी प्रणालीले चाँडै, समयमै सबै डाटा प्राप्त गर्नुपर्दछ, ट्रिगर अभिव्यक्ति अनुसार यसलाई प्रशोधन गर्नुपर्दछ, अर्थात्, यसलाई केही मापदण्डहरू अनुसार प्रशोधन गर्नुपर्दछ (यो फरक प्रणालीहरूमा फरक छ) र डाटाबेसमा बचत गर्नुपर्दछ। भविष्य।

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

तेस्रो कार्यसम्पादन चुनौती इतिहास क्लियरिङ हो, त्यो हो, जब तपाइँ बिन्दुमा पुग्नुहुन्छ जहाँ तपाइँ 5 वर्ष (महिना वा दुई महिना पनि) मा सङ्कलन गरिएको कुनै पनि विस्तृत मेट्रिक्स भण्डारण गर्न आवश्यक छैन। केही नेटवर्क नोडहरू मेटाइयो, वा केही होस्टहरू, मेट्रिकहरू अब आवश्यक पर्दैन किनभने तिनीहरू पहिले नै पुरानो भइसकेका छन् र अब सङ्कलन हुँदैनन्। यो सबै सफा गर्न आवश्यक छ ताकि तपाईको डाटाबेस धेरै ठूलो नहोस्। सामान्यतया, इतिहास खाली गर्नु प्रायः भण्डारणको लागि गम्भीर परीक्षण हो - यसले अक्सर प्रदर्शनमा धेरै बलियो प्रभाव पार्छ।

क्यासिंग समस्याहरू कसरी समाधान गर्ने?

अब म Zabbix को बारेमा विशेष कुरा गर्नेछु। Zabbix मा, पहिलो र दोस्रो कलहरू क्यासिङ प्रयोग गरेर समाधान गरिन्छ।

डाटा सङ्कलन र प्रशोधन - हामी यी सबै डाटा भण्डारण गर्न RAM प्रयोग गर्छौं। यी डाटा अब थप विस्तारमा छलफल गरिनेछ।

डाटाबेस साइडमा पनि मुख्य छनोटहरूको लागि केही क्यासिङ छ - ग्राफ र अन्य चीजहरूको लागि।

Zabbix सर्भरको छेउमा क्यास गर्दै: हामीसँग कन्फिगरेसन क्याच, ValueCache, HistoryCache, TrendsCache छ। यो के हो?

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

Zabbix मा क्यास गर्दै। तथ्यांक संकलन

यहाँ रेखाचित्र एकदम ठूलो छ:

योजनामा ​​मुख्य यी कलेक्टरहरू हुन्:

यी आफैंमा विधानसभा प्रक्रियाहरू हुन्, विभिन्न प्रकारका विधानसभाहरूको लागि जिम्मेवार विभिन्न "पोलरहरू"। तिनीहरूले icmp, ipmi, र विभिन्न प्रोटोकलहरू मार्फत डेटा सङ्कलन गर्छन् र सबैलाई प्रिप्रोसेसिङमा स्थानान्तरण गर्छन्।

पूर्व प्रशोधन इतिहास क्याच

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

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

तदनुसार, हामीले यो डाटालाई कुनै न कुनै तरिकाले प्रिप्रोसेसिङ प्रयोग गरेर प्रशोधन गरिसकेपछि, हामी यसलाई थप प्रशोधन गर्नको लागि HistoryCache मा बचत गर्छौं। यो तथ्याङ्क सङ्कलन निष्कर्षमा पुग्छ। हामी मुख्य प्रक्रियामा जान्छौं।

इतिहास सिंकको काम

Zabbix मा मुख्य प्रक्रिया (यो एक मोनोलिथिक वास्तुकला भएको कारण) इतिहास समक्रमण हो। यो मुख्य प्रक्रिया हो जुन विशेष गरी प्रत्येक डेटा तत्वको परमाणु प्रशोधनसँग सम्बन्धित छ, त्यो हो, प्रत्येक मान:

• मान आउँछ (यसले HistoryCache बाट लिन्छ);
• कन्फिगरेसन सिङ्करमा जाँच गर्दछ: गणनाको लागि कुनै ट्रिगरहरू छन् कि छैनन् - तिनीहरूलाई गणना गर्दछ;
  यदि त्यहाँ छ भने - घटनाहरू सिर्जना गर्दछ, चेतावनी सिर्जना गर्नको लागि एस्केलेसन सिर्जना गर्दछ, यदि आवश्यक भएमा कन्फिगरेसन अनुसार;
• पछिको प्रशोधन, एकत्रीकरणको लागि रेकर्ड ट्रिगरहरू; यदि तपाईंले पछिल्लो घण्टा र यस्तै अन्यमा जम्मा गर्नुभयो भने, यो मान ValueCache द्वारा सम्झिन्छ ताकि इतिहास तालिकामा नजानुहोस्; यसरी, ValueCache आवश्यक डाटाले भरिएको छ जुन ट्रिगरहरू, गणना गरिएका तत्वहरू, आदि गणना गर्न आवश्यक छ।
• त्यसपछि इतिहास सिङ्करले डाटाबेसमा सबै डाटा लेख्छ;
• डाटाबेसले तिनीहरूलाई डिस्कमा लेख्छ - यो जहाँ प्रशोधन प्रक्रिया समाप्त हुन्छ।

डाटाबेस। क्यासिङ

डाटाबेस पक्षमा, जब तपाइँ ग्राफहरू वा घटनाहरूमा केही रिपोर्टहरू हेर्न चाहनुहुन्छ, त्यहाँ विभिन्न क्यासहरू छन्। तर यस रिपोर्टमा म तिनीहरूको बारेमा कुरा गर्दिन।

MySQL को लागि त्यहाँ Innodb_buffer_pool छ, र विभिन्न क्यासहरूको गुच्छा पनि कन्फिगर गर्न सकिन्छ।
तर यी मुख्य हुन्:

• साझा_बफरहरू;
• प्रभावकारी_cache_size;
• साझा_पूल।

सबै डाटाबेसहरूको लागि, मैले भने कि त्यहाँ केहि क्यासहरू छन् जसले तपाईंलाई RAM मा भण्डारण गर्न अनुमति दिन्छ जुन प्रायः क्वेरीहरूको लागि आवश्यक हुन्छ। यसका लागि तिनीहरूसँग आफ्नै प्रविधिहरू छन्।

डाटाबेस प्रदर्शन को बारे मा

तदनुसार, त्यहाँ प्रतिस्पर्धात्मक वातावरण छ, त्यो हो, Zabbix सर्भरले डाटा सङ्कलन गर्दछ र यसलाई रेकर्ड गर्दछ। पुन: सुरु गर्दा, यसले ValueCache भर्नको लागि इतिहासबाट पनि पढ्छ र यस्तै। यहाँ तपाईंसँग Zabbix API प्रयोग गर्ने स्क्रिप्ट र रिपोर्टहरू हुन सक्छन्, जुन वेब इन्टरफेसमा बनाइएको छ। Zabbix API डाटाबेसमा प्रवेश गर्छ र ग्राफ, रिपोर्ट, वा घटनाहरूको कुनै प्रकारको सूची, हालका समस्याहरू प्राप्त गर्न आवश्यक डाटा प्राप्त गर्दछ।

साथै एक धेरै लोकप्रिय दृश्य समाधान Grafana हो, जुन हाम्रा प्रयोगकर्ताहरूले प्रयोग गर्छन्। Zabbix API मार्फत र डाटाबेस मार्फत सीधा लग इन गर्न सक्षम। यसले डाटा प्राप्त गर्नको लागि एक निश्चित प्रतिस्पर्धा पनि सिर्जना गर्दछ: परिणाम र परीक्षणको द्रुत डेलिभरीको पालना गर्न डाटाबेसको राम्रो, राम्रो ट्युनिंग आवश्यक छ।

इतिहास खाली गर्दै। Zabbix सँग हाउसकीपर छ

Zabbix मा प्रयोग गरिएको तेस्रो कल हाउसकीपर प्रयोग गरेर इतिहास सफा गर्दैछ। हाउसकीपरले सबै सेटिङहरू पछ्याउँछ, त्यो हो, हाम्रो डेटा तत्वहरूले कति लामो समय (दिनहरूमा), प्रचलनहरू कति लामो भण्डारण गर्ने, र परिवर्तनहरूको गतिशीलता संकेत गर्दछ।

मैले TrendCache को बारेमा कुरा गरिन, जुन हामी उडानमा गणना गर्छौं: डाटा आउँछ, हामी यसलाई एक घण्टाको लागि जम्मा गर्छौं (अधिकतर यी अन्तिम घण्टाका लागि संख्याहरू हुन्), रकम औसत/न्यूनतम छ र हामी यसलाई एक घण्टामा एक पटक रेकर्ड गर्छौं। परिवर्तनहरूको गतिशीलताको तालिका ("प्रवृत्ति")। "हाउसकीपर" ले डाटाबेसबाट नियमित चयनहरू प्रयोग गरेर डाटा सुरु गर्छ र मेटाउँछ, जुन सधैं प्रभावकारी हुँदैन।

यो अप्रभावी छ भनेर कसरी बुझ्न? तपाइँ आन्तरिक प्रक्रियाहरूको प्रदर्शन ग्राफमा निम्न चित्र देख्न सक्नुहुन्छ:

तपाईंको इतिहास सिङ्कर लगातार व्यस्त छ (रातो ग्राफ)। र "रातो" ग्राफ जुन माथि जान्छ। यो "हाउसकीपर" हो जुन सुरु हुन्छ र डाटाबेसले निर्दिष्ट गरेको सबै पङ्क्तिहरू मेटाउनको लागि पर्खन्छ।

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

तपाईले साधारण तरिकामा हाउसकीपरलाई असक्षम गर्न सक्नुहुन्छ - हामीसँग परिचित वेब इन्टरफेस छ। प्रशासन सामान्यमा सेटिङहरू ("हाउसकीपर" को लागि सेटिङहरू) हामी आन्तरिक इतिहास र प्रवृत्तिहरूको लागि आन्तरिक हाउसकीपिङ असक्षम पार्छौं। तदनुसार, हाउसकीपरले अब यसलाई नियन्त्रण गर्दैन:

तपाईं अब के गर्न सक्नुहुन्छ? तपाईंले यसलाई बन्द गर्नुभयो, तपाईंको ग्राफहरू समतल भएका छन्... यस अवस्थामा थप समस्याहरू के हुन सक्छ? के मद्दत गर्न सक्छ?

विभाजन (विभाजन)

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

तपाइँको सेटअपमा निर्भर गर्दछ (तपाईले एक दिनमा कति डेटा सिर्जना गर्नुहुन्छ), तिनीहरूले सामान्यतया न्यूनतम सेट गर्छन् - यो 1 दिन / ब्याच हो, र "प्रवृत्ति" को लागी, परिवर्तनहरूको गतिशीलता - 1 महिना / नयाँ ब्याच। यदि तपाईंसँग धेरै ठूलो सेटअप छ भने यो परिवर्तन हुन सक्छ।

सेटअपको साइजको बारेमा तुरुन्तै भनौं: प्रति सेकेन्डमा 5 हजार नयाँ मानहरू (तथाकथित nvps) - यसलाई सानो "सेटअप" मानिनेछ। औसत - प्रति सेकेन्ड 5 देखि 25 हजार मानहरू। माथिका सबै पहिले नै ठूला र धेरै ठूला स्थापनाहरू छन् जुन डाटाबेसको धेरै सावधान कन्फिगरेसन चाहिन्छ।

धेरै ठूला स्थापनाहरूमा, 1 दिन इष्टतम नहुन सक्छ। मैले व्यक्तिगत रूपमा MySQL मा 40 गिगाबाइट प्रति दिन विभाजनहरू देखेको छु (र त्यहाँ धेरै हुन सक्छ)। यो डाटाको धेरै ठूलो मात्रा हो, जसले केही समस्याहरू निम्त्याउन सक्छ। यसलाई कम गर्न आवश्यक छ।

तपाईलाई विभाजन किन चाहिन्छ?

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

Zabbix को लागि, विशेष गरी, यो दायरा द्वारा, दायरा द्वारा प्रयोग गरिन्छ, त्यो हो, हामी एक टाइमस्ट्याम्प प्रयोग गर्दछौं (नियमित संख्या, समय को शुरुवात देखि समय)। तपाईंले दिनको सुरु/दिनको अन्त्य निर्दिष्ट गर्नुहुन्छ, र यो विभाजन हो। तदनुसार, यदि तपाइँ डाटाको लागि सोध्दै हुनुहुन्छ जुन दुई दिन पुरानो छ, सबै कुरा डाटाबेसबाट छिटो पुन: प्राप्त हुन्छ, किनकि तपाइँले क्यासमा केवल एउटा फाइल लोड गर्न र फिर्ता गर्न आवश्यक छ (ठूलो तालिकाको सट्टा)।

धेरै डाटाबेसले पनि इन्सर्ट (एउटा चाइल्ड टेबलमा घुसाउने) गति बढाउँछ। म अहिलेको लागि अमूर्त रूपमा बोल्दै छु, तर यो पनि सम्भव छ। विभाजनले अक्सर मद्दत गर्दछ।

NoSQL को लागि इलास्टिक खोज

भर्खरै, 3.4 मा, हामीले NoSQL समाधान लागू गर्यौं। Elasticsearch मा लेख्ने क्षमता थपियो। तपाइँ निश्चित प्रकारहरू लेख्न सक्नुहुन्छ: तपाइँ छनौट गर्नुहुन्छ - या त नम्बरहरू वा केही चिन्हहरू लेख्नुहोस्; हामीसँग स्ट्रिङ पाठ छ, तपाईं Elasticsearch मा लगहरू लेख्न सक्नुहुन्छ... तदनुसार, वेब इन्टरफेसले Elasticsearch मा पनि पहुँच गर्नेछ। यसले केहि अवस्थामा राम्रो काम गर्दछ, तर अहिले यो प्रयोग गर्न सकिन्छ।

TimescaleDB। हाइपरटेबलहरू

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

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

TimescaleDB र PostgreSQL

TimescaleDB निर्माताहरूले आश्वस्त गरेझैं, तिनीहरूले सोधपुछहरू प्रशोधन गर्नको लागि थप सही एल्गोरिदम प्रयोग गर्छन्, विशेष इन्सर्टहरूमा, जसले तिनीहरूलाई डेटासेट इन्सर्टको बढ्दो साइजको साथ लगभग स्थिर कार्यसम्पादन गर्न अनुमति दिन्छ। त्यो हो, Postgres को 200 मिलियन पङ्क्तिहरू पछि, सामान्य एक धेरै ढिलो हुन थाल्छ र शाब्दिक रूपमा शून्यमा प्रदर्शन गुमाउँछ, जबकि टाइमस्केलले तपाईंलाई डेटाको कुनै पनि मात्रामा सकेसम्म प्रभावकारी रूपमा सम्मिलित गर्न अनुमति दिन्छ।

TimescaleDB कसरी स्थापना गर्ने? यो सरल छ!

यो कागजातमा छ, यो वर्णन गरिएको छ - तपाइँ यसलाई कुनै पनि प्याकेजहरूबाट स्थापना गर्न सक्नुहुन्छ ... यो आधिकारिक पोस्टग्रेस प्याकेजहरूमा निर्भर गर्दछ। म्यानुअल रूपमा कम्पाइल गर्न सकिन्छ। यो यस्तो भयो कि मैले डाटाबेसको लागि कम्पाइल गर्नुपर्‍यो।

Zabbix मा हामी केवल विस्तार सक्रिय गर्छौं। मलाई लाग्छ कि पोस्टग्रेसमा एक्सटेन्सन प्रयोग गर्नेहरूले... तपाईले एक्स्टेन्सनलाई सक्रिय गर्नुहोस्, तपाईले प्रयोग गरिरहनु भएको Zabbix डाटाबेसको लागि सिर्जना गर्नुहोस्।

र अन्तिम चरण ...

TimescaleDB। इतिहास तालिकाहरूको माइग्रेसन

तपाईंले हाइपरटेबल सिर्जना गर्न आवश्यक छ। यसको लागि एक विशेष प्रकार्य छ - हाइपरटेबल सिर्जना गर्नुहोस्। यसमा, पहिलो प्यारामिटर तालिका हो जुन यस डाटाबेसमा आवश्यक छ (जसको लागि तपाईंले हाइपरटेबल सिर्जना गर्न आवश्यक छ)।

सिर्जना गर्ने क्षेत्र, र chunk_time_interval (यो खण्डहरूको अन्तराल हो (प्रयोग गर्न आवश्यक विभाजनहरू)। 86 एक दिन हो।

माइग्रेट_डेटा प्यारामिटर: यदि तपाईंले true मा घुसाउनु भयो भने, यसले सबै हालको डाटालाई पूर्व-सिर्जित खण्डहरूमा स्थानान्तरण गर्नेछ।

मैले माइग्रेट_डेटा आफैं प्रयोग गरेको छु - तपाईंको डाटाबेस कति ठूलो छ भन्ने आधारमा यसले उचित समय लिन्छ। मसँग एक टेराबाइट थियो - यसलाई सिर्जना गर्न एक घण्टा भन्दा बढी लाग्यो। केहि अवस्थाहरूमा, परीक्षणको क्रममा, मैले पाठ (history_text) र string (history_str) को लागि ऐतिहासिक डेटा मेटाएको छु ताकि तिनीहरूलाई स्थानान्तरण नहोस् - तिनीहरू मेरो लागि साँच्चै रोचक थिएनन्।

र हामी हाम्रो db_extention मा अन्तिम अपडेट गर्छौं: हामी टाइमस्केलेडब स्थापना गर्छौं ताकि डेटाबेस र विशेष गरी, हाम्रो Zabbix ले बुझ्छ कि त्यहाँ db_extention छ। उसले यसलाई सक्रिय गर्दछ र डाटाबेसमा सही वाक्यविन्यास र प्रश्नहरू प्रयोग गर्दछ, ती "सुविधाहरू" प्रयोग गरेर जुन TimescaleDB को लागि आवश्यक छ।

सर्भर कन्फिगरेसन

मैले दुईवटा सर्भर प्रयोग गरें। पहिलो सर्भर एकदम सानो भर्चुअल मेसिन, 20 प्रोसेसर, 16 गीगाबाइट RAM छ। मैले यसमा Postgres 10.8 कन्फिगर गरें:

अपरेटिङ सिस्टम डेबियन थियो, फाइल सिस्टम xfs थियो। मैले यो विशेष डाटाबेस प्रयोग गर्नको लागि न्यूनतम सेटिङहरू बनाएको छु, Zabbix ले प्रयोग गर्ने कुरा माइनस। एउटै मेसिनमा Zabbix सर्भर, PostgreSQL र लोड एजेन्टहरू थिए।

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

मैले ५० एजेन्टहरू प्रयोग गरेर (थप थपेर) मात्र होइन, तर गतिशील डेटा तत्वहरू प्रयोग गरेर र अद्यावधिक अन्तराललाई ४ सेकेन्डमा घटाएर अद्यावधिक अन्तराल र लोड आफैंलाई विनियमित गरें।

प्रदर्शन परीक्षण। PostgreSQL: 36 हजार NVPs

पहिलो सुरुवात, मैले गरेको पहिलो सेटअप यस हार्डवेयरमा शुद्ध PostreSQL 10 मा थियो (35 हजार मान प्रति सेकेन्ड)। सामान्यतया, तपाईले स्क्रिनमा देख्न सक्नुहुन्छ, डेटा सम्मिलित गर्न सेकेन्डको अंश लाग्छ - सबै कुरा राम्रो र छिटो छ, SSD ड्राइभहरू (200 गीगाबाइट)। मात्र कुरा यो हो कि 20 GB चाँडै भरिन्छ।

भविष्यमा यस्ता ग्राफहरू धेरै हुनेछन्। यो एक मानक Zabbix सर्भर प्रदर्शन ड्यासबोर्ड हो।

पहिलो ग्राफ प्रति सेकेन्ड मानहरूको संख्या हो (नीलो, शीर्ष बायाँ), यस अवस्थामा 35 हजार मानहरू। यो (शीर्ष केन्द्र) निर्माण प्रक्रियाहरूको लोडिङ हो, र यो (शीर्ष दायाँ) आन्तरिक प्रक्रियाहरूको लोडिङ हो: इतिहास सिङ्कर र हाउसकीपर, जुन यहाँ (तल केन्द्र) धेरै समयदेखि चलिरहेको छ।

यो ग्राफ (तल केन्द्र) ले ValueCache प्रयोग देखाउँछ - ट्रिगरहरूको लागि कति ValueCache हिट हुन्छ (प्रति सेकेन्ड धेरै हजार मानहरू)। अर्को महत्त्वपूर्ण ग्राफ चौथो हो (तल बायाँ), जसले HistoryCache को प्रयोग देखाउँदछ, जुन मैले कुरा गरेको छु, जुन डाटाबेसमा सम्मिलित गर्नु अघि बफर हो।

प्रदर्शन परीक्षण। PostgreSQL: 50 हजार NVPs

अर्को, मैले समान हार्डवेयरमा प्रति सेकेन्ड 50 हजार मानहरूमा लोड बढाएँ। हाउसकीपरले लोड गर्दा, गणनाको साथ 10-2 सेकेन्डमा 3 हजार मानहरू रेकर्ड गरियो। के, वास्तवमा, निम्न स्क्रिनसटमा देखाइएको छ:

"हाउसकीपर" ले पहिले नै काममा हस्तक्षेप गर्न थालेको छ, तर सामान्यतया, इतिहास-सिङ्कर ट्र्यापरहरूमा लोड अझै पनि 60% (तेस्रो ग्राफ, शीर्ष दायाँ) को स्तरमा छ। HistoryCache पहिले नै सक्रिय रूपमा भर्न थाल्छ जब हाउसकीपर चलिरहेको छ (तल बायाँ)। यो लगभग आधा गीगाबाइट थियो, 20% भरिएको।

प्रदर्शन परीक्षण। PostgreSQL: 80 हजार NVPs

त्यसपछि मैले यसलाई प्रति सेकेन्ड 80 हजार मानहरूमा बढाएँ:

यो लगभग 400 हजार डाटा तत्व, 280 हजार ट्रिगर थियो। घुसाउनुहोस्, तपाईले देख्न सक्नुहुन्छ, इतिहास डूबनेहरूको भारको सन्दर्भमा (त्यहाँ 30 जना थिए) पहिले नै धेरै उच्च थियो। त्यसपछि मैले विभिन्न प्यारामिटरहरू बढाएँ: हिस्ट्री सिङ्करहरू, क्यास... यस हार्डवेयरमा, हिस्ट्री सिङ्करहरूमा लोड अधिकतममा बढ्न थाल्यो, लगभग "शेल्फमा" - तदनुसार, HistoryCache धेरै उच्च लोडमा गयो:

यो सबै समय मैले सबै प्रणाली प्यारामिटरहरू (कसरी प्रोसेसर प्रयोग गरिन्छ, RAM) अनुगमन गरें र पत्ता लगाए कि डिस्क उपयोगिता अधिकतम थियो - मैले यो हार्डवेयरमा, यो भर्चुअल मेसिनमा यो डिस्कको अधिकतम क्षमता हासिल गरें। "Postgres" ले यस्तो तीव्रतामा धेरै सक्रिय रूपमा डाटा डम्प गर्न थाल्यो, र डिस्कसँग अब लेख्न, पढ्नको लागि समय थिएन ...

मैले अर्को सर्भर लिएँ जुन पहिले नै 48 प्रोसेसर र 128 गीगाबाइट RAM थियो:

मैले यसलाई "ट्यून" पनि गरें - इतिहास सिङ्कर (60 टुक्राहरू) स्थापना गरे र स्वीकार्य प्रदर्शन हासिल गरे। वास्तवमा, हामी "शेल्फमा" छैनौं, तर यो सम्भवतः उत्पादकताको सीमा हो, जहाँ यो पहिले नै यसको बारेमा केहि गर्न आवश्यक छ।

प्रदर्शन परीक्षण। TimescaleDB: 80 हजार NVPs

मेरो मुख्य कार्य TimescaleDB प्रयोग गर्नु थियो। प्रत्येक ग्राफले डिप देखाउँछ:

यी विफलताहरू ठ्याक्कै डाटा माइग्रेसन हुन्। त्यस पछि, Zabbix सर्भरमा, इतिहास सिंकहरूको लोडिङ प्रोफाइल, तपाईले देख्न सक्नुहुन्छ, धेरै परिवर्तन भयो। यसले तपाइँलाई लगभग 3 गुणा छिटो डाटा घुसाउन र कम HistoryCache प्रयोग गर्न अनुमति दिन्छ - तदनुसार, तपाइँसँग डाटा समयमै डेलिभर हुनेछ। फेरि, प्रति सेकेन्ड 80 हजार मानहरू एकदम उच्च दर हो (निस्सन्देह, यान्डेक्सको लागि होइन)। समग्रमा यो एक सर्भरको साथ, एकदम ठूलो सेटअप हो।

PostgreSQL प्रदर्शन परीक्षण: 120 हजार NVPs

अर्को, मैले डेटा तत्वहरूको संख्याको मूल्य आधा मिलियनमा बढाएँ र प्रति सेकेन्ड 125 हजारको गणना मूल्य प्राप्त गरें:

र मैले यी ग्राफहरू पाएँ:

सिद्धान्तमा, यो काम गर्ने सेटअप हो, यसले लामो समयसम्म काम गर्न सक्छ। तर मसँग 1,5 टेराबाइट डिस्क मात्र भएकोले, मैले यसलाई केही दिनमा प्रयोग गरें। सबैभन्दा महत्त्वपूर्ण कुरा यो हो कि एकै समयमा TimescaleDB मा नयाँ विभाजनहरू सिर्जना गरिएको थियो, र यो कार्यसम्पादनको लागि पूर्ण रूपमा ध्यान नदिइएको थियो, जुन MySQL को बारेमा भन्न सकिँदैन।

सामान्यतया, विभाजनहरू रातमा सिर्जना गरिन्छ, किनभने यसले सामान्यतया सम्मिलित गर्न रोक्छ र तालिकाहरूसँग काम गर्दछ र सेवाको गिरावट निम्त्याउन सक्छ। यस मामला मा यो मामला छैन! मुख्य कार्य TimescaleDB को क्षमताहरू परीक्षण गर्न थियो। परिणाम निम्न आंकडा थियो: प्रति सेकेन्ड 120 हजार मान।

समुदायमा पनि उदाहरणहरू छन्:

व्यक्तिले TimescaleDB पनि अन गर्यो र प्रोसेसरमा io.weight प्रयोग गर्ने लोड घट्यो; र TimescaleDB को समावेशका कारण आन्तरिक प्रक्रिया तत्वहरूको प्रयोग पनि घटेको छ। यसबाहेक, यी साधारण प्यानकेक डिस्कहरू हुन्, त्यो हो, साधारण डिस्कहरूमा एक साधारण भर्चुअल मेसिन (SSDs होइन)!

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

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

श्रोताका प्रश्नहरू

दर्शकहरूबाट प्रश्न (यसपछि - A): - यदि TimescaleDB कन्फिगर गर्न धेरै सजिलो छ, र यसले यस्तो प्रदर्शन बढावा दिन्छ, तब सायद यो पोस्टग्रेसको साथ Zabbix कन्फिगर गर्नको लागि उत्तम अभ्यासको रूपमा प्रयोग गर्नुपर्छ? र के त्यहाँ यस समाधानको कुनै समस्या र बेफाइदाहरू छन्, वा यदि मैले आफ्नो लागि Zabbix बनाउने निर्णय गरें भने, म सजिलैसँग Postgres लिन सक्छु, त्यहाँ तुरुन्तै टाइमस्केल स्थापना गर्न सक्छु, यसलाई प्रयोग गर्न सक्छु र कुनै पनि समस्याहरूको बारेमा सोच्न सक्दिन?

AG: - हो, म भन्छु कि यो राम्रो सिफारिस हो: TimescaleDB विस्तारको साथ तुरुन्तै Postgres प्रयोग गर्नुहोस्। मैले पहिले नै भनेझैं, यो "सुविधा" प्रयोगात्मक छ भन्ने तथ्यको बावजुद धेरै राम्रो समीक्षाहरू। तर वास्तवमा परीक्षणहरूले देखाउँदछ कि यो एक उत्कृष्ट समाधान हो (TimescaleDB सँग) र मलाई लाग्छ कि यो विकसित हुनेछ! हामी यो विस्तार कसरी विकसित हुन्छ भनेर निगरानी गरिरहेका छौं र आवश्यक अनुसार परिवर्तनहरू गर्नेछौं।

विकासको समयमा पनि, हामीले तिनीहरूको एक प्रसिद्ध "विशेषताहरू" मा भर परेका थियौं: टुक्राहरूसँग थोरै फरक रूपमा काम गर्न सम्भव थियो। तर त्यसपछि तिनीहरूले यसलाई अर्को रिलीजमा काटिदिए, र हामीले यो कोडमा भर पर्न छोड्नुपर्‍यो। म धेरै सेटअपहरूमा यो समाधान प्रयोग गर्न सिफारिस गर्दछु। यदि तपाइँ MySQL प्रयोग गर्नुहुन्छ... औसत सेटअपहरूको लागि, कुनै पनि समाधानले राम्रोसँग काम गर्दछ।

A: - समुदायबाट अन्तिम ग्राफहरूमा, "घरका कामदार" भएको ग्राफ थियो:

उनले काम जारी राखे । हाउसकीपरले TimescaleDB सँग के गर्छ?

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

A: - मसँग समान प्रश्न छ - टाइमस्केलमा मेटाउने कार्यको प्रदर्शनको बारेमा।
A (दर्शकहरूबाट जवाफ): - जब तपाइँ तालिकाबाट डेटा मेटाउनुहुन्छ, यदि तपाइँ यसलाई मेटाउने मार्फत गर्नुहुन्छ भने, तपाइँ तालिका मार्फत जानु पर्छ - मेटाउनुहोस्, सफा गर्नुहोस्, भविष्यको भ्याकुमको लागि सबै कुरा चिन्ह लगाउनुहोस्। टाइमस्केलमा, तपाईंसँग टुक्रा भएकोले, तपाईं छोड्न सक्नुहुन्छ। सामान्य रूपमा भन्नुपर्दा, तपाईले ठूलो डेटामा रहेको फाइललाई मात्र भन्नुहुन्छ: "मेट्नुहोस्!"

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

A: - हामीले पहिले नै गैर-SQL को विषयमा छोएका छौं। जहाँसम्म मैले बुझेको छु, Zabbix ले डाटा परिमार्जन गर्न आवश्यक छैन, र यो सबै लग जस्तै हो। के यो विशेष डाटाबेसहरू प्रयोग गर्न सम्भव छ जसले तिनीहरूको डाटा परिवर्तन गर्न सक्दैन, तर एकै समयमा बचत, सङ्कलन, र धेरै छिटो वितरण गर्दछ - क्लिकहाउस, उदाहरणका लागि, काफ्का जस्तो केहि?... काफ्का पनि एक लग हो! के यो कुनै पनि तरिका तिनीहरूलाई एकीकृत गर्न सम्भव छ?

AG: - अनलोड गर्न सकिन्छ। हामीसँग संस्करण 3.4 देखि एक निश्चित "सुविधा" छ: तपाइँ सबै ऐतिहासिक फाइलहरू, घटनाहरू, फाइलहरूमा सबै कुरा लेख्न सक्नुहुन्छ; र त्यसपछि केहि ह्यान्डलर प्रयोग गरेर कुनै अन्य डेटाबेसमा पठाउनुहोस्। वास्तवमा, धेरै व्यक्तिहरू पुन: काम गर्छन् र सीधा डाटाबेसमा लेख्छन्। फ्लाईमा, इतिहास सिंकहरूले यी सबै फाइलहरूमा लेख्छन्, यी फाइलहरू घुमाउँछन्, र यस्तै, र तपाईंले यसलाई क्लिकहाउसमा स्थानान्तरण गर्न सक्नुहुन्छ। म योजनाहरूको बारेमा भन्न सक्दिन, तर सायद NoSQL समाधानहरूको लागि थप समर्थन (जस्तै क्लिकहाउस) जारी रहनेछ।

A: - सामान्यतया, यो बाहिर जान्छ कि तपाईं पोस्टग्रेसबाट पूर्ण रूपमा छुटकारा पाउन सक्नुहुन्छ?

AG: - निस्सन्देह, Zabbix मा सबै भन्दा कठिन भाग ऐतिहासिक तालिका हो, जसले धेरै समस्याहरू र घटनाहरू सिर्जना गर्दछ। यस अवस्थामा, यदि तपाइँ घटनाहरू लामो समयको लागि भण्डारण गर्नुहुन्न र इतिहासलाई केहि अन्य द्रुत भण्डारणमा प्रचलनहरूसँग भण्डारण गर्नुहुन्छ भने, सामान्यतया, मलाई लाग्छ, त्यहाँ कुनै समस्या हुनेछैन।

A: - यदि तपाईंले क्लिकहाउसमा स्विच गर्नुभयो भने, उदाहरणका लागि सबै कुरा कति छिटो काम गर्छ भन्ने अनुमान गर्न सक्नुहुन्छ?

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

A: - त्यसोभए हामी समान लडाईको बारेमा कुरा गर्दैछौं, र यी द्रुत डाटाबेसहरूको ठूलो फाइदाको बारेमा होइन?

AG: - मलाई लाग्छ जब हामी एकीकृत गर्छौं, त्यहाँ थप सटीक परीक्षणहरू हुनेछन्।

A: - राम्रा पुराना आरआरडी कहाँ गए? तपाइँलाई SQL डाटाबेसमा स्विच गर्न के गर्यो? सुरुमा, सबै मेट्रिक्स RRD मा सङ्कलन गरिएको थियो।

AG: - Zabbix सँग RRD थियो, सायद धेरै पुरानो संस्करणमा। त्यहाँ सधैं SQL डाटाबेस भएको छ - एक क्लासिक दृष्टिकोण। क्लासिक दृष्टिकोण MySQL, PostgreSQL (तिनीहरू धेरै लामो समयको लागि अवस्थित छन्) हो। हामीले SQL र RRD डाटाबेसहरूको लागि साझा इन्टरफेस लगभग कहिल्यै प्रयोग गरेनौं।

केही विज्ञापनहरू 🙂

हामीसँग रहनु भएकोमा धन्यवाद। तपाईलाई हाम्रा लेखहरू मनपर्छ? थप रोचक सामग्री हेर्न चाहनुहुन्छ? हामीलाई अर्डर गरेर वा साथीहरूलाई सिफारिस गरेर समर्थन गर्नुहोस्, $4.99 बाट विकासकर्ताहरूको लागि क्लाउड VPS, प्रविष्टि-स्तर सर्भरहरूको एक अद्वितीय एनालग, जुन हामीले तपाईंको लागि आविष्कार गरेको हो: VPS (KVM) E5-2697 v3 (6 कोर) 10GB DDR4 480GB SSD 1Gbps $ 19 बाट वा कसरी सर्भर साझा गर्ने बारे सम्पूर्ण सत्य? (RAID1 र RAID10 सँग उपलब्ध, 24 कोर सम्म र 40GB DDR4 सम्म)।

डेल R730xd 2x एम्स्टर्डमको इक्विनिक्स टियर IV डाटा सेन्टरमा सस्तो छ? यहाँ मात्र 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 बाट नेदरल्याण्ड मा! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 बाट! बारे पढ्नुहोस् पूर्वाधार कर्पोरेशन कसरी निर्माण गर्ने। डेल R730xd E5-2650 v4 सर्भरहरूको प्रयोगको साथ एक पैसाको लागि 9000 यूरो मूल्यको वर्ग?

स्रोत: www.habr.com