របៀបដែលយើងបានសាកល្បងមូលដ្ឋានទិន្នន័យស៊េរីពេលវេលាច្រើន។

ក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ មូលដ្ឋានទិន្នន័យស៊េរីពេលវេលាបានប្រែក្លាយពីអ្វីដែលហួសសម័យ (ឯកទេសខ្ពស់ដែលប្រើទាំងនៅក្នុងប្រព័ន្ធត្រួតពិនិត្យបើកចំហ (និងភ្ជាប់ទៅនឹងដំណោះស្រាយជាក់លាក់) ឬនៅក្នុងគម្រោងទិន្នន័យធំ) ទៅជា "ផលិតផលអ្នកប្រើប្រាស់"។ នៅលើទឹកដីនៃសហព័ន្ធរុស្ស៊ីការអរគុណពិសេសត្រូវតែត្រូវបានផ្តល់ឱ្យ Yandex និង ClickHouse ។ រហូតមកដល់ចំណុចនេះ ប្រសិនបើអ្នកត្រូវការរក្សាទុកទិន្នន័យស៊េរីពេលវេលាដ៏ច្រើន អ្នកត្រូវតែបំពេញតម្រូវការក្នុងការសាងសង់ជង់ Hadoop ដ៏អស្ចារ្យ និងរក្សាវា ឬទំនាក់ទំនងជាមួយពិធីការនីមួយៗសម្រាប់ប្រព័ន្ធនីមួយៗ។

វាហាក់ដូចជាថានៅឆ្នាំ 2019 អត្ថបទដែល TSDB មានតម្លៃប្រើនឹងមានប្រយោគតែមួយ៖ "គ្រាន់តែប្រើ ClickHouse" ។ ប៉ុន្តែ ... មាន nuances ។

ជាការពិតណាស់ ClickHouse កំពុងអភិវឌ្ឍយ៉ាងសកម្ម មូលដ្ឋានអ្នកប្រើប្រាស់កំពុងកើនឡើង ហើយការគាំទ្រគឺសកម្មខ្លាំងណាស់ ប៉ុន្តែតើយើងបានក្លាយជាចំណាប់ខ្មាំងចំពោះភាពជោគជ័យជាសាធារណៈរបស់ ClickHouse ដែលបានគ្របដណ្ដប់លើដំណោះស្រាយផ្សេងទៀត ប្រហែលជាដំណោះស្រាយដែលមានប្រសិទ្ធភាព/អាចទុកចិត្តបានជាង?

នៅដើមឆ្នាំមុន យើងបានចាប់ផ្តើមដំណើរការឡើងវិញនូវប្រព័ន្ធត្រួតពិនិត្យផ្ទាល់ខ្លួនរបស់យើង ក្នុងអំឡុងពេលនោះ សំណួរបានកើតឡើងនៃការជ្រើសរើសមូលដ្ឋានទិន្នន័យសមរម្យសម្រាប់ការរក្សាទុកទិន្នន័យ។ ខ្ញុំចង់និយាយអំពីប្រវត្តិនៃជម្រើសនេះនៅទីនេះ។

ការបង្កើតបញ្ហា

ដំបូងបង្អស់ បុព្វកថាចាំបាច់។ ហេតុអ្វី​បាន​ជា​យើង​ត្រូវ​ការ​ប្រព័ន្ធ​ត្រួត​ពិនិត្យ​ផ្ទាល់​ខ្លួន​របស់​យើង ហើយ​តើ​វា​ត្រូវ​បាន​រចនា​ឡើង​ដោយ​របៀប​ណា?

យើងបានចាប់ផ្តើមផ្តល់សេវាគាំទ្រនៅឆ្នាំ 2008 ហើយនៅឆ្នាំ 2010 វាច្បាស់ណាស់ថាវាពិបាកក្នុងការប្រមូលផ្តុំទិន្នន័យអំពីដំណើរការដែលកើតឡើងនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធអតិថិជនជាមួយនឹងដំណោះស្រាយដែលមាននៅពេលនោះ (យើងកំពុងនិយាយអំពីព្រះជាម្ចាស់អត់ទោសឱ្យខ្ញុំ Cacti, Zabbix និងក្រាហ្វិចដែលកំពុងលេចឡើង) ។

តម្រូវការចម្បងរបស់យើងគឺ៖

