🥇 InfluxDB सोबत काम करताना राग, सौदेबाजी आणि नैराश्य

तुम्ही टाइम सिरीज डेटाबेस वापरत असल्यास (टाइमसीरीज डीबी, विकी) आकडेवारीसह साइटसाठी मुख्य स्टोरेज म्हणून, नंतर समस्या सोडवण्याऐवजी आपल्याला खूप डोकेदुखी होऊ शकते. मी अशा डेटाबेसचा वापर करणार्‍या प्रकल्पावर काम करत आहे आणि काहीवेळा InfluxDB, ज्यावर चर्चा केली जाईल, पूर्णपणे अनपेक्षित आश्चर्य सादर केले जाईल.

जबाबदारी नाकारणे: सूचीबद्ध समस्या InfluxDB आवृत्ती 1.7.4 वर लागू होतात.

वेळ मालिका का?

विविध ब्लॉकचेनवरील व्यवहारांचा मागोवा घेणे आणि आकडेवारी प्रदर्शित करणे हा प्रकल्प आहे. विशेषतः, आम्ही स्थिर नाण्यांचे उत्सर्जन आणि जळणे पाहतो (विकी). या व्यवहारांवर आधारित, तुम्हाला आलेख तयार करणे आणि सारांश सारण्या दाखवणे आवश्यक आहे.

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

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

हे थोडे गोंधळात टाकणारे होते की असे डेटाबेस सहसा मेट्रिक्स गोळा करण्याच्या उद्देशाने वापरले जातात. सर्व्हरचे निरीक्षण, आयओटी उपकरणे, सर्व काही ज्यातून लाखो बिंदू “प्रवाह”: [ - ]. परंतु जर डेटाबेस मोठ्या डेटा प्रवाहासह चांगले कार्य करते, तर लहान व्हॉल्यूममुळे समस्या का निर्माण होऊ शकतात? हे लक्षात घेऊन, आम्ही InfluxDB ला कार्य करण्यासाठी घेतले.

InfluxDB मध्ये आणखी काय सोयीचे आहे

नमूद केलेल्या एकत्रीकरण कार्यांव्यतिरिक्त, आणखी एक चांगली गोष्ट आहे - सतत प्रश्न (दस्तऐवज). हा डेटाबेसमध्ये तयार केलेला शेड्यूलर आहे जो शेड्यूलवर डेटावर प्रक्रिया करू शकतो. उदाहरणार्थ, दर 24 तासांनी तुम्ही दिवसभरातील सर्व नोंदी गटबद्ध करू शकता, सरासरीची गणना करू शकता आणि तुमची स्वतःची सायकल न लिहिता दुसर्‍या टेबलमध्ये एक नवीन बिंदू रेकॉर्ड करू शकता.

देखील आहे धारणा धोरणे (दस्तऐवज)—विशिष्ट कालावधीनंतर डेटा हटवणे सेट करणे. हे उपयुक्त आहे जेव्हा, उदाहरणार्थ, आपल्याला एका आठवड्यासाठी CPU लोड प्रति सेकंदात एकदा मोजणे आवश्यक असते, परंतु काही महिन्यांच्या अंतरावर अशा अचूकतेची आवश्यकता नसते. अशा परिस्थितीत, आपण हे करू शकता:

दुसर्‍या टेबलमध्ये डेटा एकत्रित करण्यासाठी सतत क्वेरी तयार करा;
पहिल्या सारणीसाठी, त्याच आठवड्यापेक्षा जुने मेट्रिक्स हटवण्यासाठी धोरण परिभाषित करा.

आणि इन्फ्लक्स स्वतंत्रपणे डेटाचा आकार कमी करेल आणि अनावश्यक गोष्टी हटवेल.

संग्रहित डेटा बद्दल

जास्त डेटा संग्रहित नाही: सुमारे 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

मला सूचीमध्‍ये सारणी दिसत नाही, परंतु नवीन डेटा क्‍वेरी अजूनही समान व्‍यवहारांचा संच देते.

मला ही समस्या फक्त एकदाच आली, कारण डिलीट केस ही एक वेगळी केस होती. परंतु डेटाबेसचे हे वर्तन स्पष्टपणे "योग्य" ऑपरेशनच्या चौकटीत बसत नाही. नंतर मला ते 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

स्पष्टीकरण:

पहिल्या विनंतीमध्ये, आम्हाला बाजार डेटासह प्रत्येक नाण्याचे शेवटचे गुण मिळतात. माझ्या बाबतीत आठ नाण्यांसाठी आठ गुण.
दुसर्‍या विनंतीला सर्वात नवीन बिंदूंपैकी एक मिळते.
तिसरा गेल्या XNUMX तासांच्या व्यवहारांच्या सूचीची विनंती करतो; त्यापैकी शंभर असू शकतात.

मी स्पष्ट करतो की InfluxDB टॅग आणि वेळेवर आधारित एक निर्देशांक आपोआप तयार करते, जे प्रश्नांची गती वाढवते. पहिल्या विनंती मध्ये चिन्ह टॅग आहे.

मी या API पद्धतीवर ताण चाचणी चालवली आहे. 25 RPS साठी, सर्व्हरने सहा CPU चा पूर्ण भार प्रदर्शित केला:

त्याच वेळी, NodeJs प्रक्रियेने कोणतेही लोड दिले नाही.

अंमलबजावणीची गती आधीच 7-10 RPS ने कमी झाली आहे: जर एका क्लायंटला 200 ms मध्ये प्रतिसाद मिळू शकला, तर 10 क्लायंटला एक सेकंद प्रतीक्षा करावी लागेल. 25 RPS ही मर्यादा आहे ज्यावर स्थिरता सहन करावी लागली; 500 त्रुटी ग्राहकांना परत केल्या गेल्या.

अशा कामगिरीसह आमच्या प्रकल्पात इन्फ्लक्स वापरणे अशक्य आहे. शिवाय: ज्या प्रोजेक्टमध्ये अनेक क्लायंट्सना देखरेख दाखवण्याची गरज असते, अशाच समस्या दिसू शकतात आणि मेट्रिक्स सर्व्हर ओव्हरलोड होईल.

निष्कर्ष

मिळालेल्या अनुभवातून सर्वात महत्त्वाचा निष्कर्ष असा आहे की पुरेसे विश्लेषण केल्याशिवाय तुम्ही अज्ञात तंत्रज्ञान प्रकल्पात घेऊ शकत नाही. मुख्य डेटा स्टोअर म्हणून InfluxDB निवडणे टाळण्यासाठी गिथबवरील खुल्या समस्यांचे एक साधे स्क्रीनिंग माहिती प्रदान करू शकते.

माझ्या प्रकल्पाच्या कामांसाठी InfluxDB योग्य असायला हवे होते, परंतु सरावाने दाखवल्याप्रमाणे, हा डेटाबेस गरजा पूर्ण करत नाही आणि त्यात बरेच बग आहेत.

प्रोजेक्ट रिपॉजिटरीमध्ये तुम्हाला आवृत्ती 2.0.0-बीटा आधीच सापडेल; आम्ही फक्त आशा करू शकतो की दुसऱ्या आवृत्तीमध्ये लक्षणीय सुधारणा होईल. यादरम्यान, मी TimescaleDB दस्तऐवजीकरणाचा अभ्यास करेन.

स्त्रोत: www.habr.com

InfluxDB सह काम करताना राग, सौदेबाजी आणि नैराश्य