ការខឹងសម្បារ ការចរចា និងការធ្លាក់ទឹកចិត្តនៅពេលធ្វើការជាមួយ InfluxDB

ប្រសិនបើអ្នកប្រើមូលដ្ឋានទិន្នន័យស៊េរីពេលវេលា (timeseries db, វិ​គី) ជាកន្លែងផ្ទុកសំខាន់សម្រាប់គេហទំព័រដែលមានស្ថិតិ បន្ទាប់មកជំនួសឱ្យការដោះស្រាយបញ្ហា អ្នកអាចឈឺក្បាលច្រើន។ ខ្ញុំកំពុងធ្វើការលើគម្រោងដែលប្រើមូលដ្ឋានទិន្នន័យបែបនេះ ហើយពេលខ្លះ InfluxDB ដែលនឹងត្រូវបានពិភាក្សា បង្ហាញពីការភ្ញាក់ផ្អើលដែលមិននឹកស្មានដល់ទាំងស្រុង។

ការមិនទទួលខុសត្រូវ៖ បញ្ហាដែលបានរាយបញ្ជីអនុវត្តចំពោះ InfluxDB កំណែ 1.7.4 ។

ហេតុអ្វីបានជាស៊េរីពេលវេលា?

គម្រោងនេះគឺដើម្បីតាមដានប្រតិបត្តិការនៅលើ blockchain ផ្សេងៗ និងបង្ហាញស្ថិតិ។ ជាពិសេស យើងពិនិត្យមើលការបំភាយ និងការដុតកាក់ដែលមានស្ថេរភាព (វិ​គី) ដោយផ្អែកលើប្រតិបត្តិការទាំងនេះ អ្នកត្រូវបង្កើតក្រាហ្វ និងបង្ហាញតារាងសង្ខេប។

ខណៈពេលដែលការវិភាគប្រតិបត្តិការ គំនិតមួយបានកើតឡើង៖ ដើម្បីប្រើមូលដ្ឋានទិន្នន័យស៊េរីពេលវេលា InfluxDB ជាកន្លែងផ្ទុកសំខាន់។ ប្រតិបត្តិការគឺជាចំណុចនៅក្នុងពេលវេលា ហើយពួកវាសមល្អទៅនឹងគំរូស៊េរីពេលវេលា។

មុខងារប្រមូលផ្តុំក៏មើលទៅមានភាពងាយស្រួលផងដែរ - ល្អសម្រាប់ដំណើរការតារាងដែលមានរយៈពេលវែង។ អ្នកប្រើប្រាស់ត្រូវការគំនូសតាងសម្រាប់មួយឆ្នាំ ហើយមូលដ្ឋានទិន្នន័យមានសំណុំទិន្នន័យដែលមានរយៈពេលប្រាំនាទី។ វាគ្មានន័យទេក្នុងការផ្ញើចំណុចទាំងអស់មួយរយពាន់ឱ្យគាត់ - ក្រៅពីដំណើរការយូរ ពួកវានឹងមិនសមនៅលើអេក្រង់ទេ។ អ្នកអាចសរសេរការអនុវត្តផ្ទាល់ខ្លួនរបស់អ្នកក្នុងការបង្កើនពេលវេលា ឬប្រើមុខងារប្រមូលផ្តុំដែលបានបង្កើតឡើងនៅក្នុង Influx ។ ដោយមានជំនួយរបស់ពួកគេ អ្នកអាចដាក់ទិន្នន័យជាក្រុមតាមថ្ងៃ ហើយផ្ញើ 365 ពិន្ទុដែលត្រូវការ។

វាមានការភាន់ច្រលំបន្តិចថា ជាធម្មតាមូលដ្ឋានទិន្នន័យបែបនេះត្រូវបានប្រើសម្រាប់គោលបំណងនៃការប្រមូលម៉ែត្រ។ ការត្រួតពិនិត្យម៉ាស៊ីនមេ ឧបករណ៍ iot អ្វីគ្រប់យ៉ាងដែលរាប់លានចំណុចនៃទម្រង់ "លំហូរ"៖ [<ពេលវេលា> - <តម្លៃម៉ែត្រ>] ។ ប៉ុន្តែប្រសិនបើមូលដ្ឋានទិន្នន័យដំណើរការល្អជាមួយនឹងលំហូរទិន្នន័យធំ ហេតុអ្វីបានជាបរិមាណតូចមួយគួរតែបង្កបញ្ហា? ជាមួយនឹងគំនិតនេះ យើងបានយក InfluxDB ទៅធ្វើការ។

តើមានអ្វីផ្សេងទៀតដែលងាយស្រួលនៅក្នុង InfluxDB

ក្រៅ​ពី​មុខងារ​ប្រមូល​ផ្តុំ​ដែល​បាន​រៀបរាប់ មាន​រឿង​អស្ចារ្យ​មួយ​ទៀត - សំណួរបន្ត (ឯកសារ) នេះគឺជាកម្មវិធីកំណត់ពេលដែលបានបង្កើតឡើងនៅក្នុងមូលដ្ឋានទិន្នន័យដែលអាចដំណើរការទិន្នន័យតាមកាលវិភាគមួយ។ ជាឧទាហរណ៍ រៀងរាល់ 24 ម៉ោង អ្នកអាចដាក់ជាក្រុមនៃកំណត់ត្រាទាំងអស់សម្រាប់ថ្ងៃ គណនាជាមធ្យម និងកត់ត្រាចំណុចថ្មីមួយនៅក្នុងតារាងមួយផ្សេងទៀតដោយមិនចាំបាច់សរសេរកង់ផ្ទាល់ខ្លួនរបស់អ្នក។