• ការគាំទ្រ (នៅពេលនោះ - រាប់សិបនាក់ហើយនៅពេលអនាគត - រាប់រយ) នៃអតិថិជននៅក្នុងប្រព័ន្ធមួយហើយក្នុងពេលតែមួយវត្តមាននៃប្រព័ន្ធគ្រប់គ្រងការជូនដំណឹងកណ្តាល។
• ភាពបត់បែនក្នុងការគ្រប់គ្រងប្រព័ន្ធដាស់តឿន (ការកើនឡើងនៃការដាស់តឿនរវាងមន្រ្តីកាតព្វកិច្ច កាលវិភាគ មូលដ្ឋានចំណេះដឹង);
• សមត្ថភាពក្នុងការលម្អិតក្រាហ្វិកយ៉ាងជ្រាលជ្រៅ (Zabbix នៅពេលនោះបានបង្ហាញក្រាហ្វក្នុងទម្រង់នៃរូបភាព);
• ការផ្ទុកទិន្នន័យរយៈពេលវែងនៃចំនួនដ៏ធំនៃទិន្នន័យ (មួយឆ្នាំឬច្រើនជាងនេះ) និងសមត្ថភាពក្នុងការទាញយកវាយ៉ាងឆាប់រហ័ស។

នៅក្នុងអត្ថបទនេះយើងចាប់អារម្មណ៍លើចំណុចចុងក្រោយ។

និយាយអំពីការផ្ទុក, តម្រូវការមានដូចខាងក្រោម:

• ប្រព័ន្ធត្រូវតែដំណើរការយ៉ាងឆាប់រហ័ស;
• វាជាការចង់បានដែលប្រព័ន្ធមានចំណុចប្រទាក់ SQL ។
• ប្រព័ន្ធត្រូវតែមានស្ថេរភាព និងមានមូលដ្ឋានអ្នកប្រើប្រាស់សកម្ម និងការគាំទ្រ (នៅពេលដែលយើងប្រឈមមុខនឹងតម្រូវការគាំទ្រប្រព័ន្ធដូចជា MemcacheDB ដែលលែងត្រូវបានបង្កើតឡើង ឬការផ្ទុកចែកចាយ MooseFS កម្មវិធីតាមដានកំហុសដែលត្រូវបានរក្សាទុកជាភាសាចិន៖ យើងនិយាយរឿងនេះឡើងវិញសម្រាប់គម្រោងរបស់យើងមិនចង់បាន);
• ការអនុលោមតាមទ្រឹស្តីបទ CAP៖ ភាពស៊ីសង្វាក់គ្នា (ទាមទារ) - ទិន្នន័យត្រូវតែទាន់សម័យ យើងមិនចង់ឱ្យប្រព័ន្ធគ្រប់គ្រងការដាស់តឿនមិនទទួលបានទិន្នន័យថ្មី និងបញ្ចេញការជូនដំណឹងអំពីការមិនមកដល់នៃទិន្នន័យសម្រាប់គម្រោងទាំងអស់នោះទេ។ Partition Tolerance (ទាមទារ) - យើងមិនចង់ទទួលបានប្រព័ន្ធ Split Brain ទេ។ ភាពអាចរកបាន (មិនសំខាន់ទេប្រសិនបើមានការចម្លងសកម្ម) - យើងអាចប្តូរទៅប្រព័ន្ធបម្រុងទុកដោយខ្លួនឯងក្នុងករណីមានគ្រោះថ្នាក់ដោយប្រើលេខកូដ។

ចម្លែកគ្រប់គ្រាន់ហើយ នៅពេលនោះ MySQL បានក្លាយជាដំណោះស្រាយដ៏ល្អសម្រាប់យើង។ រចនាសម្ព័ន្ធទិន្នន័យរបស់យើងគឺសាមញ្ញបំផុត៖ លេខសម្គាល់ម៉ាស៊ីនមេ លេខសម្គាល់រាប់ ត្រាពេលវេលា និងតម្លៃ។ ការធ្វើសំណាកគំរូរហ័សនៃទិន្នន័យក្តៅត្រូវបានធានាដោយបណ្តុំសតិបណ្ដោះអាសន្នដ៏ធំមួយ ហើយការយកគំរូទិន្នន័យប្រវត្តិសាស្ត្រត្រូវបានធានាដោយ SSD ។

