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

हम देखेंगे कि कैसे Zabbix एक बैकेंड के रूप में TimescaleDB डेटाबेस के साथ काम करता है। हम दिखाते हैं कि स्क्रैच से कैसे शुरू करें और PostgreSQL के साथ माइग्रेट कैसे करें। हम दो कॉन्फ़िगरेशन का तुलनात्मक प्रदर्शन परीक्षण भी देते हैं।



हाईलाड ++ साइबेरिया 2019. टॉम्स्क हॉल। 24 जून, 16:00। सार और प्रस्तुति । अगला हाईलाड ++ सम्मेलन 6 और 7 अप्रैल, 2020 को सेंट पीटर्सबर्ग में आयोजित किया जाएगा। विवरण और टिकट यहां ।

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

मुख्य प्रदर्शन चुनौतियां: डेटा अधिग्रहण से

शुरू करने के लिए, कुछ प्रदर्शन चुनौतियां हैं जो हर निगरानी प्रणाली का सामना करती हैं। पहली प्रदर्शन चुनौती डेटा का त्वरित संग्रह और प्रसंस्करण है।



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



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



तीसरी प्रदर्शन चुनौती इतिहास को साफ कर रही है, अर्थात, जब आपका दिन ऐसा होता है, तो आपको किसी भी विस्तृत मैट्रिक्स को संग्रहीत करने की आवश्यकता नहीं होती है जिसे 5 साल (यहां तक ​​कि महीने या दो महीने) में एकत्र किया गया हो। कुछ नेटवर्क नोड्स को हटा दिया गया है, या कुछ होस्ट, मेट्रिक्स की आवश्यकता नहीं है क्योंकि वे पहले से ही पुराने हैं और अब एकत्र नहीं किए गए हैं। यह सब साफ करने की आवश्यकता है ताकि आपका डेटाबेस बड़े आकार में न बढ़े। सामान्य तौर पर, इतिहास को साफ़ करना अक्सर भंडारण के लिए एक गंभीर परीक्षा है - बहुत बार यह प्रदर्शन को प्रभावित करता है।

कैशिंग समस्याओं को कैसे हल करें?

मैं अब ज़ैबिक्स के बारे में विशेष रूप से बोलूंगा। ज़ैबिक्स में, कैशिंग का उपयोग करके पहली और दूसरी कॉल का समाधान किया जाता है।



डेटा संग्रह और प्रसंस्करण - हम रैम का उपयोग इस सभी डेटा को संग्रहीत करने के लिए करते हैं। अब इस डेटा पर अधिक विस्तार से चर्चा की जाएगी।

साथ ही डेटाबेस की ओर से मुख्य नमूने के लिए एक निश्चित कैशिंग है - रेखांकन, अन्य चीजों के लिए।

Zabbix सर्वर के किनारे पर ही कैशिंग: हमारे पास कॉन्फ़िगरेशनकैश, वैल्यू कैश, हिस्ट्रीकैच, ट्रेंडसैच है। यह क्या है



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

ज़ाबिक्स में कैशिंग। डेटा संग्रह

यहाँ यह योजना काफी बड़ी है:



इस योजना में मुख्य हैं ये संग्राहक:



ये स्वयं विधानसभा प्रक्रियाएं हैं, विभिन्न "पोलर्स" जो विभिन्न प्रकार की विधानसभाओं के लिए जिम्मेदार हैं। वे अलग-अलग प्रोटोकॉल के अनुसार icmp, ipmi के माध्यम से डेटा एकत्र करते हैं और सभी को प्रीप्रोसेसिंग में स्थानांतरित करते हैं।

Preprocessing HistoryCache

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



