👩🏾‍💻 👰🏻 🛄 InfluxDB के साथ काम करने पर गुस्सा, सौदेबाजी और अवसाद 👰🏼 👨‍✈️ 🚴🏽

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

डिस्क्लेमर : ये समस्याएँ इंफ्लुएंसडीबी 1.7.4 के लिए हैं।

क्यों समय श्रृंखला?

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

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

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

यह थोड़ा शर्मनाक था कि आमतौर पर ऐसे डेटाबेस का उपयोग मैट्रिक्स इकट्ठा करने के लिए किया जाता है। मॉनिटरिंग सर्वर, आईओटी-डिवाइसेस, जिसमें से सभी फॉर्म के लाखों बिंदु "डालना": [<समय> - <मीट्रिक मूल्य>]। लेकिन अगर डेटाबेस डेटा के एक बड़े प्रवाह के साथ अच्छी तरह से काम करता है, तो थोड़ी मात्रा में समस्याएं क्यों होनी चाहिए? इसे ध्यान में रखते हुए, उन्होंने काम करने के लिए InfluxDB लिया।

InfluxDB में और क्या सुविधाजनक है

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

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

किसी अन्य तालिका में डेटा एकत्र करने के लिए एक निरंतर क्वेरी बनाएं;
पहली तालिका के लिए, उस सप्ताह से पुराने मैट्रिक्स को हटाने के लिए एक नीति निर्धारित करें।

और इन्फ्लक्स स्वतंत्र रूप से डेटा के आकार को कम करेगा और अनावश्यक को हटा देगा।

संग्रहीत डेटा के बारे में

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

समस्याओं

सेवा के विकास और उसके बाद के परीक्षण के दौरान, अधिक से अधिक महत्वपूर्ण समस्याएं इन्फ्लुएंक्सडीबी के संचालन के दौरान उत्पन्न हुईं।

1. डेटा का विलोपन

लेनदेन के साथ डेटा की एक श्रृंखला है:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

परिणाम:

मैं डेटा हटाने के लिए एक आदेश भेजता हूं:

 DELETE FROM transactions WHERE symbol='USDT'

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

मैं पूरी तालिका को हटाने का प्रयास करता हूं:

 DROP MEASUREMENT transactions

मैं टेबल विलोपन की जाँच करता हूँ:

 SHOW MEASUREMENTS

मैं सूची में तालिका नहीं देखता, लेकिन एक नया डेटा अनुरोध अभी भी लेनदेन का एक ही सेट लौटाता है।

मेरे लिए समस्या केवल एक बार हुई, क्योंकि हटाने का मामला एक अलग मामला है। लेकिन डेटाबेस का यह व्यवहार स्पष्ट रूप से "सही" कार्य के ढांचे में फिट नहीं होता है। बाद में जीथब पर मुझे इस विषय पर लगभग एक साल पहले एक खुला टिकट मिला।

नतीजतन, पूरे डेटाबेस को हटाने और बाद में बहाली में मदद मिली।

2. फ्लोटिंग-पॉइंट नंबर

इन्फ्लक्सडीबी में अंतर्निहित कार्यों का उपयोग करके गणितीय गणना सटीकता त्रुटियों को देती है। ऐसा नहीं है कि यह कुछ भी असामान्य था, लेकिन अप्रिय।

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

3. निरंतर प्रश्नों को अलग-अलग समय क्षेत्रों के लिए अनुकूलित नहीं किया जा सकता है

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

InfluxDB में समय के अनुसार समूहीकरण करते समय, आप अतिरिक्त रूप से एक शिफ्ट निर्दिष्ट कर सकते हैं, उदाहरण के लिए, मॉस्को समय (UTC + 3) के लिए:

 SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

लेकिन क्वेरी परिणाम गलत होगा। किसी कारण से, दिन के आधार पर डेटा 1677 के रूप में शुरू हो जाएगा (इन्फ्लक्सडीबी आधिकारिक तौर पर इस वर्ष से समय अवधि का समर्थन करता है):

इस समस्या को हल करने के लिए, सेवा को अस्थायी रूप से UTC + 0 पर स्थानांतरित कर दिया गया था।

4. प्रदर्शन

इंटरनेट पर कई बेंचमार्क हैं जिनमें इन्फ्लक्सबीडी और अन्य डेटाबेस की तुलना है। पहले परिचित पर, वे विपणन सामग्री की तरह दिखते थे, लेकिन अब मुझे लगता है कि उनमें कुछ सच्चाई है।

मैं आपको अपना मामला बताऊंगा।

सेवा एक एपीआई विधि प्रदान करती है जो अंतिम दिन के लिए आंकड़े लौटाती है। गणना के दौरान, विधि निम्नलिखित प्रश्नों के साथ डेटाबेस पर तीन बार प्रश्न करती है:

 SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

 SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

 SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

स्पष्टीकरण:

पहली क्वेरी में, हमें बाजार डेटा के साथ प्रत्येक सिक्के के लिए अंतिम अंक मिलते हैं। मेरे मामले में आठ सिक्कों के लिए आठ अंक।
दूसरा अनुरोध एक नवीनतम बिंदु प्राप्त करता है।
तीसरा एक अंतिम दिन लेनदेन की सूची का अनुरोध करता है, कई सौ हो सकते हैं।

मैं स्पष्ट करूंगा कि InfluxDB में, एक सूचकांक स्वचालित रूप से टैग और समय के अनुसार बनाया जाता है, जो प्रश्नों को गति देता है। पहली क्वेरी में, प्रतीक टैग है।

मैंने इस एपीआई विधि के लिए एक तनाव परीक्षण किया। 25 आरपीएस के लिए, सर्वर ने छह सीपीयू का पूरा लोड दिखाया:

इसी समय, NodeJs प्रक्रिया ने कोई भी भार नहीं दिया।

निष्पादन की गति पहले से ही 7-10 आरपीएस से कम हो गई है: यदि एक ग्राहक को 200 एमएस में प्रतिक्रिया मिल सकती है, तो 10 ग्राहकों को एक सेकंड इंतजार करना चाहिए। 25 आरपीएस - जिस सीमा के साथ स्थिरता का सामना करना पड़ा, 500 त्रुटियों को ग्राहकों को वापस कर दिया गया था।

ऐसे प्रदर्शन के साथ, हमारी परियोजना में इन्फ्लक्स का उपयोग करना असंभव है। इसके अलावा: एक परियोजना में जहां आपको कई ग्राहकों को निगरानी प्रदर्शित करने की आवश्यकता होती है, इसी तरह की समस्याएं दिखाई दे सकती हैं और मीट्रिक सर्वर ओवरलोड हो जाएगा।

निष्कर्ष

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

InfluxDB मेरी परियोजना के कार्यों के लिए अच्छी तरह से अनुकूल होना चाहिए था, लेकिन जैसा कि अभ्यास से पता चला है, यह डेटाबेस जरूरतों को पूरा नहीं करता है और बहुत गड़बड़ करता है।

आप प्रोजेक्ट रिपॉजिटरी में पहले से ही संस्करण 2.0.0-बीटा पा सकते हैं, यह आशा है कि दूसरे संस्करण में महत्वपूर्ण सुधार होंगे। इस बीच, मैं TimescaleDB प्रलेखन का अध्ययन करने जा रहा हूं।

InfluxDB के साथ काम करने पर गुस्सा, सौदेबाजी और अवसाद