हाईलोड++, एंड्री गुशचिन (ज़ैबिक्स): उच्च प्रदर्शन और मूल विभाजन

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

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

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

शीर्ष उत्पादकता चुनौतियाँ: डेटा संग्रह से लेकर डेटा सफ़ाई तक

आरंभ करने के लिए, कुछ निश्चित प्रदर्शन चुनौतियाँ हैं जिनका प्रत्येक निगरानी प्रणाली को सामना करना पड़ता है। पहली उत्पादकता चुनौती डेटा को शीघ्रता से एकत्र करना और संसाधित करना है।

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

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

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

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

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

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

इसके अलावा डेटाबेस पक्ष में मुख्य चयनों के लिए कुछ कैशिंग है - ग्राफ़ और अन्य चीज़ों के लिए।

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

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

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

यहाँ आरेख काफी बड़ा है:

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

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

प्रीप्रोसेसिंग हिस्ट्री कैश

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

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

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

हिस्ट्री सिंकर का काम

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

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

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

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

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

• साझा_बफ़र्स;
• प्रभावी_कैश_आकार;
• साझा पूल।

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

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

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

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

इतिहास साफ़ करना. ज़ैबिक्स के पास हाउसकीपर है

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

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

कैसे समझें कि यह अप्रभावी है? आप आंतरिक प्रक्रियाओं के प्रदर्शन ग्राफ़ पर निम्नलिखित चित्र देख सकते हैं:

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

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

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

आप आगे क्या कर सकते हैं? आपने इसे बंद कर दिया, आपका ग्राफ़ समतल हो गया है... इस मामले में और क्या समस्याएँ उत्पन्न हो सकती हैं? क्या मदद कर सकता है?

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

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

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

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

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

आपको विभाजन की आवश्यकता क्यों है?

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

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

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

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

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

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

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

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

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

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

टाइमस्केलडीबी कैसे स्थापित करें? यह आसान है!

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

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

और आखिरी कदम...

टाइमस्केलडीबी। इतिहास तालिकाओं का स्थानांतरण

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

वह क्षेत्र जिसके द्वारा बनाना है, और खंड_समय_अंतराल (यह खंडों का अंतराल है (विभाजन जिन्हें उपयोग करने की आवश्यकता है)। 86 एक दिन है।

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

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

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

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

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

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

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

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

प्रदर्शन का परीक्षण। पोस्टग्रेएसक्यूएल: 36 हजार एनवीपी

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

भविष्य में ऐसे बहुत सारे ग्राफ़ होंगे। यह एक मानक ज़ैबिक्स सर्वर प्रदर्शन डैशबोर्ड है।

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

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

प्रदर्शन का परीक्षण। पोस्टग्रेएसक्यूएल: 50 हजार एनवीपी

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

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

प्रदर्शन का परीक्षण। पोस्टग्रेएसक्यूएल: 80 हजार एनवीपी

फिर मैंने इसे बढ़ाकर 80 हजार मान प्रति सेकंड कर दिया:

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

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

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

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

प्रदर्शन का परीक्षण। टाइमस्केलडीबी: 80 हजार एनवीपी

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

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

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

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

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

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

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

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

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

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

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

दर्शकों के प्रश्न

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

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

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

और: - समुदाय के अंतिम ग्राफ़ पर, "हाउसकीपर" के साथ एक ग्राफ़ था:

उन्होंने काम करना जारी रखा. हाउसकीपर TimescaleDB के साथ क्या करता है?

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

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

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

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

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

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

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

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

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

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

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

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

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

कुछ विज्ञापन 🙂

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

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

स्रोत: www.habr.com