ដូច្នេះហើយ យើងសម្រេចបាននូវគំរូនៃទិន្នន័យថ្មីរយៈពេលពីរសប្តាហ៍ ជាមួយនឹងព័ត៌មានលម្អិតចុះទៅ 200 ms វិនាទី មុនពេលទិន្នន័យត្រូវបានបង្ហាញទាំងស្រុង ហើយរស់នៅក្នុងប្រព័ន្ធនេះអស់រយៈពេលជាយូរ។

ទន្ទឹមនឹងនេះពេលវេលាបានកន្លងផុតទៅហើយបរិមាណទិន្នន័យបានកើនឡើង។ នៅឆ្នាំ 2016 បរិមាណទិន្នន័យបានកើនឡើងដល់រាប់សិប terabytes ដែលជាការចំណាយដ៏សំខាន់នៅក្នុងបរិបទនៃការជួលទំហំផ្ទុក SSD ។

មកដល់ពេលនេះ មូលដ្ឋានទិន្នន័យ columnar បានរីករាលដាលយ៉ាងសកម្ម ដែលយើងបានចាប់ផ្តើមគិតយ៉ាងសកម្មអំពី៖ នៅក្នុង columnar databases ទិន្នន័យត្រូវបានរក្សាទុក ដូចដែលអ្នកអាចយល់បាននៅក្នុង columnar ហើយប្រសិនបើអ្នកក្រឡេកមើលទិន្នន័យរបស់យើង វាងាយស្រួលមើល។ ចំនួនស្ទួនដែលអាចនៅក្នុង ប្រសិនបើអ្នកប្រើមូលដ្ឋានទិន្នន័យ columnar បង្ហាប់វាដោយប្រើការបង្ហាប់។

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

នៅឆ្នាំ 2017 នៅឯសន្និសីទ Percona Live នៅ San Jose អ្នកអភិវឌ្ឍន៍ Clickhouse ប្រហែលជាបានប្រកាសខ្លួនឯងជាលើកដំបូង។ នៅ glance ដំបូង ប្រព័ន្ធនេះគឺត្រៀមខ្លួនជាស្រេចសម្រាប់ផលិតកម្ម (ល្អ Yandex.Metrica គឺជាប្រព័ន្ធផលិតកម្មដ៏អាក្រក់) ការគាំទ្រគឺលឿន និងសាមញ្ញ ហើយសំខាន់បំផុត ប្រតិបត្តិការគឺសាមញ្ញ។ ចាប់តាំងពីឆ្នាំ 2018 យើងបានចាប់ផ្តើមដំណើរការផ្លាស់ប្តូរ។ ប៉ុន្តែនៅពេលនោះ មានប្រព័ន្ធ TSDB និង "មនុស្សពេញវ័យ" ជាច្រើនដែលបានសាកល្បង ហើយយើងបានសម្រេចចិត្តលះបង់ពេលវេលាដ៏ច្រើន ហើយប្រៀបធៀបជម្រើសផ្សេងៗ ដើម្បីប្រាកដថាមិនមានដំណោះស្រាយជំនួសសម្រាប់ Clickhouse ស្របតាមតម្រូវការរបស់យើង។

បន្ថែមពីលើតម្រូវការផ្ទុកដែលបានបញ្ជាក់រួចហើយ របស់ថ្មីបានបង្ហាញខ្លួន៖

• ប្រព័ន្ធថ្មីគួរតែផ្តល់នូវការអនុវត្តយ៉ាងហោចណាស់ដូចគ្នានឹង MySQL លើចំនួនដូចគ្នានៃផ្នែករឹង។
• ការផ្ទុកប្រព័ន្ធថ្មីគួរតែយកទំហំតិចគួរឱ្យកត់សម្គាល់។
• DBMS នៅតែងាយស្រួលក្នុងការគ្រប់គ្រង។
• ខ្ញុំចង់ផ្លាស់ប្តូរកម្មវិធីតិចតួចបំផុតនៅពេលផ្លាស់ប្តូរ DBMS ។

តើ​យើង​ចាប់​ផ្ដើម​ពិចារណា​ប្រព័ន្ធ​អ្វី?

Apache Hive / Apache Impala
ជង់ Hadoop ចាស់ដែលសាកល្បងដោយសមរភូមិ។ សំខាន់វាគឺជាចំណុចប្រទាក់ SQL ដែលបង្កើតឡើងនៅលើកំពូលនៃការរក្សាទុកទិន្នន័យក្នុងទម្រង់ដើមនៅលើ HDFS ។

