InfluxDB सँग काम गर्दा रिस, बार्गेनिङ र डिप्रेसन

यदि तपाइँ टाइम सीरीज डाटाबेस प्रयोग गर्नुहुन्छ भने (timeseries db, wiki) तथ्याङ्कको साथ साइटको लागि मुख्य भण्डारणको रूपमा, त्यसपछि समस्या समाधान गर्नुको सट्टा तपाईले धेरै टाउको दुखाइ पाउन सक्नुहुन्छ। म यस्तो डाटाबेस प्रयोग गर्ने परियोजनामा ​​काम गर्दैछु, र कहिलेकाहीँ InfluxDB, जुन छलफल गरिनेछ, पूर्ण रूपमा अप्रत्याशित आश्चर्यहरू प्रस्तुत गर्दछ।

त्याग: सूचीबद्ध मुद्दाहरू InfluxDB संस्करण 1.7.4 मा लागू हुन्छन्।

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

परियोजनाले विभिन्न ब्लकचेनहरूमा लेनदेनहरू ट्र्याक गर्ने र तथ्याङ्कहरू प्रदर्शन गर्ने हो। विशेष गरी, हामी स्थिर सिक्काको उत्सर्जन र जलाउने (wiki)। यी लेनदेनको आधारमा, तपाईंले ग्राफहरू निर्माण गर्न र सारांश तालिकाहरू देखाउन आवश्यक छ।

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

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

यो थोरै भ्रमपूर्ण थियो कि त्यस्ता डाटाबेसहरू सामान्यतया मेट्रिक्स सङ्कलन गर्ने उद्देश्यका लागि प्रयोग गरिन्छ। सर्भरहरूको निगरानी, ​​iot उपकरणहरू, सबै चीजहरू जसबाट फारम "प्रवाह" को लाखौं बिन्दुहरू: [<time> - <metric value>]। तर यदि डाटाबेसले ठूलो डाटा प्रवाहको साथ राम्रोसँग काम गर्दछ भने, त्यसो भए किन सानो भोल्युमले समस्या निम्त्याउनु पर्छ? यसलाई दिमागमा राखेर, हामीले InfluxDB लाई काम गर्न लग्यौं।

InfluxDB मा अरू के सुविधाजनक छ

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

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

1. अर्को तालिकामा डेटा जम्मा गर्न निरन्तर क्वेरी सिर्जना गर्नुहोस्;
2. पहिलो तालिकाको लागि, त्यही हप्ता भन्दा पुरानो मेट्रिक्स मेटाउने नीति परिभाषित गर्नुहोस्।

र Influx ले स्वतन्त्र रूपमा डाटाको आकार घटाउनेछ र अनावश्यक चीजहरू मेटाउनेछ।

भण्डारण डाटा बारे

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

समस्याहरू

सेवाको विकास र पछिल्लो परीक्षणको क्रममा, InfluxDB को सञ्चालनमा अधिक र अधिक महत्वपूर्ण समस्याहरू देखा पर्यो।

1. डाटा मेटाउँदै

लेनदेन संग डेटा को एक श्रृंखला छ:

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

परिणाम:

म डाटा मेटाउन आदेश पठाउँदै छु:

DELETE FROM transactions WHERE symbol=’USDT’

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

म सम्पूर्ण तालिका मेटाउने प्रयास गर्दैछु:

DROP MEASUREMENT transactions

म तालिका मेटाउने जाँच गर्छु:

SHOW MEASUREMENTS

म सूचीमा तालिका देख्दिन, तर नयाँ डेटा क्वेरीले अझै पनि लेनदेनको समान सेट फर्काउँछ।

समस्या मलाई एक पटक मात्र आयो, किनकि मेटाउने मामला एक अलग मामला थियो। तर डाटाबेसको यो व्यवहार स्पष्ट रूपमा "सही" सञ्चालनको ढाँचामा फिट हुँदैन। पछि मैले यसलाई github मा खुला पाए टिकट यस विषयमा करिब एक वर्षअघि ।

नतिजाको रूपमा, मेटाउन र त्यसपछि सम्पूर्ण डाटाबेस पुनर्स्थापित गर्न मद्दत गर्यो।

2. फ्लोटिंग बिन्दु नम्बरहरू

InfluxDB मा निर्मित प्रकार्यहरू प्रयोग गर्दा गणित गणनाहरूमा सटीकता त्रुटिहरू छन्। यो असामान्य कुरा होइन, तर यो अप्रिय छ।

मेरो मामलामा, डेटामा वित्तीय घटक छ र म यसलाई उच्च सटीकताका साथ प्रशोधन गर्न चाहन्छु। यस कारण, हामी निरन्तर प्रश्नहरू त्याग्न योजना बनाउँछौं।

