Zabbix, टाइम सीरीज़ और TimescaleDB

प्रत्येक मॉनिटरिंग सिस्टम को तीन प्रकार की प्रदर्शन समस्याओं का सामना करना पड़ता है।

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



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

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

पहले दो समस्याओं को कैशिंग द्वारा हल किया जाता है। Zabbix डेटा पढ़ने और लिखने के कार्यों को गति देने के लिए कई विशिष्ट कैश का समर्थन करता है। DBMS तंत्र स्वयं यहाँ उपयुक्त नहीं हैं, क्योंकि यहां तक ​​कि सबसे उन्नत सामान्य-उद्देश्य कैशिंग एल्गोरिथ्म को नहीं पता होगा कि किस डेटा संरचना को किसी दिए गए बिंदु पर तत्काल पहुंच की आवश्यकता होती है।

निगरानी और समय श्रृंखला डेटा

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

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

सारांश यह है कि निगरानी प्रणाली तीन दिशाओं में प्रदर्शन की समस्याओं को हल करती है - नया डेटा एकत्र करना और इसे SQL INSERT प्रश्नों का उपयोग करके डेटाबेस में लिखना, SELECT क्वेरीज़ का उपयोग करके डेटा तक पहुँचना, और DELETE का उपयोग करके डेटा हटाना। आइए देखें कि एक विशिष्ट SQL क्वेरी कैसे निष्पादित की जाती है:

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

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

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

समय श्रृंखला एक अस्थायी क्रम में अनुक्रमित (या सूचीबद्ध या भित्तिचित्र) डेटा बिंदुओं की एक श्रृंखला है।

डेटाबेस बिंदु से, समय श्रृंखला में निम्नलिखित गुण हैं:

• समय-क्रम ब्लॉक के अनुक्रम के रूप में समय श्रृंखला एक डिस्क पर स्थित हो सकती है।
• समय श्रृंखला तालिकाओं को एक समय स्तंभ का उपयोग करके अनुक्रमित किया जा सकता है।
• अधिकांश SQL सेलेक्ट क्वेश्चंस टाइम-सिग्नलिंग कॉलम पर WHERE, GROUP BY या ORDER BY क्लॉस का उपयोग करेंगे।
• आमतौर पर, टाइम सीरीज़ के डेटा की एक "समाप्ति तिथि" होती है जिसके बाद इसे हटाया जा सकता है।

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

क्या Zabbix किसी भी तरह से इन DBMS का उपयोग कर सकता है? संभावित दृष्टिकोणों में से एक समय श्रृंखला में विशेष बाहरी डेटाबेस में भंडारण के लिए ऐतिहासिक डेटा को स्थानांतरित करना है। यह देखते हुए कि ज़ैबिक्स आर्किटेक्चर ऐतिहासिक डेटा संग्रहीत करने के लिए बाहरी बैकएंड का समर्थन करता है (उदाहरण के लिए, ज़ैबिक्स में इलास्टिक्स खोज समर्थन लागू किया गया है), पहली नज़र में यह विकल्प बहुत उचित लगता है। लेकिन अगर हमने बाह्य सर्वर के रूप में समय श्रृंखला के लिए एक या कई DBMS का समर्थन किया है, तो उपयोगकर्ताओं को निम्नलिखित बिंदुओं पर विचार करना होगा:

• एक और प्रणाली जिसे तलाशने, कॉन्फ़िगर करने और बनाए रखने की आवश्यकता है। सेटिंग्स, डिस्क स्थान, भंडारण नीतियों, प्रदर्शन, आदि का ट्रैक रखने के लिए एक और जगह।
• निगरानी प्रणाली के दोष सहिष्णुता को कम करना, जैसा कि संबंधित घटकों की श्रृंखला में एक नया लिंक दिखाई देता है।

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

सवाल उठता है - क्या समय की श्रृंखला के लिए DBMS का लाभ उठाने का एक तरीका है, लेकिन SQL के लचीलेपन और फायदे को खोए बिना? स्वाभाविक रूप से, एक सार्वभौमिक उत्तर मौजूद नहीं है, लेकिन एक विशिष्ट समाधान उत्तर के बहुत करीब मिला - TimescaleDB ।