प्रीप्रोसेसिंग, पूर्वप्रक्रमक चरणों को प्राप्त करने के लिए कॉन्फ़िगरेशनकैश का उपयोग करता है; यह इस डेटा को विभिन्न तरीकों से संसाधित करता है। संस्करण 4.2 के साथ शुरू, हमने इसे प्रॉक्सी को सबमिट किया है। यह बहुत सुविधाजनक है, क्योंकि प्रीप्रोसेसिंग स्वयं एक कठिन ऑपरेशन है। और यदि आपके पास बहुत बड़ी "ज़ैबिक्स" है, जिसमें बड़ी संख्या में डेटा तत्व और संग्रह की उच्च आवृत्ति है, तो यह काम को बहुत सुविधाजनक बनाता है।

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

इतिहास पर्यायवाची ऑपरेशन

ज़ैबिक्स में मुख्य प्रक्रिया (चूंकि यह एक अखंड वास्तुकला है) इतिहास पर्यायवाची है। यह मुख्य प्रक्रिया है जो विशेष रूप से प्रत्येक डेटा तत्व के परमाणु प्रसंस्करण से संबंधित है, अर्थात प्रत्येक मूल्य:

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

डेटाबेस। कैशिंग

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

MySQL के लिए, Innodb_buffer_pool है, विभिन्न कैश का एक गुच्छा है जिसे कॉन्फ़िगर भी किया जा सकता है।
लेकिन ये मुख्य हैं:

• shared_buffers;
• effective_cache_size;
• shared_pool।

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

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

तदनुसार, एक प्रतिस्पर्धी माहौल है, अर्थात, ज़ैबिक्स सर्वर डेटा एकत्र करता है और उन्हें रिकॉर्ड करता है। रीस्टार्ट होने पर, यह वैल्यूकैच वगैरह को पॉप्युलेट करने के लिए हिस्ट्री से भी पढ़ता है। यहां आपके पास ज़ैबिक्स-एपीआई का उपयोग करने वाली स्क्रिप्ट और रिपोर्ट हो सकती हैं, जो वेब इंटरफ़ेस के आधार पर बनाई गई हैं। "Zabbiks" -API डेटाबेस में शामिल है और ग्राफ़, रिपोर्ट या घटनाओं की कुछ सूची, हाल की समस्याओं को प्राप्त करने के लिए आवश्यक डेटा प्राप्त करता है।



इसके अलावा एक बहुत लोकप्रिय विज़ुअलाइज़ेशन समाधान ग्राफाना है, जिसका उपयोग हमारे उपयोगकर्ताओं द्वारा किया जाता है। "Zabbiks" -API, और डेटाबेस के माध्यम से सीधे दोनों में प्रवेश करने में सक्षम। यह डेटा प्राप्त करने के लिए एक निश्चित प्रतियोगिता भी बनाता है: परिणाम और परीक्षण के तेजी से वितरण के अनुरूप करने के लिए एक बेहतर, डेटाबेस की बेहतर ट्यूनिंग की आवश्यकता होती है।

साफ इतिहास। ज़ाबिक्स में हाउसकीपर है

ज़ाबिक्स द्वारा इस्तेमाल की जाने वाली तीसरी चुनौती हाउसकीपर के साथ कहानी को साफ़ करना है। होसकाइपर सभी सेटिंग्स का अनुपालन करता है, अर्थात्, हमारे डेटा तत्वों में यह इंगित किया जाता है कि स्टोर करने के लिए कितना (दिनों में), रुझानों को कितना स्टोर करना है, परिवर्तनों की गतिशीलता।

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

कैसे समझें कि यह अक्षम है? आप आंतरिक प्रक्रियाओं के प्रदर्शन रेखांकन पर निम्नलिखित चित्र देख सकते हैं:



आपका इतिहास सार लगातार व्यस्त (लाल ग्राफ) है। और "लाल" चार्ट जो शीर्ष पर जाता है। यह हॉसकिपर है, जो शुरू होता है और डेटाबेस के लिए इंतजार करता है जब यह निर्दिष्ट सभी लाइनों को हटा देता है।