គុណសម្បត្តិ

• ជាមួយនឹងប្រតិបត្តិការដែលមានស្ថេរភាព វាងាយស្រួលណាស់ក្នុងការធ្វើមាត្រដ្ឋានទិន្នន័យ។
• មានដំណោះស្រាយជួរឈរសម្រាប់ការផ្ទុកទិន្នន័យ (ទំហំតិច)។
• ការអនុវត្តការងារស្របគ្នាលឿនណាស់ នៅពេលដែលធនធានមាន។

គុណវិបត្តិ

• វាជា Hadoop ហើយវាពិបាកក្នុងការប្រើ។ ប្រសិនបើយើងមិនទាន់ត្រៀមខ្លួនរួចរាល់ក្នុងការទទួលយកដំណោះស្រាយដែលត្រៀមរួចជាស្រេចនៅក្នុងពពក (ហើយយើងមិនទាន់រួចរាល់ក្នុងលក្ខខណ្ឌនៃការចំណាយ) ជង់ទាំងមូលនឹងត្រូវប្រមូលផ្តុំ និងគាំទ្រដោយដៃរបស់អ្នកគ្រប់គ្រង ហើយយើងពិតជាមិនចង់ នេះ
• ទិន្នន័យត្រូវបានប្រមូលផ្តុំ ពិតជាលឿន.

ប៉ុន្តែ៖

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

Druid/Pinot

មានច្រើនទៀតអំពី TSDB ជាពិសេស ប៉ុន្តែម្តងទៀត ជង់ Hadoop ។

មាន អត្ថបទដ៏អស្ចារ្យដែលប្រៀបធៀបគុណសម្បត្តិ និងគុណវិបត្តិរបស់ Druid និង Pinot ធៀបនឹង ClickHouse .

នៅក្នុងពាក្យពីរបី: Druid / Pinot មើលទៅប្រសើរជាង Clickhouse ក្នុងករណីដែល:

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

ក្នុងករណីផ្ទុយគ្នា ClickHouse ដំណើរការល្អជាង ហើយនេះជាករណីរបស់យើង។

ចុចផ្ទះ

• SQL ដូច
• ងាយស្រួលក្នុងការគ្រប់គ្រង។
• មនុស្សនិយាយថាវាដំណើរការ។

ទទួលបានបញ្ជីសម្រាំងសម្រាប់ការសាកល្បង។

InfluxDB

ជម្រើសបរទេសសម្រាប់ ClickHouse ។ នៃ minuses: ភាពអាចរកបានខ្ពស់គឺមានវត្តមានតែនៅក្នុងកំណែពាណិជ្ជកម្មប៉ុណ្ណោះ ប៉ុន្តែចាំបាច់ត្រូវប្រៀបធៀប។

ទទួលបានបញ្ជីសម្រាំងសម្រាប់ការសាកល្បង។

Cassandra

ម៉្យាងវិញទៀត យើងដឹងថាវាត្រូវបានប្រើដើម្បីរក្សាទុកដងម៉ែត្រដោយប្រព័ន្ធត្រួតពិនិត្យដូចជាឧទាហរណ៍។ SignalFX ឬ OkMeter ។ ទោះយ៉ាងណាក៏ដោយមានលក្ខណៈពិសេស។

Cassandra មិនមែនជាមូលដ្ឋានទិន្នន័យ columnar ក្នុងន័យប្រពៃណីទេ។ វាមើលទៅដូចជាទិដ្ឋភាពជួរ ប៉ុន្តែបន្ទាត់នីមួយៗអាចមានចំនួនជួរឈរផ្សេងគ្នា ដែលធ្វើឱ្យវាងាយស្រួលក្នុងការរៀបចំទិដ្ឋភាពជួរឈរ។ ក្នុងន័យនេះ វាច្បាស់ណាស់ថាជាមួយនឹងដែនកំណត់ចំនួន 2 ពាន់លានជួរឈរ វាអាចរក្សាទុកទិន្នន័យមួយចំនួននៅក្នុងជួរឈរ (និងស៊េរីពេលវេលាដូចគ្នា)។ ឧទាហរណ៍ នៅក្នុង MySQL មានដែនកំណត់ចំនួន 4096 ជួរ ហើយវាងាយស្រួលក្នុងការជំពប់ដួលលើកំហុសជាមួយលេខកូដ 1117 ប្រសិនបើអ្នកព្យាយាមធ្វើដូចគ្នា។