TimescaleDB क्या है?

TimescaleDB (TSDB) एक PostgreSQL एक्सटेंशन है जो एक नियमित PostgreSQL (PG) डेटाबेस में समय श्रृंखला के साथ काम का अनुकूलन करता है। हालांकि, जैसा कि ऊपर उल्लेख किया गया है, बाजार पर अच्छी तरह से मापनीय समय श्रृंखला समाधानों की कोई कमी नहीं है, TimescaleDB की एक अनूठी विशेषता पारंपरिक CRUD रिलेशनल डेटाबेस की संगतता और लाभों का त्याग किए बिना समय श्रृंखला के साथ अच्छी तरह से काम करने की क्षमता है। व्यवहार में, इसका मतलब है कि हम दोनों दुनियाओं में सर्वश्रेष्ठ हैं। डेटाबेस जानता है कि कौन सी तालिकाओं को समय श्रृंखला माना जाना चाहिए (और सभी आवश्यक अनुकूलन लागू करें), लेकिन आप उनके साथ उसी तरह काम कर सकते हैं जैसे कि नियमित तालिकाओं के साथ। इसके अलावा, अनुप्रयोगों को यह जानने के लिए आवश्यक नहीं है कि डेटा TSDB द्वारा नियंत्रित किया जाता है!

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



हाइपरटेबल इमेज timescaledb.com से
जब अनुप्रयोग समय श्रृंखला के लिए एक नया मान जोड़ता है, तो एक्सटेंशन इस मान को वांछित टुकड़े में निर्देशित करता है। यदि नए मान के समय के लिए सीमा निर्धारित नहीं है, तो TSDB एक नया टुकड़ा बनाएगा, इसे वांछित सीमा असाइन करें और वहां मान डालें। यदि कोई एप्लिकेशन हाइपरटेबल से डेटा का अनुरोध करता है, तो अनुरोध को निष्पादित करने से पहले, एक्सटेंशन जांचता है कि कौन से टुकड़े इस अनुरोध से जुड़े हैं।

लेकिन यह सब नहीं है। TSDB प्रदर्शन और स्केलेबिलिटी परिवर्तनों के एक मेजबान के साथ मजबूत और समय-परीक्षण किए गए पोस्टग्रेक्यूएल पारिस्थितिकी तंत्र का अनुपालन करता है। इनमें नए रिकॉर्ड्स का क्विक टाइम, क्विक टाइम क्वेश्चंस और वस्तुतः फ्री बैच डिलीट शामिल हैं।

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

TimescaleDB और PostgreSQL विभाजन

पहली नज़र में, ऐसा लग सकता है कि टीएसडीबी पीजी टेबल के मानक विभाजन ( घोषणात्मक विभाजन के आसपास एक अच्छा आवरण है, क्योंकि इसे आधिकारिक तौर पर पीजी 10 में कहा जाता है)। दरअसल, ऐतिहासिक डेटा को स्टोर करने के लिए, आप मानक विभाजन PG10 का उपयोग कर सकते हैं। लेकिन अगर आप करीब से देखें, तो TSDB और PG10 सेक्शन के टुकड़े समान अवधारणाओं से दूर हैं।

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

इसके बाद, आपको यह सोचने की ज़रूरत है कि समय सीमा समाप्त डेटा को कैसे हटाया जाए। TSDB में, आप बस drop_chunks () कमांड को कॉल कर सकते हैं, जो निश्चित समय के लिए हटाए जाने वाले टुकड़ों को निर्धारित करता है। पीजी 10 में, यदि आपको मानक पीजी अनुभागों से मूल्यों की एक निश्चित सीमा को हटाने की आवश्यकता है, तो आपको स्वयं इस सीमा के अनुभाग नामों की सूची की गणना करनी होगी। यदि चयनित विभाजन योजना में नेस्टेड अनुभाग शामिल हैं, तो यह विलोपन को जटिल करता है।

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

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

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

Zabbix और TimescaleDB

