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

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

हाईलोड++ साइबेरिया २०१९। टम्स्क हल। जुन २४, १६:००। सारांश र प्रस्तुति। अर्को HighLoad++ सम्मेलन अप्रिल ६-७, २०२० मा सेन्ट पिटर्सबर्गमा आयोजना हुनेछ। विवरण र टिकटहरू लिङ्क.

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

प्रमुख कार्यसम्पादन चुनौतीहरू: डेटा सङ्कलनदेखि डेटा सफाईसम्म

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

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

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

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

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

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

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

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

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

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

जाब्बिक्समा क्यासिङ। तथ्याङ्क सङ्कलन

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

योजनाका मुख्यहरू यी एसेम्बलरहरू हुन्:

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

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

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

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

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

इतिहास सिङ्कर कार्य

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

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

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

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

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

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

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

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

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

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

इतिहास सफा गर्दै। Zabbix मा हाउसकीपर छ

Zabbix मा प्रयोग हुने तेस्रो कल भनेको Housekeeper प्रयोग गरेर इतिहास खाली गर्नु हो। Housekeeper ले सबै सेटिङहरूको सम्मान गर्छ, अर्थात्, हामीसँग डेटा तत्वहरूमा कति भण्डारण गर्ने (दिनहरूमा), कति प्रवृत्तिहरू भण्डारण गर्ने, परिवर्तनहरूको गतिशीलता छ।

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

यो अप्रभावी छ भनेर तपाईंलाई कसरी थाहा हुन्छ? तपाईंले आन्तरिक प्रक्रिया कार्यसम्पादन चार्टहरूमा यो तस्वीर देख्न सक्नुहुन्छ:

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

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

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

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

विभाजन (सेक्शनिङ)

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

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

म तपाईंलाई सेटअप आकारहरूको बारेमा तुरुन्तै बताउँछु: प्रति सेकेन्ड ५ हजार नयाँ मानहरू (तथाकथित NVPS) - यसलाई सानो "सेटअप" मानिनेछ। औसत - प्रति सेकेन्ड ५ देखि २५ हजार मानहरू। त्यो भन्दा माथिको कुनै पनि कुरा पहिले नै ठूलो र धेरै ठूला स्थापनाहरू हुन् जसलाई डाटाबेसको धेरै सावधानीपूर्वक कन्फिगरेसन आवश्यक पर्दछ।

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

हामीलाई विभाजन किन चाहिन्छ?

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

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

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

NoSQL को लागि इलास्टिकसर्च

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

टाइमस्केलडीबी। हाइपरटेबलहरू

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

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

टाइमस्केलडीबी र पोस्टग्रेएसक्यूएल

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

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

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

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

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

टाइमस्केलडीबी। इतिहास तालिकाहरू स्थानान्तरण गर्दै

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

र chunk_time_interval द्वारा सिर्जना गर्नुपर्ने क्षेत्र (यो प्रयोग गर्नुपर्ने chunks (partitions) को अन्तराल हो)। ८६,४०० एक दिन हो।

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

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

अनि हामीले हाम्रो db_extention मा गर्ने अन्तिम अपडेट: हामी timescaledb स्थापना गर्छौं ताकि DB र विशेष गरी, हाम्रो "Zabbix" ले db_extention छ भनेर बुझोस्। यसले यसलाई सक्रिय गर्छ र TimescaledDB को लागि आवश्यक ती "सुविधाहरू" प्रयोग गरेर DB मा सही वाक्य रचना र प्रश्नहरू प्रयोग गर्छ।

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

मैले दुई सर्भर प्रयोग गरें। पहिलो सर्भर भर्चुअल मेसिन हो, एकदम सानो, २० प्रोसेसरहरू, १६ गिगाबाइट RAM। मैले यसमा Postgres १०.८ कन्फिगर गरें:

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

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

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

कार्यसम्पादन परीक्षण। PostgreSQL: ३६K NVP हरू

पहिलो सुरुवात, मैले गरेको पहिलो सेटअप यस हार्डवेयरमा सफा PostreSQL १० मा थियो (प्रति सेकेन्ड ३५ हजार मानहरू)। सामान्यतया, तपाईंले स्क्रिनमा देख्न सक्नुहुन्छ, डेटा सम्मिलनले एक सेकेन्डको अंश लिन्छ - सबै कुरा राम्रो र छिटो छ, SSD डिस्कहरू (२०० गीगाबाइटहरू)। एउटै कुरा यो हो कि २० GB धेरै छिटो भरिन्छ।

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

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

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

कार्यसम्पादन परीक्षण। PostgreSQL: ३६K NVP हरू

त्यसपछि मैले त्यही हार्डवेयरमा लोड बढाएर प्रति सेकेन्ड ५० हजार मान पुर्‍याएँ। "हाउसकीपर" बाट लोड गर्दा, गणना सहित २-३ सेकेन्डमा १० हजार मान लेखिन्थ्यो। जुन वास्तवमा निम्न स्क्रिनसटमा देखाइएको छ:

"हाउसकीपर" ले पहिले नै काममा हस्तक्षेप गर्न थालेको छ, तर सामान्यतया इतिहास सिङ्कर ट्र्यापरहरूको भार अझै पनि ६०% मा छ (तेस्रो ग्राफ, माथि दायाँ)। "हाउसकीपर" (तल बायाँ) को कामको क्रममा हिस्ट्रीक्यास पहिले नै सक्रिय रूपमा भरिन थाल्छ। यो लगभग आधा गिगाबाइट थियो, २०% ले भरिएको।

कार्यसम्पादन परीक्षण। PostgreSQL: ३६K NVP हरू

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

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

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

मैले अर्को सर्भर लिएँ जसमा पहिले नै ४८ प्रोसेसर र १२८ गिगाबाइट र्‍याम थियो:

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

कार्यसम्पादन परीक्षण। टाइमस्केलDB: ८० हजार NVP हरू

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

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

PostgreSQL प्रदर्शन परीक्षण: १२०K NVP हरू

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

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

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

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

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

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

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

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

दर्शकका प्रश्नहरू

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

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

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

A: – समुदायको पछिल्लो चार्टमा, “हाउसकीपर” भएको चार्ट थियो:

ऊ काम गरिरह्यो। हाउसकिपरले टाइमस्केलडीबीसँग के गर्छ?

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

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

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

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

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

A: – सामान्यतया, यो थाहा हुन्छ कि पोस्टग्रेसबाट पूर्ण रूपमा छुटकारा पाउन सम्भव छ?

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

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

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

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

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

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

एजी: – “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