ម៉ាស៊ីន Cassandra គឺផ្តោតលើការរក្សាទុកទិន្នន័យយ៉ាងច្រើននៅក្នុងប្រព័ន្ធចែកចាយដោយគ្មានមេ ហើយទ្រឹស្តីបទ Cassandra CAP ដែលបានរៀបរាប់ខាងលើគឺនិយាយអំពី AP បន្ថែមទៀត ពោលគឺអំពីភាពអាចរកបានទិន្នន័យ និងភាពធន់ទ្រាំទៅនឹងការបែងចែក។ ដូច្នេះ ឧបករណ៍នេះអាចល្អប្រសិនបើអ្នកគ្រាន់តែសរសេរទៅកាន់មូលដ្ឋានទិន្នន័យនេះហើយកម្រអានពីវា។ ហើយនៅទីនេះវាជាការសមហេតុផលក្នុងការប្រើ Cassandra ជាកន្លែងផ្ទុក "ត្រជាក់" ។ នោះគឺជាកន្លែងដែលអាចទុកចិត្តបានរយៈពេលវែងដើម្បីរក្សាទុកទិន្នន័យប្រវត្តិសាស្ត្រដ៏ច្រើនដែលកម្រត្រូវការ ប៉ុន្តែអាចទាញយកមកវិញបានប្រសិនបើចាំបាច់។ ទោះយ៉ាងណាក៏ដោយ សម្រាប់ជាប្រយោជន៍នៃភាពពេញលេញ យើងនឹងសាកល្បងវាផងដែរ។ ប៉ុន្តែដូចដែលខ្ញុំបាននិយាយមុននេះ វាមិនមានបំណងប្រាថ្នាក្នុងការសរសេរកូដឡើងវិញយ៉ាងសកម្មសម្រាប់ដំណោះស្រាយមូលដ្ឋានទិន្នន័យដែលបានជ្រើសរើសទេ ដូច្នេះយើងនឹងសាកល្បងវាក្នុងកម្រិតខ្លះ - ដោយមិនកែប្រែរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យទៅនឹងលក្ខណៈជាក់លាក់របស់ Cassandra ។

Prometheus

ដោយមានការចង់ដឹងចង់ឃើញ យើងបានសម្រេចចិត្តសាកល្បងដំណើរការនៃការផ្ទុក Prometheus ដើម្បីស្វែងយល់ថាតើយើងលឿន ឬយឺតជាងដំណោះស្រាយបច្ចុប្បន្ន និងប៉ុន្មាន។

វិធីសាស្រ្តសាកល្បង និងលទ្ធផល

ដូច្នេះ យើងបានសាកល្បងមូលដ្ឋានទិន្នន័យចំនួន 5 ក្នុងការកំណត់រចនាសម្ព័ន្ធ 6 ខាងក្រោម៖ ClickHouse (1 node), ClickHouse (តារាងចែកចាយសម្រាប់ 3 nodes), InfluxDB, Mysql 8, Cassandra (3 nodes) និង Prometheus ។ ផែនការសាកល្បងមានដូចខាងក្រោម៖

1. ផ្ទុកឡើងទិន្នន័យប្រវត្តិសាស្រ្តសម្រាប់មួយសប្តាហ៍ (840 លានតម្លៃក្នុងមួយថ្ងៃ; 208 ពាន់ម៉ែត្រ);
2. យើងបង្កើតការផ្ទុកថត (របៀបផ្ទុក 6 ត្រូវបានពិចារណាសូមមើលខាងក្រោម);
3. ស្របជាមួយនឹងការថត យើងធ្វើការជ្រើសរើសជាទៀងទាត់ ដោយត្រាប់តាមសំណើរបស់អ្នកប្រើដែលធ្វើការជាមួយគំនូសតាង។ ដើម្បី​កុំ​ឱ្យ​រឿង​ស្មុគស្មាញ​ខ្លាំង​ពេក យើង​បាន​ជ្រើសរើស​ទិន្នន័យ​សម្រាប់​ម៉ែត្រ​ចំនួន 10 (នោះ​ជា​ចំនួន​ប៉ុន្មាន​នៅ​លើ​ក្រាហ្វ CPU) សម្រាប់​មួយ​សប្តាហ៍។