3. निरन्तर प्रश्नहरू विभिन्न समय क्षेत्रहरूमा अनुकूलित गर्न सकिँदैन

सेवासँग दैनिक लेनदेन तथ्याङ्कहरूको साथ तालिका छ। प्रत्येक दिनको लागि, तपाईंले त्यो दिनको लागि सबै लेनदेनहरू समूहबद्ध गर्न आवश्यक छ। तर प्रत्येक प्रयोगकर्ताको दिन फरक समयमा सुरु हुनेछ, र त्यसैले लेनदेनको सेट फरक हुनेछ। UTC द्वारा हो 37 विकल्प पालीहरू जसको लागि तपाईंले डेटा जम्मा गर्न आवश्यक छ।

InfluxDB मा, समय अनुसार समूहबद्ध गर्दा, तपाइँ थप रूपमा एक शिफ्ट निर्दिष्ट गर्न सक्नुहुन्छ, उदाहरणका लागि मस्को समय (UTC+3):

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

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

यस समस्याको वरिपरि काम गर्न, हामीले अस्थायी रूपमा सेवालाई UTC+0 मा स्विच गर्यौं।

4. प्रदर्शन

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

म तिमीलाई मेरो मामला बताउछु।

सेवाले अन्तिम दिनको तथ्याङ्क फिर्ता गर्ने API विधि प्रदान गर्दछ। गणनाहरू प्रदर्शन गर्दा, विधिले निम्न प्रश्नहरूसँग डाटाबेसलाई तीन पटक सोध्छ:

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

स्पष्टीकरण:

1. पहिलो अनुरोधमा, हामीले बजार डेटाको साथ प्रत्येक सिक्काको लागि अन्तिम अंकहरू पाउँछौं। मेरो मामला मा आठ सिक्का लागि आठ अंक।
2. दोस्रो अनुरोधले सबैभन्दा नयाँ बिन्दुहरू मध्ये एक पाउँछ।
3. तेस्रोले पछिल्लो XNUMX घण्टाको लेनदेनको सूची अनुरोध गर्दछ; त्यहाँ ती मध्ये धेरै सय हुन सक्छन्।

मलाई स्पष्ट गर्न दिनुहोस् कि InfluxDB ले स्वचालित रूपमा ट्याग र समयको आधारमा अनुक्रमणिका बनाउँछ, जसले प्रश्नहरूको गति बढाउँछ। पहिलो अनुरोधमा प्रतीक ट्याग छ।

मैले यस API विधिमा तनाव परीक्षण चलाएको छु। 25 RPS को लागि, सर्भरले छ CPU हरूको पूर्ण लोड प्रदर्शन गर्‍यो:

एकै समयमा, NodeJs प्रक्रियाले कुनै पनि लोड प्रदान गर्दैन।

कार्यान्वयन गति पहिले नै 7-10 RPS द्वारा घटेको छ: यदि एक ग्राहकले 200 ms मा प्रतिक्रिया प्राप्त गर्न सक्छ भने, त्यसपछि 10 ग्राहकहरूले एक सेकेन्ड पर्खनु पर्ने थियो। 25 RPS त्यो सीमा हो जसमा स्थिरताले भोगेको थियो; 500 त्रुटिहरू ग्राहकहरूलाई फिर्ता गरियो।

यस्तो प्रदर्शन संग हाम्रो परियोजना मा Influx प्रयोग गर्न असम्भव छ। यसबाहेक: एउटा परियोजनामा ​​जहाँ अनुगमन धेरै ग्राहकहरूलाई प्रदर्शन गर्न आवश्यक छ, समान समस्याहरू देखा पर्न सक्छन् र मेट्रिक्स सर्भर ओभरलोड हुनेछ।

निष्कर्षमा

प्राप्त अनुभवबाट सबैभन्दा महत्त्वपूर्ण निष्कर्ष यो हो कि तपाइँ पर्याप्त विश्लेषण बिना एक परियोजनामा ​​अज्ञात प्रविधि लिन सक्नुहुन्न। Github मा खुला मुद्दाहरूको एक साधारण स्क्रीनिंगले InfluxDB लाई मुख्य डाटा स्टोरको रूपमा छनौट गर्नबाट बच्न जानकारी प्रदान गर्न सक्छ।

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

तपाईंले परियोजना भण्डारमा पहिले नै संस्करण 2.0.0-beta फेला पार्न सक्नुहुन्छ; हामी केवल आशा गर्न सक्छौं कि दोस्रो संस्करणमा महत्त्वपूर्ण सुधार हुनेछ। यस बीचमा, म TimescaleDB कागजात अध्ययन गर्न जानेछु।

स्रोत: www.habr.com