कुछ आइटम आईडी लें: आपको अंतिम 5 हजार हटाने की आवश्यकता है; बेशक, सूचकांकों द्वारा। लेकिन आमतौर पर डाटासेट काफी बड़ा होता है - डेटाबेस अभी भी डिस्क से इसे पढ़ता है और इसे कैश में बढ़ाता है, और यह डेटाबेस के लिए एक बहुत महंगा ऑपरेशन है। इसके आकार के आधार पर, यह कुछ प्रदर्शन समस्याओं को जन्म दे सकता है।

आप हॉसकिपर को एक सरल तरीके से अक्षम कर सकते हैं - हमारे पास सभी के लिए एक परिचित वेब इंटरफ़ेस है। सामान्य प्रशासन ("हाउसकीपर" के लिए सेटिंग) में हम आंतरिक इतिहास और प्रवृत्तियों के लिए आंतरिक हाउसकीपिंग को अक्षम करते हैं। तदनुसार, हॉसकिपर अब इसे नियंत्रित नहीं करता है:



मैं आगे क्या कर सकता हूं? आपने डिस्कनेक्ट कर दिया, आपके शेड्यूल लेवल हो गए ... इस मामले में आगे क्या समस्याएं हो सकती हैं? क्या मदद कर सकता है?

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

यह आमतौर पर हर रिलेशनल डेटाबेस पर कॉन्फ़िगर किया जाता है जिसे मैंने एक अलग तरीके से सूचीबद्ध किया है। MySQL की अपनी तकनीक है। लेकिन कुल मिलाकर वे बहुत समान हैं जब यह PostgreSQL 10 और MySQL की बात आती है। बेशक, इसको लागू करने के तरीके में बहुत सारे आंतरिक अंतर हैं और यह सभी प्रदर्शन को कैसे प्रभावित करता है। लेकिन सामान्य तौर पर, एक नए विभाजन का निर्माण अक्सर कुछ समस्याओं को भी जन्म देता है।



आपके सेटअप (आप एक दिन में कितना डेटा बनाते हैं) के आधार पर, वे आम तौर पर न्यूनतम एक - 1 दिन / विभाजन सेट करते हैं, और रुझानों के लिए, परिवर्तनों की गतिशीलता - 1 महीने / नया विभाजन। यदि आपके पास बहुत बड़ा सेटअप है तो यह बदल सकता है।

सेटअप के आकार के बारे में तुरंत बताएं: प्रति सेकंड 5 हजार नए मान (तथाकथित nvps) - यह एक छोटा "सेटअप" माना जाएगा। औसत - प्रति सेकंड 5 से 25 हजार मान। ऊपर जो कुछ भी है वह पहले से ही बहुत बड़ा और बहुत बड़ा इंस्टॉलेशन है जिसे डेटाबेस के बहुत सावधान कॉन्फ़िगरेशन की आवश्यकता है।

बहुत बड़े प्रतिष्ठानों पर, 1 दिन - यह इष्टतम नहीं हो सकता है। मैंने व्यक्तिगत रूप से प्रति दिन 40 गीगाबाइट के MySQL विभाजन पर देखा (और अधिक भी हो सकता है)। यह बहुत बड़ी मात्रा में डेटा है, जिससे कुछ समस्याएं हो सकती हैं। इसे कम करने की जरूरत है।

विभाजन क्यों?

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



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



कई डेटाबेस इंसर्ट (एकल बाल तालिका में सम्मिलन) में भी तेजी लाते हैं। जबकि मैं सारगर्भित बोलता हूं, लेकिन यह संभव भी है। विभाजन अक्सर मदद करता है।

NoSQL के लिए एलिटिक्स खोज

हाल ही में, 3.4 में, हमने NoSQL के लिए एक समाधान लागू किया। एलिस्टिक्स खोज में लिखने की क्षमता को जोड़ा। आप कुछ अलग प्रकार लिख सकते हैं: चुनें - या तो संख्या या कुछ संकेत लिखें; हमारे पास स्ट्रिंग टेक्स्ट है, आप एलिस्टिक्सखोज में लॉग लिख सकते हैं ... तदनुसार, वेब इंटरफेस भी एलीस्टेसर्च को एक्सेस करेगा। यह कुछ मामलों में ठीक काम करता है, लेकिन फिलहाल इसका इस्तेमाल किया जा सकता है।