យើងផ្ទុកដោយត្រាប់តាមឥរិយាបថរបស់ភ្នាក់ងារត្រួតពិនិត្យរបស់យើង ដែលផ្ញើតម្លៃទៅម៉ែត្រនីមួយៗរៀងរាល់ 15 វិនាទី។ ទន្ទឹមនឹងនេះដែរយើងចាប់អារម្មណ៍លើភាពខុសប្លែកគ្នា:

• ចំនួនសរុបនៃម៉ែត្រដែលទិន្នន័យត្រូវបានសរសេរ;
• ចន្លោះពេលសម្រាប់ការផ្ញើតម្លៃទៅមួយម៉ែត្រ;
• ទំហំបាច់។

អំពីទំហំបាច់។ ដោយសារវាមិនត្រូវបានផ្តល់អនុសាសន៍ឱ្យផ្ទុកស្ទើរតែទាំងអស់នៃមូលដ្ឋានទិន្នន័យពិសោធន៍របស់យើងជាមួយនឹងការបញ្ចូលតែមួយ យើងនឹងត្រូវការការបញ្ជូនតដែលប្រមូលម៉ែត្រដែលចូលមក ហើយដាក់ពួកវាជាក្រុម ហើយសរសេរពួកវាទៅក្នុងមូលដ្ឋានទិន្នន័យជាការបញ្ចូលជាបាច់។

ដូចគ្នានេះផងដែរ ដើម្បីយល់កាន់តែច្បាស់អំពីរបៀបបកស្រាយទិន្នន័យដែលទទួលបាន សូមស្រមៃថាយើងមិនមែនគ្រាន់តែផ្ញើម៉ែត្រមួយចំនួនប៉ុណ្ណោះទេ ប៉ុន្តែម៉ែត្រត្រូវបានរៀបចំទៅក្នុងម៉ាស៊ីនមេ - 125 ម៉ែត្រក្នុងមួយម៉ាស៊ីនមេ។ នៅទីនេះម៉ាស៊ីនមេគឺគ្រាន់តែជាអង្គភាពនិម្មិត - គ្រាន់តែយល់ថាឧទាហរណ៍ 10000 ម៉ែត្រត្រូវគ្នានឹងម៉ាស៊ីនមេប្រហែល 80 ។

ហើយនៅទីនេះ ដោយគិតដល់ចំណុចទាំងអស់នេះ គឺជារបៀបផ្ទុកទិន្នន័យចំនួន 6 របស់យើង៖

មានពីរចំណុចនៅទីនេះ។ ទីមួយសម្រាប់ Cassandra ទំហំបាច់ទាំងនេះបានប្រែទៅជាធំពេក នៅទីនោះយើងបានប្រើតម្លៃ 50 ឬ 100។ ហើយទីពីរចាប់តាំងពី Prometheus ធ្វើការយ៉ាងតឹងរ៉ឹងនៅក្នុងរបៀបទាញ ពោលគឺឧ។ វាខ្លួនវាទៅ និងប្រមូលទិន្នន័យពីប្រភពម៉ែត្រ (និងសូម្បីតែផ្លូវរុញ ទោះបីជាឈ្មោះមិនផ្លាស់ប្តូរស្ថានភាពជាមូលដ្ឋានក៏ដោយ) បន្ទុកដែលត្រូវគ្នាត្រូវបានអនុវត្តដោយប្រើបន្សំនៃការកំណត់រចនាសម្ព័ន្ធឋិតិវន្ត។

លទ្ធផលតេស្តមានដូចខាងក្រោម៖

អ្វីដែលគួរកត់សម្គាល់៖ គំរូលឿនអស្ចារ្យពី Prometheus គំរូយឺតយ៉ាវពី Cassandra គំរូយឺតដែលមិនអាចទទួលយកបានពី InfluxDB; បើនិយាយពីល្បឿនថត ClickHouse បានឈ្នះគ្រប់គ្នា ហើយ Prometheus មិនចូលរួមក្នុងការប្រកួតប្រជែងនោះទេ ព្រោះវាបង្កើតការបញ្ចូលដោយខ្លួនឯង ហើយយើងមិនវាស់វែងអ្វីទាំងអស់។

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

ប្រភព: www.habr.com