ក៏មានផងដែរ គោលនយោបាយរក្សាទុក (ឯកសារ)-រៀបចំការលុបទិន្នន័យបន្ទាប់ពីរយៈពេលជាក់លាក់មួយ។ វាមានប្រយោជន៍នៅពេលឧទាហរណ៍ អ្នកត្រូវរក្សាទុកការផ្ទុកស៊ីភីយូរយៈពេលមួយសប្តាហ៍ជាមួយនឹងការវាស់វែងម្តងក្នុងមួយវិនាទី ប៉ុន្តែលើសពីរយៈពេលពីរបីខែ ភាពត្រឹមត្រូវបែបនេះមិនចាំបាច់ទេ។ ក្នុងស្ថានភាពបែបនេះ អ្នកអាចធ្វើដូចនេះបាន៖

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 នៅពេលដាក់ជាក្រុមតាមពេលវេលា អ្នកអាចបញ្ជាក់បន្ថែមពីការផ្លាស់ប្តូរ ឧទាហរណ៍សម្រាប់ម៉ោង Moscow (UTC+3)៖

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

ប៉ុន្តែ​លទ្ធផល​សំណួរ​នឹង​មិន​ត្រឹមត្រូវ។ សម្រាប់ហេតុផលមួយចំនួន ទិន្នន័យដែលបានដាក់ជាក្រុមតាមថ្ងៃនឹងចាប់ផ្តើមត្រឡប់ទៅ 1677 (InfluxDB គាំទ្រជាផ្លូវការនូវចន្លោះពេលចាប់ពីឆ្នាំនេះ)៖

ដើម្បីដោះស្រាយបញ្ហានេះ យើងបានប្តូរសេវាកម្មទៅជា UTC+0 ជាបណ្តោះអាសន្ន។

4. ការសម្តែង

មានស្តង់ដារជាច្រើននៅលើអ៊ីនធឺណិតដែលប្រៀបធៀប InfluxDB និងមូលដ្ឋានទិន្នន័យផ្សេងទៀត។ នៅ glance ដំបូង ពួកគេមើលទៅដូចជាសម្ភារៈទីផ្សារ ប៉ុន្តែឥឡូវនេះខ្ញុំគិតថាមានការពិតខ្លះនៅក្នុងពួកគេ។

ខ្ញុំនឹងប្រាប់អ្នកពីករណីរបស់ខ្ញុំ។

សេវាកម្មផ្តល់វិធីសាស្ត្រ 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 ម៉ាស៊ីនមេបានបង្ហាញពីការផ្ទុកពេញលេញនៃស៊ីភីយូប្រាំមួយ:

ទន្ទឹមនឹងនេះដំណើរការ NodeJs មិនបានផ្តល់នូវបន្ទុកណាមួយទាល់តែសោះ។

ល្បឿននៃការប្រតិបត្តិបានធ្លាក់ចុះ 7-10 RPS រួចហើយ៖ ប្រសិនបើអតិថិជនម្នាក់អាចទទួលបានការឆ្លើយតបក្នុង 200 ms នោះអតិថិជន 10 នាក់ត្រូវរង់ចាំមួយវិនាទី។ 25 RPS គឺជាដែនកំណត់ដែលស្ថេរភាពទទួលរងការឈឺចាប់ 500 កំហុសត្រូវបានប្រគល់ជូនអតិថិជនវិញ។

ជាមួយនឹងការអនុវត្តបែបនេះ វាមិនអាចទៅរួចទេក្នុងការប្រើ Influx នៅក្នុងគម្រោងរបស់យើង។ ជាងនេះទៅទៀត៖ នៅក្នុងគម្រោងដែលការត្រួតពិនិត្យចាំបាច់ត្រូវបង្ហាញដល់អតិថិជនជាច្រើន បញ្ហាស្រដៀងគ្នាអាចនឹងលេចឡើង ហើយម៉ាស៊ីនមេម៉ែត្រនឹងផ្ទុកលើសទម្ងន់។

សេចក្តីសន្និដ្ឋាន

ការសន្និដ្ឋានដ៏សំខាន់បំផុតពីបទពិសោធន៍ដែលទទួលបានគឺថា អ្នកមិនអាចយកបច្ចេកវិទ្យាមិនស្គាល់ទៅក្នុងគម្រោងដោយគ្មានការវិភាគគ្រប់គ្រាន់នោះទេ។ ការត្រួតពិនិត្យសាមញ្ញនៃបញ្ហាបើកចំហនៅលើ github អាចផ្តល់ព័ត៌មានដើម្បីជៀសវាងការជ្រើសរើស InfluxDB ជាឃ្លាំងទិន្នន័យសំខាន់។

InfluxDB គួរតែសមល្អសម្រាប់ភារកិច្ចនៃគម្រោងរបស់ខ្ញុំ ប៉ុន្តែដូចដែលការអនុវត្តបានបង្ហាញ មូលដ្ឋានទិន្នន័យនេះមិនបំពេញតាមតម្រូវការ និងមានកំហុសច្រើន។

អ្នកអាចស្វែងរកកំណែ 2.0.0-beta រួចហើយនៅក្នុងឃ្លាំងគម្រោង យើងអាចសង្ឃឹមថាកំណែទីពីរនឹងមានការកែលម្អគួរឱ្យកត់សម្គាល់។ ក្នុងពេលនេះ ខ្ញុំនឹងទៅសិក្សាឯកសារ TimescaleDB។

ប្រភព: www.habr.com