सभी विकल्पों में से, TimescaleDB Zabbix और इसके उपयोगकर्ताओं के लिए सबसे सुरक्षित विकल्प लगता है:

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

आइए देखें कि टीएसडीबी को नए सिरे से स्थापित ज़ैबिक्स के साथ शुरू करने के लिए क्या करने की आवश्यकता है। Zabbix स्थापित करने और PostgreSQL डेटाबेस निर्माण स्क्रिप्ट चलाने के बाद, आपको वांछित प्लेटफ़ॉर्म पर TSDB डाउनलोड और इंस्टॉल करना होगा। यहां इंस्टॉलेशन निर्देश देखें। एक्सटेंशन को स्थापित करने के बाद, आपको इसे ज़ैबिक्स बेस के लिए सक्षम करने की आवश्यकता है, और फिर ज़ैबिक्स के साथ आने वाली टाइमकेलेडब.सक्ल स्क्रिप्ट को चलाएं। यदि इंस्टॉलेशन स्रोत से है, या /usr/share/zabbix/database/timecaledb.sql.gz में है तो यह डेटाबेस / पोस्टग्रेजल / टाइमकैलडबी.एसक्यूएल में स्थित है। वह सब है! अब आप Zabbix सर्वर शुरू कर सकते हैं और यह TSDB के साथ काम करेगा।

Timescaledb.sql स्क्रिप्ट तुच्छ है। वह जो करता है वह नियमित ज़ैबिक्स ऐतिहासिक तालिकाओं को टीएसडीबी हाइपरटेबल्स में परिवर्तित करता है और डिफ़ॉल्ट सेटिंग्स को बदलता है - पैरामीटर को सेट करता है आइटम इतिहास अवधि और ओवरराइड आइटम प्रवृत्ति अवधि। अब (संस्करण 4.2) निम्नलिखित Zabbix टेबल TSDB नियंत्रण में काम करते हैं - इतिहास, history_uint, history_str, history_log, history_text, रुझान और रुझान_uint। इन तालिकाओं को स्थानांतरित करने के लिए एक ही स्क्रिप्ट का उपयोग किया जा सकता है (ध्यान दें कि migrate_data पैरामीटर सही पर सेट है)। यह ध्यान में रखना होगा कि डेटा माइग्रेशन एक बहुत लंबी प्रक्रिया है और इसमें कई घंटे लग सकते हैं।

Chunk_time_interval => 86400 पैरामीटर को timecaledb.sql चलाने से पहले परिवर्तनों की आवश्यकता हो सकती है। Chunk_time_interval अंतराल है जो इस टुकड़े में गिरने वाले मूल्यों के समय को सीमित करता है। उदाहरण के लिए, यदि आप chunk_time_interval अंतराल को 3 घंटे के लिए सेट करते हैं, तो पूरे दिन के डेटा को 8 टुकड़ों में वितरित किया जाएगा, जिसमें पहला खंड नंबर 1 पहले 3 घंटे (0: 00-2: 59) को कवर करेगा, दूसरा टुकड़ा नंबर 2 - दूसरा 3 घंटे ( 3: 00-5: 59), आदि। अंतिम खंड संख्या 8 में 21: 00-23: 59 के समय के मान शामिल होंगे। 86400 सेकंड (1 दिन) औसत डिफ़ॉल्ट मान है, लेकिन लोड सिस्टम के उपयोगकर्ता इसे कम करना चाह सकते हैं।

स्मृति आवश्यकताओं का मोटे तौर पर अनुमान लगाने के लिए, यह समझना महत्वपूर्ण है कि एक टुकड़ा औसतन कितना स्थान ले सकता है। सामान्य सिद्धांत यह है कि प्रत्येक हाइपरटेबल से कम से कम एक टुकड़े को व्यवस्थित करने के लिए सिस्टम में पर्याप्त मेमोरी होनी चाहिए। इस मामले में, निश्चित रूप से, टुकड़े के आकार का योग न केवल एक मार्जिन के साथ मेमोरी में फिट होना चाहिए, बल्कि postgresql.conf से शेयर्ड_बफर्स ​​पैरामीटर के मूल्य से भी कम होना चाहिए। इस विषय पर और जानकारी TimescaleDB प्रलेखन में पाई जा सकती है।