TimescaleDB। Gipertablitsy

4.4.2 के लिए, हमने TimescaleDB जैसी एक चीज़ पर ध्यान दिया। यह क्या है यह Postgres के लिए एक विस्तार है, अर्थात, इसमें एक मूल PostgreSQL इंटरफ़ेस है। साथ ही, यह एक्सटेंशन आपको समय के डेटा के साथ अधिक कुशलता से काम करने और स्वचालित विभाजन करने की अनुमति देता है। यह कैसा दिखता है:



यह हाइपरटेबल है - Timescale में ऐसी अवधारणा है। यह हाइपरटेबल है जो आप बनाते हैं, और इसमें विखंडू होते हैं। विखंडू विभाजन हैं, ये बाल टेबल हैं, अगर मुझसे गलती नहीं है। यह वास्तव में प्रभावी है।

TimescaleDB और PostgreSQL

जैसा कि TimescaleDB के निर्माता आश्वासन देते हैं, वे विशेष रूप से Insert'ov में अधिक सही अनुरोध प्रसंस्करण एल्गोरिथ्म का उपयोग करते हैं, जो आपको डेटासेट के बढ़ते आकार के साथ लगभग निरंतर प्रदर्शन करने की अनुमति देता है। "पोस्टग्रेज" की 200 मिलियन लाइनों के बाद, सामान्य रूप से बहुत ज्यादा गाया जाने लगता है और प्रदर्शन को शाब्दिक रूप से शून्य तक खो देता है, जबकि "Timescale" आपको किसी भी राशि के डेटा के साथ यथासंभव कुशलता से सम्मिलित करने की अनुमति देता है।

TimescaleDB कैसे स्थापित करें? सब कुछ सरल है!

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



Zabbix में, हम सिर्फ एक्सटेंशन सक्रिय करते हैं। मुझे लगता है कि जिन्होंने Postgres में Extention का उपयोग किया है ... आप बस Extention सक्रिय करते हैं, इसे Zabbix डेटाबेस के लिए बनाएं जो आप उपयोग करते हैं।

और अंतिम चरण ...

TimescaleDB। माइग्रेशन हिस्ट्री टेबल

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



