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

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

Disclaimer: सूचीबद्ध समस्याएँ InfluxDB संस्करण 1.7.4 पर लागू होती हैं।

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

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

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

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

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

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

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

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

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

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

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

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

समस्याओं

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

1. डेटा हटाना

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

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

रिजल्ट:

मैं डेटा हटाने के लिए एक कमांड भेज रहा हूं:

DELETE FROM transactions WHERE symbol=’USDT’

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

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

DROP MEASUREMENT transactions

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

SHOW MEASUREMENTS

मुझे सूची में तालिका नहीं दिख रही है, लेकिन एक नई डेटा क्वेरी अभी भी लेनदेन का वही सेट लौटाती है।

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

परिणामस्वरूप, संपूर्ण डेटाबेस को हटाने और फिर पुनर्स्थापित करने से मदद मिली।

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

InfluxDB में अंतर्निहित फ़ंक्शंस का उपयोग करते समय गणित गणना में सटीकता त्रुटियां होती हैं। ऐसा नहीं है कि यह कोई असामान्य बात है, लेकिन यह अप्रिय है।

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

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

सेवा में दैनिक लेनदेन आंकड़ों वाली एक तालिका है। प्रत्येक दिन के लिए, आपको उस दिन के सभी लेन-देन को समूहीकृत करना होगा। लेकिन प्रत्येक उपयोगकर्ता का दिन अलग-अलग समय पर शुरू होगा, और इसलिए लेनदेन का सेट अलग होगा। यूटीसी द्वारा हाँ 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

स्पष्टीकरण:

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

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

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

उसी समय, NodeJs प्रक्रिया ने बिल्कुल भी कोई लोड प्रदान नहीं किया।

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

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

उत्पादन

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

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

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

स्रोत: www.habr.com