उदाहरण के लिए, यदि आपके पास एक प्रणाली है जो मुख्य रूप से पूर्णांक मैट्रिक्स को इकट्ठा करती है और आप हिस्ट्री_इंट टेबल को 2-घंटे के टुकड़ों में विभाजित करने का निर्णय लेते हैं, और शेष तालिकाओं को एक-दिवसीय टुकड़ों में विभाजित करते हैं, तो आपको इस पंक्ति को timecaledb.sql में बदलने की आवश्यकता है:

SELECT create_hypertable('history_uint', 'clock', chunk_time_interval => 7200, migrate_data => true); 

एक निश्चित मात्रा में ऐतिहासिक डेटा जमा हो जाने के बाद, आप chunk_relation_size (): कॉल करके इतिहास_इंट टेबल के टुकड़े के आकार की जांच कर सकते हैं।

 zabbix=> SELECT chunk_table,total_bytes FROM chunk_relation_size('history_uint');              chunk_table               | total_bytes -----------------------------------------+------------- _timescaledb_internal._hyper_2_6_chunk  |    13287424 _timescaledb_internal._hyper_2_7_chunk  |    13172736 _timescaledb_internal._hyper_2_8_chunk  |    13344768 _timescaledb_internal._hyper_2_9_chunk  |    13434880 _timescaledb_internal._hyper_2_10_chunk |    13230080 _timescaledb_internal._hyper_2_11_chunk |    13189120 

सभी हाइपरटेबल्स के लिए टुकड़े के आकार को खोजने के लिए इस कॉल को दोहराया जा सकता है। यदि, उदाहरण के लिए, यह पाया गया कि history_uint का टुकड़ा आकार 13MB है, तो अन्य इतिहास तालिकाओं के लिए टुकड़े, 20MB और प्रवृत्ति तालिका 10MB के लिए कहें, तो कुल मेमोरी आवश्यकता 13 + 4 x 20 + 2 x 10 / 113MB है। हमें अन्य डेटा संग्रहीत करने के लिए शेयर्ड_बफर्स ​​से भी जगह छोड़नी चाहिए, 20% कहते हैं। फिर शेयर्ड_बफर्स ​​का मूल्य 113MB / 0.8 = ~ 140MB होना चाहिए।

TSDB के महीन ट्यूनिंग के लिए, हाल ही में फैली हुई टेक्डबेड-ट्यून उपयोगिता दिखाई दी है। यह postgresql.conf का विश्लेषण करता है, इसे सिस्टम कॉन्फ़िगरेशन (मेमोरी और प्रोसेसर) के साथ संबद्ध करता है, और फिर मेमोरी पैरामीटर सेट करने, समानांतर प्रसंस्करण के पैरामीटर, वाल पर सिफारिशें देता है। उपयोगिता postgresql.conf फ़ाइल को बदल देती है, लेकिन आप इसे -dry-run पैरामीटर के साथ चला सकते हैं और प्रस्तावित परिवर्तनों की जांच कर सकते हैं।

हम Zabbix मापदंडों पर ओवरराइड करेंगे आइटम इतिहास अवधि और ओवरराइड आइटम प्रवृत्ति अवधि (प्रशासन में उपलब्ध - सामान्य -> ​​हाउसकीपिंग)। उन्हें TSDB हाइपरटेबल्स के संपूर्ण टुकड़ों के रूप में ऐतिहासिक डेटा को हटाने की आवश्यकता है, न कि रिकॉर्ड्स की।

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

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

TimescaleDB के साथ प्रदर्शन