वह फ़ील्ड जिसके द्वारा आप बनाना चाहते हैं, और chunk_time_interval (यह चंक्स का अंतराल है (उपयोग किए जाने वाले विभाजन)। 86,400 एक दिन है।

पैरामीटर माइग्रेट_डेटा: यदि आप सही में सम्मिलित करते हैं, तो यह सभी मौजूदा डेटा को पूर्व में बनाए गए चंक्स में स्थानांतरित करता है।

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

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

सर्वर कॉन्फ़िगरेशन

मैंने दो सर्वरों का उपयोग किया। पहला सर्वर एक वर्चुअल मशीन है, जिसमें 20 प्रोसेसर, 16 गीगाबाइट रैम है। इस पर 10.8 पोस्टग्रैज सेट करें:



ऑपरेटिंग सिस्टम डेबियन था, फ़ाइल सिस्टम xfs था। मैंने इस विशेष डेटाबेस का उपयोग करने के लिए न्यूनतम सेटिंग की, शून्य से ज़ैबिक्स का क्या उपयोग होगा। एक ही मशीन पर एक Zabbix सर्वर, PostgreSQL और लोड एजेंट थे।



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



मैंने अपडेट अंतराल को नियंत्रित किया, खुद को लोड किया ताकि मैंने न केवल 50 एजेंटों (अधिक जोड़ा) का उपयोग किया, बल्कि गतिशील डेटा तत्वों की मदद से और अद्यतन अंतराल को 4 सेकंड तक कम कर दिया।

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

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



ऐसे और भी कई चार्ट होंगे। यह ज़ैबिक्स सर्वर का मानक प्रदर्शन डैशबोर्ड है।



पहला ग्राफ इस मामले में प्रति सेकंड (नीला, शीर्ष बाएं) मानों की संख्या, 35 हजार मान है। यह (लोडिंग सेंटर) विधानसभा प्रक्रियाओं का लोडिंग है, और यह (ऊपरी दाएं) आंतरिक प्रक्रियाओं को लोड कर रहा है: इतिहास सिंकर्स और हाउसकीपर, जो पर्याप्त समय से यहां चल रहा है।

यह ग्राफ़ (निचला केंद्र) ValueCache का उपयोग दिखाता है - ट्रिगर के लिए कितने ValueCache हिट (प्रति सेकंड कई हजार मान)। एक और महत्वपूर्ण ग्राफ चौथा (नीचे बाएं) है, जो हिस्ट्रीचैच के उपयोग को दर्शाता है, जिसके बारे में मैंने बात की थी, जो डेटाबेस में डालने से पहले एक बफर है।

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

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



हौसेपाइपर पहले से ही काम में हस्तक्षेप करना शुरू कर रहा है, लेकिन इतिहास-सिंकर ट्रैपर्स की समग्र लोडिंग अभी भी 60% (तीसरा चार्ट, शीर्ष दाएं) है। हिस्ट्रीकैच पहले से ही "हॉसकिपर" के काम के दौरान सक्रिय रूप से भरना शुरू कर देता है (नीचे बाएं)। यह लगभग आधा गीगाबाइट था, 20% से भर गया।

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

आगे बढ़कर प्रति सेकंड 80 हजार मान बढ़े:



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



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



मैंने एक और सर्वर लिया जिसमें पहले से ही 128 गीगाबाइट रैम के साथ 48 प्रोसेसर थे:



इसके अलावा, मैंने इसे "धूमिल कर दिया" - मैंने इतिहास सार (60 टुकड़े) स्थापित किया और स्वीकार्य प्रदर्शन हासिल किया। वास्तव में, हम "शेल्फ में" नहीं हैं, लेकिन यह संभवतः उत्पादकता की सीमा है, जहां इसके बारे में कुछ करना पहले से ही आवश्यक है।

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

मेरा मुख्य कार्य TimescaleDB का उपयोग करना था। प्रत्येक चार्ट पर विफलता दिखाई देती है:



ये डिप्स सिर्फ डेटा माइग्रेशन हैं। उसके बाद, "ज़ैबिक्स" सर्वर में, इतिहास-सिंकर्स की लोडिंग प्रोफाइल, जैसा कि आप देखते हैं, बहुत कुछ बदल गया है।यह लगभग 3 गुना तेज है जो आपको डेटा डालने और कम हिस्ट्रीशीट का उपयोग करने की अनुमति देता है - तदनुसार, आपको समय पर डेटा प्राप्त होगा। फिर, प्रति सेकंड 80 हजार मान एक उच्च दर है (निश्चित रूप से, यैंडेक्स के लिए नहीं)। सामान्य तौर पर, यह एक सर्वर के साथ एक काफी बड़ा सेटअप है।

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

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



और मुझे ये ग्राफ़ मिल गए:



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

विभाजन आमतौर पर रात में बनाए जाते हैं, क्योंकि यह तालिकाओं के सामान्य सम्मिलन और संचालन को अवरुद्ध करता है, और सेवा का ह्रास हो सकता है। इस मामले में, यह नहीं है! मुख्य कार्य TimescaleDB की क्षमताओं का परीक्षण करना था। परिणाम एक ऐसा आंकड़ा था: प्रति सेकंड 120 हजार मान।

समुदाय में भी उदाहरण हैं:



आदमी भी TimescaleDB पर बदल गया और io.weight का उपयोग करने पर लोड प्रोसेसर पर गिर गया; और आंतरिक प्रक्रिया तत्वों के उपयोग ने भी TimescaleDB को शामिल करने के लिए धन्यवाद को अस्वीकार कर दिया है। और ये साधारण पैनकेक डिस्क हैं, यानी साधारण डिस्क (एसएसडी नहीं) पर एक साधारण वर्चुअल मशीन है!

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

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

दर्शकों के सवाल

दर्शकों से सवाल (इसके बाद - ए): - अगर TimescaleDB को कॉन्फ़िगर करना बहुत आसान है, और यह इस तरह के प्रदर्शन को बढ़ावा देता है, तो शायद इसे पोस्टग्रेज के साथ ज़ैबिक्स की स्थापना के लिए सबसे अच्छा अभ्यास के रूप में इस्तेमाल किया जाना चाहिए? और क्या इस निर्णय के कुछ नुकसान और नुकसान हैं, या फिर भी, अगर मैंने ज़ैबिक्स खुद बनाने का फैसला किया है, तो मैं सुरक्षित रूप से पोस्टग्रैज ले जा सकता हूं, Timescale को तुरंत वहां डाल सकता हूं, इसका उपयोग कर सकता हूं और किसी भी समस्या के बारे में नहीं सोचूंगा ?



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

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

और:- नवीनतम ग्राफ़ पर, जो समुदाय से हैं, "हाउसकीपर" के साथ एक ग्राफ था:



यह काम करना जारी रखता था। TimescaleDB के साथ Hauskiper क्या करता है?

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

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

"Timescale" बस समझता है कि अब ऐसा कोई हिस्सा नहीं है। और चूंकि यह क्वेरी प्लानर में एकीकृत होता है, इसलिए यह चुनिंदा या अन्य परिचालनों में हुक पर आपकी शर्तों को पकड़ता है और तुरंत समझ जाता है कि यह हिस्सा नहीं है - "मैं अब वहां नहीं जा सकता!" (डेटा उपलब्ध नहीं है)। वह सब है! यही है, बाइनरी फ़ाइल को हटाने के द्वारा टेबल स्कैन को बदल दिया जाता है, इसलिए यह तेज़ है।

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

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

ए: - सामान्य तौर पर, यह पता चला है कि आप पूरी तरह से पोस्टग्रेज से छुटकारा पा सकते हैं?

एजी:- बेशक, ज़ाबिक्स में सबसे कठिन हिस्सा ऐतिहासिक तालिकाओं है, जो सबसे अधिक समस्याएं और घटनाएं पैदा करते हैं। इस मामले में, यदि आप लंबे समय तक घटनाओं को स्टोर नहीं करते हैं और इतिहास को कुछ अन्य फास्ट स्टोरेज में रुझानों के साथ रखते हैं, तो सामान्य तौर पर कोई समस्या नहीं होगी, मुझे लगता है।

A: - क्या आप आकलन कर सकते हैं कि उदाहरण के लिए, यदि आप Clickhouse में जाते हैं तो सब कुछ कितनी तेजी से काम करेगा?

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

और:- यही है, हम एक समान लड़ाई के बारे में बात कर रहे हैं, और इन तेज़ डेटाबेस के महान लाभ के बारे में नहीं?

एजी: - मुझे लगता है कि जब हम एकीकृत करते हैं, तो अधिक सटीक परीक्षण होंगे।

A: - अच्छे पुराने RRD कहाँ गए? आपने SQL डेटाबेस में क्या परिवर्तन किया? प्रारंभ में, आरआरडी पर, सभी मैट्रिक्स एकत्र किए गए थे।

एजी: - "ज़ैबिक्स" आरआरडी में, शायद यह बहुत प्राचीन संस्करण में था। हमेशा SQL डेटाबेस - एक क्लासिक दृष्टिकोण रहा है। क्लासिक दृष्टिकोण MySQL, PostgreSQL (वे पहले से ही लंबे समय तक मौजूद हैं)। हमारे पास SQL ​​और RRD डेटाबेस के लिए एक सामान्य इंटरफ़ेस है, हमने लगभग कभी उपयोग नहीं किया।

विज्ञापन का एक सा :)

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

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?