គឺជាប្រព័ន្ធគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ columnar ប្រភពបើកចំហសម្រាប់ដំណើរការសំណួរវិភាគតាមអ៊ីនធឺណិត (OLAP) ដែលបង្កើតឡើងដោយ Yandex ។ វាត្រូវបានប្រើដោយ Yandex, CloudFlare, VK.com, Badoo និងសេវាកម្មផ្សេងទៀតនៅជុំវិញពិភពលោកដើម្បីរក្សាទុកទិន្នន័យដ៏ច្រើនពិតប្រាកដ (បញ្ចូលរាប់ពាន់ជួរក្នុងមួយវិនាទី ឬ petabytes នៃទិន្នន័យដែលផ្ទុកនៅលើថាស)។
នៅក្នុង DBMS "ខ្សែអក្សរ" ធម្មតាដែលជាឧទាហរណ៍ MySQL, Postgres, MS SQL Server ទិន្នន័យត្រូវបានរក្សាទុកតាមលំដាប់ដូចខាងក្រោមៈ
ក្នុងករណីនេះ តម្លៃដែលទាក់ទងនឹងជួរដេកមួយត្រូវបានរក្សាទុកនៅក្បែរនោះ។ នៅក្នុង columnar DBMSs តម្លៃពីជួរឈរផ្សេងគ្នាត្រូវបានរក្សាទុកដោយឡែកពីគ្នា ហើយទិន្នន័យពីជួរឈរមួយត្រូវបានរក្សាទុកជាមួយគ្នា៖
ឧទាហរណ៍នៃ columnar DBMSs គឺ Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+។
ក្រុមហ៊ុនបញ្ជូនសំបុត្រ បានចាប់ផ្តើមប្រើប្រាស់ Clickhouse ក្នុងឆ្នាំ 2018 សម្រាប់ការរាយការណ៍ ហើយមានការចាប់អារម្មណ៍យ៉ាងខ្លាំងជាមួយនឹងភាពសាមញ្ញ សមត្ថភាពធ្វើមាត្រដ្ឋាន ការគាំទ្រ SQL និងល្បឿនរបស់វា។ ល្បឿននៃ DBMS នេះមានព្រំប្រទល់នឹងវេទមន្ត។
បន្ធូរបន្ថយ
Clickhouse ត្រូវបានដំឡើងនៅលើ Ubuntu ជាមួយនឹងពាក្យបញ្ជាតែមួយ។ ប្រសិនបើអ្នកស្គាល់ SQL អ្នកអាចចាប់ផ្តើមប្រើ Clickhouse ភ្លាមៗសម្រាប់តម្រូវការរបស់អ្នក។ ទោះយ៉ាងណាក៏ដោយនេះមិនមានន័យថាអ្នកអាចធ្វើ "បង្ហាញតារាងបង្កើត" នៅក្នុង MySQL ហើយចម្លង SQL នៅក្នុង Clickhouse នោះទេ។
បើប្រៀបធៀបទៅនឹង MySQL មានភាពខុសគ្នានៃប្រភេទទិន្នន័យសំខាន់ៗនៅក្នុងនិយមន័យតារាងតារាង ដូច្នេះអ្នកនឹងនៅតែត្រូវការពេលវេលាខ្លះដើម្បីផ្លាស់ប្តូរនិយមន័យតារាងតារាង និងរៀនម៉ាស៊ីនតារាងដើម្បីទទួលបានផាសុកភាព។
Clickhouse ដំណើរការល្អដោយគ្មានកម្មវិធីបន្ថែមណាមួយ ប៉ុន្តែប្រសិនបើអ្នកចង់ប្រើការចម្លង អ្នកនឹងត្រូវដំឡើង ZooKeeper ។ ការវិភាគការអនុវត្តសំណួរបង្ហាញពីលទ្ធផលដ៏ល្អ - តារាងប្រព័ន្ធមានព័ត៌មានទាំងអស់ ហើយទិន្នន័យទាំងអស់អាចទាញយកមកវិញដោយប្រើ SQL ចាស់ និងគួរឱ្យធុញ។
ផលិតភាព
- ការប្រៀបធៀប Clickhouse ជាមួយ Vertica និង MySQL លើការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ៖ រន្ធពីរ Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; RAM 128 GiB; md RAID-5 នៅលើ 8 6TB SATA HDD, ext4.
- ការប្រៀបធៀប Clickhouse ជាមួយ Amazon RedShift cloud storage ។
- សម្រង់ប្លុក :
មូលដ្ឋានទិន្នន័យ ClickHouse មានការរចនាដ៏សាមញ្ញបំផុត - ថ្នាំងទាំងអស់នៅក្នុងចង្កោមមានមុខងារដូចគ្នា ហើយប្រើតែ ZooKeeper សម្រាប់ការសម្របសម្រួលប៉ុណ្ណោះ។ យើងបានសាងសង់ចង្កោមតូចមួយនៃថ្នាំងជាច្រើន និងធ្វើការធ្វើតេស្ត ក្នុងអំឡុងពេលនោះយើងបានរកឃើញថាប្រព័ន្ធមានដំណើរការគួរឱ្យចាប់អារម្មណ៍ ដែលត្រូវនឹងគុណសម្បត្តិដែលបានចែងនៅក្នុងការវិភាគ DBMS benchmarks ។ យើងបានសម្រេចចិត្តពិនិត្យមើលយ៉ាងដិតដល់នូវគំនិតនៅពីក្រោយ ClickHouse ។ ឧបសគ្គទីមួយក្នុងការស្រាវជ្រាវគឺការខ្វះខាតឧបករណ៍ និងសហគមន៍ ClickHouse តូច ដូច្នេះហើយយើងបានស្វែងយល់ពីការរចនានៃ DBMS នេះដើម្បីយល់ពីរបៀបដែលវាដំណើរការ។
ClickHouse មិនគាំទ្រការទទួលទិន្នន័យដោយផ្ទាល់ពី Kafka ព្រោះវាគ្រាន់តែជាមូលដ្ឋានទិន្នន័យ ដូច្នេះយើងបានសរសេរសេវាកម្មអាដាប់ទ័រផ្ទាល់ខ្លួនរបស់យើងនៅក្នុង Go ។ វាអានសារដែលបានអ៊ិនកូដ Cap'n Proto ពី Kafka បំប្លែងពួកវាទៅជា TSV ហើយបញ្ចូលវាទៅក្នុង ClickHouse ជាបាច់តាមរយៈចំណុចប្រទាក់ HTTP ។ ក្រោយមកយើងបានសរសេរសេវាកម្មនេះឡើងវិញដើម្បីប្រើបណ្ណាល័យ Go ដោយភ្ជាប់ជាមួយចំណុចប្រទាក់ផ្ទាល់ខ្លួនរបស់ ClickHouse ដើម្បីកែលម្អដំណើរការ។ នៅពេលវាយតម្លៃការអនុវត្តនៃការទទួលកញ្ចប់ព័ត៌មាន យើងបានរកឃើញរឿងសំខាន់មួយ - វាប្រែថាសម្រាប់ ClickHouse ដំណើរការនេះពឹងផ្អែកយ៉ាងខ្លាំងទៅលើទំហំនៃកញ្ចប់ព័ត៌មាន ពោលគឺចំនួនជួរដែលបញ្ចូលក្នុងពេលដំណាលគ្នា។ ដើម្បីយល់ពីមូលហេតុដែលវាកើតឡើង យើងបានមើលពីរបៀបដែល ClickHouse រក្សាទុកទិន្នន័យ។
ម៉ាស៊ីនសំខាន់ ឬជាក្រុមគ្រួសារនៃម៉ាស៊ីនតារាង ដែលប្រើដោយ ClickHouse ដើម្បីរក្សាទុកទិន្នន័យគឺ MergeTree ។ ម៉ាស៊ីននេះមានគំនិតស្រដៀងទៅនឹងក្បួនដោះស្រាយ LSM ដែលប្រើក្នុង Google BigTable ឬ Apache Cassandra ប៉ុន្តែជៀសវាងការបង្កើតតារាងអង្គចងចាំកម្រិតមធ្យម ហើយសរសេរទិន្នន័យដោយផ្ទាល់ទៅថាស។ នេះផ្តល់ឱ្យវានូវដំណើរការសរសេរដ៏ល្អឥតខ្ចោះ ដោយហេតុថាកញ្ចប់ព័ត៌មានដែលបានបញ្ចូលនីមួយៗត្រូវបានតម្រៀបដោយសោចម្បង បង្ហាប់ និងសរសេរទៅថាសដើម្បីបង្កើតជាផ្នែកមួយ។
អវត្ដមាននៃតារាងអង្គចងចាំ ឬគំនិតណាមួយនៃ "ភាពស្រស់" នៃទិន្នន័យក៏មានន័យថាពួកវាអាចត្រូវបានបន្ថែមតែប៉ុណ្ណោះ ប្រព័ន្ធមិនគាំទ្រការផ្លាស់ប្តូរ ឬលុបទេ។ បច្ចុប្បន្ន មធ្យោបាយតែមួយគត់ដើម្បីលុបទិន្នន័យគឺត្រូវលុបវាតាមខែប្រតិទិន ចាប់តាំងពីផ្នែកមិនដែលឆ្លងកាត់ព្រំដែនមួយខែ។ ក្រុមការងារ ClickHouse កំពុងធ្វើការយ៉ាងសកម្មដើម្បីធ្វើឱ្យមុខងារនេះអាចប្ដូរតាមបំណងបាន។ ម្យ៉ាងវិញទៀត វាធ្វើឱ្យការសរសេរ និងបញ្ចូលផ្នែកដោយមិនមានការឈ្លោះប្រកែកគ្នា ដូច្នេះទទួលបានមាត្រដ្ឋានឆ្លងកាត់តាមជួរជាមួយនឹងចំនួននៃការបញ្ចូលក្នុងពេលដំណាលគ្នា រហូតដល់ I/O ឬការតិត្ថិភាពស្នូលកើតឡើង។
ទោះជាយ៉ាងណាក៏ដោយ នេះក៏មានន័យថាប្រព័ន្ធនេះមិនស័ក្តិសមសម្រាប់កញ្ចប់ព័ត៌មានតូចៗទេ ដូច្នេះសេវាកម្ម Kafka និងឧបករណ៍បញ្ចូលត្រូវបានប្រើប្រាស់សម្រាប់ការបណ្ដោះអាសន្ន។ បន្ទាប់មក ClickHouse នៅផ្ទៃខាងក្រោយបន្តអនុវត្តការបញ្ចូលផ្នែកជាបន្តបន្ទាប់ ដូច្នេះព័ត៌មានតូចៗជាច្រើននឹងត្រូវបានបញ្ចូលគ្នា និងកត់ត្រាច្រើនដង ដូច្នេះវាបង្កើនអាំងតង់ស៊ីតេនៃការថត។ ទោះជាយ៉ាងណាក៏ដោយ ផ្នែកដែលមិនបានភ្ជាប់ច្រើនពេកនឹងបណ្តាលឱ្យមានការបិទភ្ជាប់យ៉ាងខ្លាំងក្លា ដរាបណាការបញ្ចូលចូលគ្នានៅតែបន្ត។ យើងបានរកឃើញថាការសម្របសម្រួលដ៏ល្អបំផុតរវាងការបញ្ចូលក្នុងពេលវេលាជាក់ស្តែង និងការអនុវត្តការបញ្ចូលគឺការបញ្ចូលចំនួនកំណត់នៃការបញ្ចូលក្នុងមួយវិនាទីទៅក្នុងតារាង។
គន្លឹះនៃការអនុវត្តការអានតារាងគឺការធ្វើលិបិក្រម និងទីតាំងនៃទិន្នន័យនៅលើថាស។ មិនថាដំណើរការលឿនប៉ុណ្ណានោះទេ នៅពេលដែលម៉ាស៊ីនត្រូវការស្កេនទិន្នន័យ terabytes ពីឌីស ហើយប្រើតែផ្នែកមួយប៉ុណ្ណោះ វានឹងត្រូវការពេលវេលា។ ClickHouse គឺជាឃ្លាំងផ្ទុកជួរឈរ ដូច្នេះផ្នែកនីមួយៗមានឯកសារសម្រាប់ជួរឈរនីមួយៗ (ជួរឈរ) ដែលមានតម្លៃតម្រៀបសម្រាប់ជួរនីមួយៗ។ វិធីនេះ ជួរឈរទាំងមូលដែលបាត់ពីសំណួរអាចត្រូវបានរំលងជាមុនសិន ហើយបន្ទាប់មកក្រឡាជាច្រើនអាចត្រូវបានដំណើរការស្របគ្នាជាមួយនឹងការប្រតិបត្តិតាមវ៉ិចទ័រ។ ដើម្បីជៀសវាងការស្កេនពេញលេញ ផ្នែកនីមួយៗមានឯកសារលិបិក្រមតូចមួយ។
ដោយសារជួរឈរទាំងអស់ត្រូវបានតម្រៀបដោយ "កូនសោចម្បង" ឯកសារលិបិក្រមមានតែស្លាក (ជួរដែលបានចាប់យក) នៃជួរទី Nth នីមួយៗ ដើម្បីអាចរក្សាពួកវាក្នុងសតិបានសូម្បីតែតារាងធំខ្លាំងក៏ដោយ។ ជាឧទាហរណ៍ អ្នកអាចកំណត់ការកំណត់លំនាំដើមទៅ "សម្គាល់រាល់ជួរទី 8192" បន្ទាប់មក "តិចជាង" ការធ្វើលិបិក្រមនៃតារាងដែលមាន 1 ពាន់ពាន់លាន។ បន្ទាត់ដែលសមនឹងអង្គចងចាំយ៉ាងងាយស្រួលនឹងយកត្រឹមតែ 122 តួអក្សរប៉ុណ្ណោះ។
ការអភិវឌ្ឍប្រព័ន្ធ
ការអភិវឌ្ឍន៍ និងការកែលម្អ Clickhouse អាចត្រូវបានតាមដាននៅ ហើយត្រូវប្រាកដថាដំណើរការនៃការ "ធំឡើង" កើតឡើងក្នុងល្បឿនដ៏គួរឱ្យចាប់អារម្មណ៍មួយ។
ប្រជាប្រិយភាព
ប្រជាប្រិយភាពរបស់ Clickhouse ហាក់ដូចជាកំពុងកើនឡើងជាលំដាប់ ជាពិសេសនៅក្នុងសហគមន៍ដែលនិយាយភាសារុស្សី។ សន្និសីទ High load 2018 កាលពីឆ្នាំមុន (ទីក្រុងម៉ូស្គូ ថ្ងៃទី 8-9 ខែវិច្ឆិកា ឆ្នាំ 2018) បានបង្ហាញថាសត្វចម្លែកដូចជា vk.com និង Badoo ប្រើប្រាស់ Clickhouse ដែលពួកគេបញ្ចូលទិន្នន័យ (ឧទាហរណ៍ កំណត់ហេតុ) ពីម៉ាស៊ីនមេរាប់ម៉ឺនក្នុងពេលដំណាលគ្នា។ នៅក្នុងវីដេអូ ៤០ នាទី។ . ឆាប់ៗនេះ យើងនឹងបង្ហោះប្រតិចារឹកនៅលើ Habr ដើម្បីងាយស្រួលក្នុងការធ្វើការជាមួយសម្ភារៈ។
កម្មវិធី
បន្ទាប់ពីចំណាយពេលស្រាវជ្រាវខ្លះ ខ្ញុំគិតថាមានផ្នែកដែល ClickHouse អាចមានប្រយោជន៍ ឬអាចជំនួសទាំងស្រុងនូវដំណោះស្រាយបែបប្រពៃណី និងពេញនិយមផ្សេងទៀតដូចជា MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot និង ឌុយអ៊ីដ។ ខាងក្រោមនេះពិពណ៌នាអំពីព័ត៌មានលម្អិតនៃការប្រើប្រាស់ ClickHouse ដើម្បីធ្វើទំនើបកម្ម ឬជំនួសទាំងស្រុងនូវ DBMS ខាងលើ។
ពង្រីកសមត្ថភាពរបស់ MySQL និង PostgreSQL
ថ្មីៗនេះ យើងបានជំនួសផ្នែកខ្លះនៃ MySQL ជាមួយ ClickHouse សម្រាប់វេទិកាព្រឹត្តិបត្ររបស់យើង។ . បញ្ហាគឺថា MySQL ដោយសារតែការរចនាមិនល្អ កំពុងកត់ត្រារាល់អ៊ីមែលដែលបានផ្ញើ និងរាល់តំណភ្ជាប់នៅក្នុងអ៊ីមែលនោះជាមួយនឹងសញ្ញា base64 បង្កើតតារាង MySQL ដ៏ធំមួយ (email_stats) ។ បន្ទាប់ពីផ្ញើអ៊ីមែលត្រឹមតែ 10 លានទៅកាន់អតិថិជនសេវាកម្ម តារាងនេះបានកាន់កាប់ទំហំឯកសារ 150 GB ហើយ MySQL ចាប់ផ្តើម "ល្ងង់" លើសំណួរសាមញ្ញ។ ដើម្បីដោះស្រាយបញ្ហាទំហំឯកសារ យើងបានប្រើប្រាស់ការបង្ហាប់តារាង InnoDB ដោយជោគជ័យ ដែលកាត់បន្ថយវាដោយកត្តា 4។ ទោះជាយ៉ាងណាក៏ដោយ វានៅតែមិនសមហេតុផលក្នុងការរក្សាទុកអ៊ីមែលច្រើនជាង 20-30 លាននៅក្នុង MySQL គ្រាន់តែសម្រាប់ជាប្រយោជន៍នៃការអានប្រវត្តិសាស្រ្ត ចាប់តាំងពីសំណួរសាមញ្ញណាមួយដែលសម្រាប់ហេតុផលមួយចំនួនចាំបាច់ត្រូវធ្វើការស្កេនពេញលទ្ធផលក្នុងការផ្លាស់ប្តូរ និងខ្ញុំជាច្រើន ការផ្ទុក /O យោងទៅតាមដែលយើងបានទទួលការព្រមានជាទៀងទាត់ពី Zabbix ។
Clickhouse ប្រើក្បួនដោះស្រាយការបង្ហាប់ពីរដែលកាត់បន្ថយបរិមាណទិន្នន័យប្រហែល ប៉ុន្តែនៅក្នុងករណីពិសេសនេះ ទិន្នន័យពិសេស "អាចបង្ហាប់បាន"។
ការជំនួស ELK
ផ្អែកលើបទពិសោធន៍ផ្ទាល់ខ្លួនរបស់ខ្ញុំ ជង់ ELK (ElasticSearch, Logstash និង Kibana នៅក្នុងករណីពិសេសនេះ ElasticSearch) ត្រូវការធនធានច្រើនដើម្បីដំណើរការ ជាងការចាំបាច់ដើម្បីរក្សាទុកកំណត់ហេតុ។ ElasticSearch គឺជាម៉ាស៊ីនដ៏អស្ចារ្យមួយ ប្រសិនបើអ្នកត្រូវការការស្វែងរកកំណត់ហេតុអត្ថបទពេញលេញល្អ (ដែលខ្ញុំគិតថាអ្នកពិតជាត្រូវការទេ) ប៉ុន្តែខ្ញុំឆ្ងល់ថាហេតុអ្វីបានជាវាបានក្លាយជាម៉ាស៊ីនកត់ត្រាស្តង់ដារជាក់ស្តែង។ ដំណើរការប្រើប្រាស់របស់វារួមបញ្ចូលគ្នាជាមួយ Logstash បានផ្ដល់ឱ្យយើងនូវបញ្ហាសូម្បីតែនៅក្រោមបន្ទុកស្រាល ហើយតម្រូវឱ្យយើងបន្ថែម RAM និងទំហំថាសកាន់តែច្រើន។ ក្នុងនាមជាមូលដ្ឋានទិន្នន័យ Clickhouse គឺប្រសើរជាង ElasticSearch សម្រាប់ហេតុផលដូចខាងក្រោម:
- ការគាំទ្រគ្រាមភាសា SQL;
- កម្រិតល្អបំផុតនៃការបង្ហាប់ទិន្នន័យដែលបានរក្សាទុក;
- ការគាំទ្រសម្រាប់ការស្វែងរកកន្សោមធម្មតា Regex ជំនួសឱ្យការស្វែងរកអត្ថបទពេញលេញ។
- ការធ្វើឱ្យប្រសើរឡើងនូវការកំណត់ពេលសំណួរនិងការអនុវត្តរួមខ្ពស់ជាងមុន។
បច្ចុប្បន្ននេះបញ្ហាដ៏ធំបំផុតដែលកើតឡើងនៅពេលប្រៀបធៀប ClickHouse ជាមួយ ELK គឺកង្វះដំណោះស្រាយសម្រាប់ការផ្ទុកឡើងកំណត់ហេតុ ក៏ដូចជាកង្វះឯកសារ និងការបង្រៀនលើប្រធានបទ។ លើសពីនេះទៅទៀត អ្នកប្រើប្រាស់ម្នាក់ៗអាចកំណត់រចនាសម្ព័ន្ធ ELK ដោយប្រើសៀវភៅដៃ Digital Ocean ដែលមានសារៈសំខាន់ខ្លាំងណាស់សម្រាប់ការអនុវត្តយ៉ាងឆាប់រហ័សនៃបច្ចេកវិទ្យាបែបនេះ។ មានម៉ាស៊ីនមូលដ្ឋានទិន្នន័យ ប៉ុន្តែមិនទាន់មាន Filebeat សម្រាប់ ClickHouse នៅឡើយទេ។ បាទ វានៅទីនោះ និងប្រព័ន្ធសម្រាប់ធ្វើការជាមួយកំណត់ហេតុ មានឧបករណ៍មួយ។ ដើម្បីបញ្ចូលទិន្នន័យកំណត់ហេតុទៅក្នុង ClickHouse ប៉ុន្តែអ្វីៗទាំងអស់នេះត្រូវការពេលវេលាបន្ថែមទៀត។ ទោះជាយ៉ាងណាក៏ដោយ ClickHouse នៅតែជាអ្នកដឹកនាំដោយសារតែភាពសាមញ្ញរបស់វា ដូច្នេះសូម្បីតែអ្នកចាប់ផ្តើមដំបូងក៏អាចដំឡើងវាបានយ៉ាងងាយស្រួល ហើយចាប់ផ្តើមប្រើវាឱ្យពេញលេញក្នុងរយៈពេលត្រឹមតែ 10 នាទីប៉ុណ្ណោះ។
ដោយចូលចិត្តដំណោះស្រាយតិចតួចបំផុត ខ្ញុំបានព្យាយាមប្រើ FluentBit ដែលជាឧបករណ៍សម្រាប់ដឹកជញ្ជូនកំណត់ហេតុដែលមានអង្គចងចាំតិចតួចបំផុត រួមជាមួយនឹង ClickHouse ខណៈពេលដែលព្យាយាមជៀសវាងការប្រើ Kafka ។ ទោះយ៉ាងណាក៏ដោយ ភាពមិនឆបគ្នាតិចតួចចាំបាច់ត្រូវដោះស្រាយ ដូចជា មុនពេលនេះអាចត្រូវបានធ្វើដោយគ្មានស្រទាប់ប្រូកស៊ីដែលបម្លែងទិន្នន័យពី FluentBit ទៅ ClickHouse ។
ជាជម្រើសមួយ Kibana អាចត្រូវបានប្រើជាកម្មវិធីខាងក្រោយ ClickHouse . តាមអ្វីដែលខ្ញុំយល់ វាអាចធ្វើឱ្យមានបញ្ហាដំណើរការនៅពេលបង្ហាញចំណុចទិន្នន័យយ៉ាងច្រើន ជាពិសេសជាមួយនឹងកំណែចាស់របស់ Grafana។ យើងមិនទាន់បានសាកល្បងវានៅ Qwintry នៅឡើយទេ ប៉ុន្តែការត្អូញត្អែរអំពីរឿងនេះលេចឡើងម្តងម្កាលនៅលើបណ្តាញជំនួយ ClickHouse នៅលើ Telegram ។
ការជំនួស Google Big Query និង Amazon RedShift (ដំណោះស្រាយសម្រាប់ក្រុមហ៊ុនធំ)
ករណីប្រើប្រាស់ដ៏ល្អសម្រាប់ BigQuery គឺត្រូវផ្ទុកទិន្នន័យ JSON 1 TB ហើយដំណើរការសំណួរវិភាគលើវា។ Big Query គឺជាផលិតផលដ៏ល្អដែលសមត្ថភាពធ្វើមាត្រដ្ឋានមិនអាចនិយាយលើស។ នេះគឺជាកម្មវិធីដែលស្មុគស្មាញជាង ClickHouse ដែលដំណើរការលើចង្កោមខាងក្នុង ប៉ុន្តែតាមទស្សនៈរបស់អតិថិជនវាមានច្រើនដូចគ្នាជាមួយ ClickHouse ។ BigQuery អាចឡើងថ្លៃបានយ៉ាងឆាប់រហ័សនៅពេលដែលអ្នកចាប់ផ្តើមបង់ប្រាក់ក្នុងមួយ SELECT ដូច្នេះវាគឺជាដំណោះស្រាយ SaaS ពិតប្រាកដជាមួយនឹងគុណសម្បត្តិ និងគុណវិបត្តិរបស់វា។
ClickHouse គឺជាជម្រើសដ៏ល្អបំផុតនៅពេលដែលអ្នកកំពុងដំណើរការសំណួរដែលមានតម្លៃថ្លៃក្នុងការគណនាជាច្រើន។ សំណួរ SELECT កាន់តែច្រើនដែលអ្នកដំណើរការជារៀងរាល់ថ្ងៃ វាកាន់តែសមហេតុផលក្នុងការជំនួស Big Query ជាមួយ ClickHouse ពីព្រោះការជំនួសបែបនេះអាចសន្សំប្រាក់អ្នកបានរាប់ពាន់ដុល្លារ នៅពេលដែលវាមកដល់ទិន្នន័យជាច្រើន terabyte កំពុងដំណើរការ។ វាមិនអនុវត្តចំពោះទិន្នន័យដែលបានរក្សាទុកទេ ដែលមានតម្លៃថោកណាស់ក្នុងការដំណើរការក្នុង Big Query។
នៅក្នុងអត្ថបទរបស់ Altinity សហស្ថាបនិក Alexander Zaitsev និយាយអំពីអត្ថប្រយោជន៍នៃការធ្វើចំណាកស្រុក DBMS បែបនេះ។
ការជំនួស TimescaleDB
TimescaleDB គឺជាផ្នែកបន្ថែម PostgreSQL ដែលបង្កើនប្រសិទ្ធភាពការធ្វើការជាមួយស៊េរីពេលវេលានៅក្នុងមូលដ្ឋានទិន្នន័យធម្មតា (, ).
ទោះបីជា ClickHouse មិនមែនជាដៃគូប្រកួតប្រជែងដ៏ធ្ងន់ធ្ងរនៅក្នុងទីផ្សារពិសេសនៃស៊េរីពេលវេលា ប៉ុន្តែរចនាសម្ព័ន្ធជួរឈរ និងដំណើរការសំណួរវ៉ិចទ័រ វាលឿនជាង TimescaleDB ក្នុងករណីភាគច្រើននៃដំណើរការសំណួរវិភាគ។ ក្នុងពេលជាមួយគ្នានេះ ការអនុវត្តនៃការទទួលទិន្នន័យបណ្តុំពី ClickHouse គឺខ្ពស់ជាងប្រហែល 3 ដង ហើយវាក៏ប្រើប្រាស់ទំហំថាសតិចជាង 20 ដងផងដែរ ដែលពិតជាមានសារៈសំខាន់សម្រាប់ដំណើរការទិន្នន័យប្រវត្តិសាស្រ្តដែលមានបរិមាណច្រើន៖ .
មិនដូច ClickHouse មធ្យោបាយតែមួយគត់ដើម្បីរក្សាទុកទំហំថាសមួយចំនួននៅក្នុង TimescaleDB គឺត្រូវប្រើ ZFS ឬប្រព័ន្ធឯកសារស្រដៀងគ្នា។
ការអាប់ដេតនាពេលខាងមុខចំពោះ ClickHouse ទំនងជានឹងណែនាំការបង្ហាប់ដីសណ្ត ដែលនឹងធ្វើឱ្យវាកាន់តែសមរម្យសម្រាប់ដំណើរការ និងរក្សាទុកទិន្នន័យស៊េរីពេលវេលា។ TimescaleDB អាចជាជម្រើសល្អជាង ClickHouse ទទេនៅក្នុងករណីដូចខាងក្រោម៖
- ការដំឡើងតូចជាមួយ RAM តិចតួចណាស់ (<3 GB);
- មួយចំនួនធំនៃ INSERTs តូចដែលអ្នកមិនចង់ផ្ទុកទៅជាបំណែកធំ;
- ភាពស៊ីសង្វាក់គ្នា ភាពស្មើគ្នា និងតម្រូវការអាស៊ីតកាន់តែប្រសើរ។
- ការគាំទ្រ PostGIS;
- ចូលរួមជាមួយតារាង PostgreSQL ដែលមានស្រាប់ ចាប់តាំងពី Timescale DB គឺសំខាន់ PostgreSQL ។
ការប្រកួតប្រជែងជាមួយប្រព័ន្ធ Hadoop និង MapReduce
Hadoop និងផលិតផល MapReduce ផ្សេងទៀតអាចអនុវត្តការគណនាស្មុគ្រស្មាញជាច្រើន ប៉ុន្តែពួកគេមានទំនោរនឹងដំណើរការជាមួយនឹងភាពយឺតយ៉ាវដ៏ធំ។ ClickHouse ដោះស្រាយបញ្ហានេះដោយដំណើរការទិន្នន័យ terabytes និងបង្កើតលទ្ធផលស្ទើរតែភ្លាមៗ។ ដូច្នេះ ClickHouse មានប្រសិទ្ធភាពជាងក្នុងការអនុវត្តការស្រាវជ្រាវវិភាគអន្តរកម្មលឿន ដែលគួរជាទីចាប់អារម្មណ៍ចំពោះអ្នកវិទ្យាសាស្ត្រទិន្នន័យ។
ការប្រកួតប្រជែងជាមួយ Pinot និង Druid
ដៃគូប្រកួតប្រជែងជិតស្និទ្ធបំផុតរបស់ ClickHouse គឺ columnar ផលិតផលប្រភពបើកចំហដែលអាចធ្វើមាត្រដ្ឋានបានតាមលីនេអ៊ែរ Pinot និង Druid ។ ការងារដ៏ល្អមួយប្រៀបធៀបប្រព័ន្ធទាំងនេះត្រូវបានបោះពុម្ពនៅក្នុងអត្ថបទ ចុះថ្ងៃទី១ ខែកុម្ភៈ ឆ្នាំ២០១៨
អត្ថបទនេះត្រូវការការធ្វើបច្ចុប្បន្នភាព - វានិយាយថា ClickHouse មិនគាំទ្រប្រតិបត្តិការ UPDATE និង DELETE ដែលមិនពិតទាំងស្រុងសម្រាប់កំណែចុងក្រោយបំផុត។
យើងមិនមានបទពិសោធន៍ច្រើនជាមួយមូលដ្ឋានទិន្នន័យទាំងនេះទេ ប៉ុន្តែខ្ញុំពិតជាមិនចូលចិត្តភាពស្មុគស្មាញនៃហេដ្ឋារចនាសម្ព័ន្ធដែលតម្រូវឱ្យដំណើរការ Druid និង Pinot នោះទេ វាជាបណ្តុំនៃផ្នែកផ្លាស់ប្តូរដែលព័ទ្ធជុំវិញដោយ Java នៅគ្រប់ជ្រុងទាំងអស់។
Druid និង Pinot គឺជាគម្រោង Apache incubator ដែលវឌ្ឍនភាពត្រូវបានគ្របដណ្តប់យ៉ាងលម្អិតដោយ Apache នៅលើទំព័រគម្រោង GitHub របស់វា។ Pinot បានបង្ហាញខ្លួននៅក្នុង incubator នៅខែតុលា 2018 ហើយ Druid បានកើតមុន 8 ខែ - នៅក្នុងខែកុម្ភៈ។
ការខ្វះខាតព័ត៌មានអំពីរបៀបដែល AFS ធ្វើការបានលើកឡើងនូវសំណួរមួយចំនួន ហើយប្រហែលជាល្ងង់សម្រាប់ខ្ញុំ។ ខ្ញុំឆ្ងល់ថាតើអ្នកនិពន្ធ Pinot បានកត់សម្គាល់ឃើញថាមូលនិធិ Apache មានភាពអំណោយផលចំពោះ Druid ហើយថាតើអាកប្បកិរិយានេះចំពោះគូប្រជែងបណ្តាលឱ្យមានអារម្មណ៍ច្រណែនដែរឬទេ? តើការអភិវឌ្ឍន៍របស់ Druid នឹងថយចុះទេ ហើយការអភិវឌ្ឍន៍របស់ Pinot កាន់តែលឿន ប្រសិនបើអ្នកគាំទ្ររបស់អតីតស្រាប់តែចាប់អារម្មណ៍លើរឿងក្រោយ?
គុណវិបត្តិនៃ ClickHouse
ភាពមិនពេញវ័យ៖ ជាក់ស្តែង នេះនៅតែមិនមែនជាបច្ចេកវិទ្យាគួរឱ្យធុញ ប៉ុន្តែក្នុងករណីណាក៏ដោយ គ្មានអ្វីដូចនេះត្រូវបានសង្កេតឃើញនៅក្នុង DBMSs ជួរឈរផ្សេងទៀត។
សិលាចារឹកតូចមិនដំណើរការបានល្អក្នុងល្បឿនលឿនទេ៖ សិលាចារឹកត្រូវតែបំបែកទៅជាកំណាត់ធំជាង ព្រោះដំណើរការនៃសិលាចារឹកតូចៗថយចុះតាមសមាមាត្រទៅនឹងចំនួនជួរឈរក្នុងជួរនីមួយៗ។ នេះជារបៀបដែល ClickHouse ផ្ទុកទិន្នន័យនៅលើថាស - ជួរឈរនីមួយៗតំណាងឱ្យ 1 ឯកសារឬច្រើនជាងនេះ ដូច្នេះដើម្បីបញ្ចូលជួរដេក 1 ដែលមាន 100 ជួរឈរ អ្នកត្រូវបើក និងសរសេរយ៉ាងហោចណាស់ 100 ឯកសារ។ នេះជាមូលហេតុដែលការបញ្ចូលបណ្តោះអាសន្នតម្រូវឱ្យមានឈ្មួញកណ្តាល (លុះត្រាតែអតិថិជនខ្លួនវាផ្តល់នូវការផ្អាក) - ជាធម្មតា Kafka ឬប្រព័ន្ធគ្រប់គ្រងជួរមួយចំនួន។ អ្នកក៏អាចប្រើ Buffer table engine ដើម្បីចម្លងទិន្នន័យធំៗទៅក្នុងតារាង MergeTree នៅពេលក្រោយ។
ការភ្ជាប់តារាងត្រូវបានកំណត់ដោយ RAM របស់ម៉ាស៊ីនមេ ប៉ុន្តែយ៉ាងហោចណាស់ពួកគេនៅទីនោះ! ជាឧទាហរណ៍ Druid និង Pinot មិនមានការតភ្ជាប់បែបនេះទាល់តែសោះ ព្រោះវាពិបាកក្នុងការអនុវត្តដោយផ្ទាល់នៅក្នុងប្រព័ន្ធចែកចាយដែលមិនគាំទ្រការផ្លាស់ទីទិន្នន័យធំៗរវាងថ្នាំង។
ការរកឃើញ
យើងមានគម្រោងប្រើប្រាស់ ClickHouse យ៉ាងទូលំទូលាយនៅ Qwintry ក្នុងរយៈពេលប៉ុន្មានឆ្នាំខាងមុខនេះ ដោយសារ DBMS នេះផ្តល់នូវតុល្យភាពនៃការអនុវត្តដ៏ល្អ ការចំណាយទាប ការធ្វើមាត្រដ្ឋាន និងភាពសាមញ្ញ។ ខ្ញុំប្រាកដណាស់ថាវានឹងចាប់ផ្តើមរីករាលដាលយ៉ាងឆាប់រហ័សនៅពេលដែលសហគមន៍ ClickHouse បង្កើតនូវវិធីជាច្រើនទៀតក្នុងការប្រើប្រាស់វាក្នុងការដំឡើងខ្នាតតូចដល់ពាក់កណ្តាល។
ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂
សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, , analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។
Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អានអំពី
ប្រភព: www.habr.com