यह जांचने का समय है कि क्या उपरोक्त सभी वास्तव में काम करते हैं। हमारी टेस्ट बेंच Zabbix 4.2rc1 है PostgreSQL 10.7 और TimescaleDB 1.2.1 के साथ डेबियन 9.। टेस्ट मशीन 10-कोर इंटेल Xeon है जिसमें 16 जीबी रैम और एसएसडी पर 60 जीबी स्टोरेज स्पेस है। आज के मानकों के अनुसार, यह बहुत मामूली विन्यास है, लेकिन हमारा लक्ष्य यह पता लगाना है कि वास्तविक जीवन में TSDB कितना प्रभावी है। असीमित बजट के साथ कॉन्फ़िगरेशन में, आप बस 128-256 जीबी रैम डाल सकते हैं और डेटाबेस के अधिकांश (यदि सभी नहीं) मेमोरी में डाल सकते हैं।

हमारे परीक्षण कॉन्फ़िगरेशन में 32 सक्रिय Zabbix एजेंट शामिल हैं जो डेटा को सीधे Zabbix सर्वर पर स्थानांतरित करते हैं। प्रत्येक एजेंट 10,000 आइटम परोसता है। Zabbix ऐतिहासिक कैश 256MB पर सेट किया गया है, और साझा किया गया_buffers PG 2GB पर सेट है। यह कॉन्फ़िगरेशन डेटाबेस पर पर्याप्त लोड प्रदान करता है, लेकिन साथ ही Zabbix सर्वर प्रक्रियाओं पर एक बड़ा भार नहीं बनाता है। डेटा स्रोतों और डेटाबेस के बीच बढ़ते भागों की संख्या को कम करने के लिए, हमने ज़ैबिक्स प्रॉक्सी का उपयोग नहीं किया।

यहाँ मानक पीजी प्रणाली से प्राप्त पहला परिणाम है:



TSDB का परिणाम पूरी तरह से अलग है:



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



जब इतिहास तालिका खाली होती है, तो TSDB में लिखने की गति पीजी में लिखने की गति के बराबर होती है, और यहां तक ​​कि बाद के एक छोटे से मार्जिन के साथ। जैसे ही इतिहास में रिकॉर्ड की संख्या 50-60 मिलियन तक पहुंच जाती है, पीजी का थ्रूपुट 110K NVPS तक गिर जाता है, लेकिन, जो अधिक अप्रिय है, वह ऐतिहासिक तालिका में संचित रिकॉर्ड की संख्या के साथ विपरीत परिवर्तन जारी रखता है। उसी समय, TSDB 0 से 300 मिलियन रिकॉर्ड से पूरे परीक्षण के दौरान 130K NVPS की एक स्थिर गति बनाए रखता है।

कुल मिलाकर, हमारे उदाहरण में, औसत प्रदर्शन में अंतर काफी महत्वपूर्ण है (130K बनाम 90K प्रारंभिक शिखर को ध्यान में रखे बिना)। यह भी देखा जाता है कि मानक पीजी में सम्मिलन की दर एक विस्तृत श्रृंखला में भिन्न होती है। इस प्रकार, अगर किसी वर्कफ़्लो को इतिहास में दसियों या सैकड़ों लाखों रिकॉर्ड संग्रहीत करने की आवश्यकता होती है, लेकिन बहुत आक्रामक कैशिंग रणनीतियों के लिए कोई संसाधन नहीं हैं, तो TSDB मानक पीजी की जगह के लिए एक मजबूत उम्मीदवार है।

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

निष्कर्ष

TimescaleDB एक बहुत ही आशाजनक तकनीक है। यह पहले से ही गंभीर उत्पादन वातावरण में सफलतापूर्वक संचालित किया गया है। TSDB Zabbix के साथ अच्छा काम करता है और मानक PostgreSQL डेटाबेस पर महत्वपूर्ण लाभ प्रदान करता है।

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

यदि आप PostgreSQL के साथ Zabbix का उपयोग करते हैं, तो कम से कम TimescaleDB का प्रयास नहीं करने का कोई कारण नहीं है। शायद यह बात आपको सुखद रूप से आश्चर्यचकित करेगी :) बस ध्यान रखें कि ज़ैबिक्स में TimescaleDB के लिए समर्थन अभी भी प्रयोगात्मक है - थोड़ी देर के लिए, जबकि हम उपयोगकर्ता समीक्षा और अनुभव प्राप्त करते हैं।