ការប្រើប្រាស់ ClickHouse ប្រកបដោយប្រសិទ្ធភាព។ Alexey Milovidov (Yandex)

ដោយសារ ClickHouse គឺជាប្រព័ន្ធឯកទេស នៅពេលប្រើវាមានសារៈសំខាន់ណាស់ក្នុងការគិតគូរពីលក្ខណៈពិសេសនៃស្ថាបត្យកម្មរបស់វា។ នៅក្នុងរបាយការណ៍នេះ Alexey នឹងនិយាយអំពីឧទាហរណ៍នៃកំហុសទូទៅនៅពេលប្រើ ClickHouse ដែលអាចនាំឱ្យមានការងារមិនមានប្រសិទ្ធភាព។ ឧទាហរណ៍ជាក់ស្តែងនឹងបង្ហាញពីរបៀបដែលការជ្រើសរើសគ្រោងការណ៍ដំណើរការទិន្នន័យមួយ ឬមួយផ្សេងទៀតអាចផ្លាស់ប្តូរការអនុវត្តតាមលំដាប់លំដោយ។

សួស្តី​អ្នក​ទាំងអស់គ្នា! ខ្ញុំឈ្មោះ Alexey ខ្ញុំបង្កើត ClickHouse ។

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

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

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

ដូច្នេះ តើ​តុងទីន​ប្រភេទ​ណា​ខ្លះ? ភាគច្រើនខ្ញុំនឹងនិយាយអំពីរឿងជាក់ស្តែង។ អ្វីគ្រប់យ៉ាងគឺច្បាស់សម្រាប់មនុស្សគ្រប់គ្នា មនុស្សគ្រប់គ្នាយល់គ្រប់យ៉ាង ហើយអាចរីករាយដែលថាពួកគេឆ្លាត ហើយអ្នកដែលមិនយល់នឹងរៀនអ្វីថ្មី។

ឧទាហរណ៍ដំបូង និងសាមញ្ញបំផុត ដែលជាអកុសលកើតឡើងជាញឹកញាប់ គឺជាការបញ្ចូលមួយចំនួនធំជាមួយនឹងបាច់តូចៗ ពោលគឺចំនួនដ៏ច្រើននៃការបញ្ចូលតូចៗ។

ប្រសិនបើយើងពិចារណាពីរបៀបដែល ClickHouse អនុវត្តការបញ្ចូល នោះអ្នកអាចផ្ញើទិន្នន័យយ៉ាងហោចណាស់មួយតេរ៉ាបៃក្នុងសំណើមួយ។ វាមិនមែនជាបញ្ហាទេ។

ហើយចាំមើលថាតើការសម្តែងធម្មតានឹងទៅជាយ៉ាងណា។ ឧទាហរណ៍យើងមានតារាងពីទិន្នន័យ Yandex.Metrica ។ បុក។ 105 ជួរមួយចំនួន។ 700 បៃមិនត្រូវបានបង្ហាប់។ ហើយ​យើង​នឹង​បញ្ចូល​ក្នុង​វិធី​ដ៏​ល្អ​ក្នុង​បាច់​មួយ​លាន​ជួរ។

យើងបញ្ចូល MergeTree ទៅក្នុងតារាង វាប្រែចេញពាក់កណ្តាលមួយលានជួរក្នុងមួយវិនាទី។ អស្ចារ្យ។ នៅក្នុងតារាងចម្លងវានឹងតូចជាងបន្តិច ប្រហែល 400 ជួរក្នុងមួយវិនាទី។

ហើយប្រសិនបើអ្នកបើកការបញ្ចូលកូរ៉ុម អ្នកទទួលបានតិចជាងបន្តិច ប៉ុន្តែនៅតែដំណើរការសមរម្យ 250 ពាក្យក្នុងមួយវិនាទី។ ការបញ្ចូលកូរ៉ុមគឺជាមុខងារដែលគ្មានឯកសារនៅក្នុង ClickHouse*។

* គិតត្រឹមឆ្នាំ ២០២០ ឯកសាររួចហើយ.

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកធ្វើអាក្រក់? យើងបញ្ចូលជួរមួយទៅក្នុងតារាង MergeTree ហើយទទួលបាន 59 ជួរក្នុងមួយវិនាទី។ នោះយឺតជាង 10 ដង។ នៅក្នុង ReplicatedMergeTree – 000 ជួរក្នុងមួយវិនាទី។ ហើយប្រសិនបើកូរ៉ុមត្រូវបានបើក នោះវាប្រែចេញ 6 បន្ទាត់ក្នុងមួយវិនាទី។ តាម​គំនិត​ខ្ញុំ នេះ​គឺ​ជា​ប្រភេទ​នៃ​ការ​កុហក​ពិត​ប្រាកដ​មួយ​ចំនួន។ តើអ្នកអាចបន្ថយល្បឿនបែបនេះដោយរបៀបណា? ខ្ញុំថែមទាំងបានសរសេរនៅលើអាវយឺតរបស់ខ្ញុំថា ClickHouse មិនគួរបន្ថយល្បឿនទេ។ ប៉ុន្តែយ៉ាងណាក៏ដោយ ពេលខ្លះវាកើតឡើង។

តាមពិតនេះគឺជាចំណុចខ្វះខាតរបស់យើង។ យើង​អាច​ធ្វើ​ឱ្យ​អ្វីៗ​ដំណើរការ​បាន​យ៉ាង​ងាយ ប៉ុន្តែ​យើង​មិន​បាន​ធ្វើ​ទេ។ ហើយ​យើង​មិន​បាន​ធ្វើ​វា​ទេ ព្រោះ​ស្គ្រីប​របស់​យើង​មិន​ត្រូវ​ការ​វា​ទេ។ យើង​មាន​សាច់​ដុំ​រួច​ហើយ។ យើងទើបតែទទួលបានបាច់នៅច្រកចូលរបស់យើង ហើយគ្មានបញ្ហាអ្វីទេ។ យើងបញ្ចូលវាហើយអ្វីៗដំណើរការល្អ។ ប៉ុន្តែជាការពិតណាស់ គ្រប់ប្រភេទនៃសេណារីយ៉ូគឺអាចធ្វើទៅបាន។ ឧទាហរណ៍ នៅពេលដែលអ្នកមាន servers ជាច្រើនដែលទិន្នន័យត្រូវបានបង្កើត។ ហើយពួកគេមិនបញ្ចូលទិន្នន័យញឹកញាប់ទេ ប៉ុន្តែពួកគេនៅតែបញ្ចប់ដោយការបញ្ចូលញឹកញាប់។ ហើយយើងត្រូវជៀសវាងបញ្ហានេះ។

តាមទស្សនៈបច្ចេកទេស ចំណុចគឺថានៅពេលអ្នកបញ្ចូលក្នុង ClickHouse ទិន្នន័យមិនបញ្ចប់នៅក្នុង memtable ណាមួយឡើយ។ យើងមិនមានរចនាសម្ព័ន្ធកំណត់ហេតុពិតប្រាកដ MergeTree ទេ ប៉ុន្តែគ្រាន់តែជា MergeTree ប៉ុណ្ណោះ ព្រោះមិនមានកំណត់ហេតុ ឬ memTable ទេ។ យើងគ្រាន់តែសរសេរទិន្នន័យភ្លាមៗទៅកាន់ប្រព័ន្ធឯកសារ ដោយបានរៀបចំជាជួររួចហើយ។ ហើយប្រសិនបើអ្នកមាន 100 ជួរឈរនោះឯកសារច្រើនជាង 200 នឹងត្រូវសរសេរទៅថតដាច់ដោយឡែកមួយ។ ទាំងអស់នេះគឺស្មុគស្មាញណាស់។

ហើយសំណួរកើតឡើង: "តើធ្វើដូចម្តេចដើម្បីឱ្យវាត្រឹមត្រូវ?" ប្រសិនបើស្ថានភាពបែបនេះអ្នកនៅតែត្រូវការកត់ត្រាទិន្នន័យនៅក្នុង ClickHouse ។

វិធីសាស្រ្ត 1. នេះគឺជាវិធីងាយស្រួលបំផុត។ ប្រើប្រភេទនៃជួរដែលបានចែកចាយមួយចំនួន។ ឧទាហរណ៍ Kafka ។ អ្នកគ្រាន់តែទាញយកទិន្នន័យពី Kafka ហើយបាច់វាម្តងក្នុងមួយវិនាទី។ ហើយអ្វីគ្រប់យ៉ាងនឹងល្អ អ្នកកត់ត្រា អ្វីគ្រប់យ៉ាងដំណើរការល្អ។

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

វិធីសាស្រ្ត 2. នេះគឺជាជម្រើសរបស់សាលាចាស់ ហើយក្នុងពេលតែមួយសាមញ្ញណាស់។ តើ​អ្នក​មាន​ម៉ាស៊ីន​បម្រើ​ប្រភេទ​ណា​ដែល​បង្កើត​កំណត់​ហេតុ​របស់​អ្នក​ទេ? ហើយវាគ្រាន់តែសរសេរកំណត់ហេតុរបស់អ្នកទៅឯកសារមួយ។ ឧទាហរណ៍ ហើយម្តងមួយវិនាទី យើងប្តូរឈ្មោះឯកសារនេះ ហើយហែកឯកសារថ្មីមួយចេញ។ ហើយស្គ្រីបដាច់ដោយឡែក ទាំងតាមរយៈ cron ឬដេមិនខ្លះយកឯកសារចាស់បំផុត ហើយសរសេរវាទៅ ClickHouse ។ ប្រសិនបើអ្នកកត់ត្រាកំណត់ហេតុម្តងក្នុងមួយវិនាទី នោះអ្វីៗនឹងល្អ។

ប៉ុន្តែគុណវិបត្តិនៃវិធីសាស្ត្រនេះគឺថា ប្រសិនបើម៉ាស៊ីនមេរបស់អ្នកដែលកំណត់ហេតុត្រូវបានបង្កើតបាត់នៅកន្លែងណាមួយ នោះទិន្នន័យក៏នឹងរលាយបាត់ដែរ។

វិធីសាស្រ្ត 3. មានវិធីសាស្រ្តគួរឱ្យចាប់អារម្មណ៍មួយផ្សេងទៀតដែលមិនតម្រូវឱ្យមានឯកសារបណ្តោះអាសន្នទាល់តែសោះ។ ឧទាហរណ៍ អ្នកមានប្រភេទឧបករណ៍បង្វិលផ្សាយពាណិជ្ជកម្ម ឬដេមិនគួរឱ្យចាប់អារម្មណ៍មួយចំនួនផ្សេងទៀតដែលបង្កើតទិន្នន័យ។ ហើយ​អ្នក​អាច​ប្រមូល​ទិន្នន័យ​មួយ​ចំនួន​ដោយ​ផ្ទាល់​ក្នុង RAM ក្នុង​ទ្រនាប់។ ហើយនៅពេលដែលពេលវេលាគ្រប់គ្រាន់បានកន្លងផុតទៅ អ្នកដាក់បណ្តុំនេះមួយឡែក បង្កើតថ្មីមួយ ហើយនៅក្នុងខ្សែស្រឡាយដាច់ដោយឡែកមួយ បញ្ចូលអ្វីដែលបានប្រមូលផ្តុំរួចហើយទៅក្នុង ClickHouse ។

ម្យ៉ាងវិញទៀត ទិន្នន័យក៏បាត់ជាមួយ kill -9។ ប្រសិនបើម៉ាស៊ីនមេរបស់អ្នកគាំង អ្នកនឹងបាត់បង់ទិន្នន័យនេះ។ ហើយបញ្ហាមួយទៀតគឺថា ប្រសិនបើអ្នកមិនអាចសរសេរទៅកាន់ database បានទេនោះ ទិន្នន័យរបស់អ្នកនឹងកកកុញនៅក្នុង RAM។ ហើយទាំង RAM នឹងអស់ ឬអ្នកនឹងបាត់បង់ទិន្នន័យ។

វិធីសាស្រ្ត 4. វិធីសាស្រ្តគួរឱ្យចាប់អារម្មណ៍មួយផ្សេងទៀត។ តើ​អ្នក​មាន​ដំណើរ​ការ​ម៉ាស៊ីន​មេ​មួយ​ចំនួន​ដែរ​ឬ​ទេ? ហើយវាអាចបញ្ជូនទិន្នន័យទៅ ClickHouse ភ្លាមៗ ប៉ុន្តែធ្វើវាក្នុងការតភ្ជាប់តែមួយ។ ឧទាហរណ៍ ខ្ញុំបានផ្ញើសំណើរ http ជាមួយនឹងការផ្ទេរការអ៊ិនកូដ៖ ច្របាច់ជាមួយការបញ្ចូល។ ហើយ​វា​បង្កើត​កំណាត់​មិន​កម្រ​ពេក​ទេ អ្នក​អាច​ផ្ញើ​បន្ទាត់​នីមួយៗ​បាន ទោះបីជា​វា​នឹង​មាន​តម្លៃ​លើស​សម្រាប់​ការ​បង្កើត​ទិន្នន័យ​នេះ​ក៏ដោយ។

ទោះយ៉ាងណាក៏ដោយក្នុងករណីនេះទិន្នន័យនឹងត្រូវបានបញ្ជូនទៅ ClickHouse ភ្លាមៗ។ ហើយ ClickHouse នឹងរារាំងពួកគេដោយខ្លួនឯង។

ប៉ុន្តែបញ្ហាក៏កើតឡើងដែរ។ ឥឡូវនេះអ្នកនឹងបាត់បង់ទិន្នន័យ រួមទាំងពេលដែលដំណើរការរបស់អ្នកត្រូវបានសម្លាប់ ហើយប្រសិនបើដំណើរការ ClickHouse ត្រូវបានសម្លាប់ ព្រោះវានឹងក្លាយជាការបញ្ចូលមិនពេញលេញ។ ហើយនៅក្នុង ClickHouse សិលាចារឹកគឺអាតូមិករហូតដល់កម្រិតជាក់លាក់មួយក្នុងទំហំជួរដេក។ ជាគោលការណ៍នេះគឺជាវិធីគួរឱ្យចាប់អារម្មណ៍។ ក៏អាចប្រើប្រាស់បានដែរ។

វិធីសាស្រ្ត 5. នេះគឺជាវិធីសាស្រ្តគួរឱ្យចាប់អារម្មណ៍មួយផ្សេងទៀត។ នេះគឺជាប្រភេទនៃម៉ាស៊ីនមេដែលបង្កើតឡើងដោយសហគមន៍មួយចំនួនសម្រាប់ការប្រមូលទិន្នន័យ។ ខ្ញុំមិនបានមើលវាដោយខ្លួនឯងទេ ដូច្នេះខ្ញុំមិនអាចធានាអ្វីទាំងអស់។ ទោះយ៉ាងណាក៏ដោយ គ្មានការធានាណាមួយត្រូវបានផ្តល់ជូនសម្រាប់ ClickHouse ខ្លួនវានោះទេ។ នេះក៏ជាប្រភពបើកចំហផងដែរ ប៉ុន្តែម្យ៉ាងវិញទៀត អ្នកប្រហែលជាធ្លាប់ប្រើស្តង់ដារគុណភាពមួយចំនួន ដែលយើងព្យាយាមផ្តល់ជូន។ ប៉ុន្តែសម្រាប់រឿងនេះ - ខ្ញុំមិនដឹងទេ ចូលទៅកាន់ GitHub មើលកូដ។ ប្រហែលជាពួកគេសរសេរអ្វីធម្មតា។

* គិតត្រឹមឆ្នាំ 2020 គួរតែបន្ថែមការពិចារណាផងដែរ។ ផ្ទះកូនឆ្មា.

វិធីសាស្រ្តទី 6. វិធីសាស្រ្តមួយទៀតគឺប្រើ Buffer tables ។ អត្ថប្រយោជន៍នៃវិធីសាស្រ្តនេះគឺថាវាងាយស្រួលណាស់ក្នុងការចាប់ផ្តើមប្រើប្រាស់។ បង្កើតតារាង Buffer ហើយបញ្ចូលវាទៅក្នុងវា។

គុណវិបត្តិគឺថាបញ្ហាមិនត្រូវបានដោះស្រាយទាំងស្រុង។ ប្រសិនបើក្នុងអត្រាមួយដូចជា MergeTree អ្នកត្រូវដាក់ជាក្រុមទិន្នន័យដោយមួយបាច់ក្នុងមួយវិនាទី បន្ទាប់មកក្នុងអត្រាក្នុងតារាងសតិបណ្ដោះអាសន្ន អ្នកត្រូវដាក់ជាក្រុមយ៉ាងហោចណាស់រហូតដល់ច្រើនពាន់ក្នុងមួយវិនាទី។ ប្រសិនបើវាលើសពី 10 ក្នុងមួយវិនាទីវានឹងនៅតែអាក្រក់។ ហើយប្រសិនបើអ្នកបញ្ចូលវាជាបាច់ នោះអ្នកឃើញថាវាប្រែទៅជាមួយរយពាន់បន្ទាត់ក្នុងមួយវិនាទី។ ហើយ​នេះ​គឺ​ជា​ទិន្នន័យ​ធ្ងន់​ល្មម​រួច​ទៅ​ហើយ។

ហើយតារាងសតិបណ្ដោះអាសន្នក៏មិនមានកំណត់ហេតុដែរ។ ហើយប្រសិនបើមានបញ្ហាជាមួយម៉ាស៊ីនមេរបស់អ្នក នោះទិន្នន័យនឹងត្រូវបាត់បង់។

ហើយជាប្រាក់រង្វាន់ ថ្មីៗនេះយើងទទួលបានឱកាសនៅ ClickHouse ដើម្បីទាញយកទិន្នន័យពី Kafka ។ មានម៉ាស៊ីនតុ - Kafka ។ អ្នកគ្រាន់តែបង្កើត។ ហើយអ្នកអាចព្យួរតំណាងជាក់ស្តែងនៅលើវា។ ក្នុងករណីនេះ វានឹងទាញយកទិន្នន័យដោយខ្លួនឯងពី Kafka ហើយបញ្ចូលវាទៅក្នុងតារាងដែលអ្នកត្រូវការ។

ហើយ​អ្វី​ដែល​រីករាយ​ជាពិសេស​ចំពោះ​ឱកាស​នេះ​គឺ​មិនមែន​យើង​ដែល​ធ្វើ​វា​នោះ​ទេ។ នេះគឺជាលក្ខណៈសហគមន៍។ ហើយនៅពេលដែលខ្ញុំនិយាយថា "លក្ខណៈពិសេសសហគមន៍" ខ្ញុំមានន័យថាវាដោយគ្មានការមើលងាយណាមួយឡើយ។ យើងអានកូដ ធ្វើការត្រួតពិនិត្យ វាគួរតែដំណើរការល្អ។

* គិតត្រឹមឆ្នាំ 2020 ការគាំទ្រស្រដៀងគ្នាបានលេចឡើងសម្រាប់ RabbitMQ.

តើមានអ្វីផ្សេងទៀតដែលអាចជាការរអាក់រអួល ឬមិនបានរំពឹងទុកនៅពេលបញ្ចូលទិន្នន័យ? ប្រសិនបើអ្នកធ្វើការស្នើសុំបញ្ចូលតម្លៃ ហើយសរសេរកន្សោមដែលបានគណនាមួយចំនួននៅក្នុងតម្លៃ។ ឧទាហរណ៍ now() ក៏ជាកន្សោមដែលបានគណនាផងដែរ។ ហើយក្នុងករណីនេះ ClickHouse ត្រូវបានបង្ខំឱ្យបើកដំណើរការអ្នកបកប្រែនៃកន្សោមទាំងនេះនៅលើបន្ទាត់នីមួយៗ ហើយការអនុវត្តនឹងធ្លាក់ចុះតាមលំដាប់លំដោយ។ វាជាការល្អប្រសើរជាងមុនដើម្បីជៀសវាងបញ្ហានេះ។

* នៅពេលនេះ បញ្ហាត្រូវបានដោះស្រាយទាំងស្រុង លែងមានដំណើរការតំរែតំរង់ទៀតហើយនៅពេលប្រើកន្សោមក្នុង VALUES ។

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

* ថ្មីៗនេះ នៅក្នុងរបៀបពិសោធន៍ ClickHouse បានបន្ថែមការគាំទ្រសម្រាប់ទម្រង់បង្រួមនៃកំណាត់ និងកំណាត់នៅក្នុង RAM ជាមួយនឹងកំណត់ហេតុសរសេរជាមុន ដែលស្ទើរតែដោះស្រាយបញ្ហាបានទាំងស្រុង។

ឥឡូវនេះសូមមើលប្រភេទទីពីរនៃបញ្ហា - ការវាយបញ្ចូលទិន្នន័យ។

ការវាយបញ្ចូលទិន្នន័យអាចតឹងរ៉ឹង ឬខ្សែអក្សរ។ ខ្សែអក្សរគឺនៅពេលដែលអ្នកទើបតែយកវា ហើយប្រកាសថាវាលទាំងអស់របស់អ្នកគឺជាប្រភេទខ្សែអក្សរ។ នេះជះ។ មិនចាំបាច់ធ្វើបែបនេះទេ។

ចូរយើងស្វែងយល់ពីរបៀបធ្វើវាឱ្យត្រឹមត្រូវនៅក្នុងករណីទាំងនោះ នៅពេលអ្នកចង់និយាយថាយើងមានវាលមួយចំនួន ខ្សែអក្សរ ហើយអនុញ្ញាតឱ្យ ClickHouse ដោះស្រាយវាដោយខ្លួនឯង ហើយខ្ញុំនឹងមិនបារម្ភអំពីវាទេ។ ប៉ុន្តែវានៅតែមានតម្លៃក្នុងការខិតខំប្រឹងប្រែងខ្លះ។

ឧទាហរណ៍យើងមានអាសយដ្ឋាន IP ។ ក្នុងករណីមួយ យើងបានរក្សាទុកវាជាខ្សែអក្សរ។ ឧទាហរណ៍ 192.168.1.1 ។ ហើយនៅក្នុងករណីមួយទៀត វានឹងជាប្រភេទ UInt32*។ 32 ប៊ីតគឺគ្រប់គ្រាន់សម្រាប់អាសយដ្ឋាន IPv4 ។

ជាដំបូង ចម្លែកគ្រប់គ្រាន់ ទិន្នន័យនឹងត្រូវបានបង្ហាប់ប្រហែលស្មើៗគ្នា។ ប្រាកដណាស់ វានឹងមានភាពខុសគ្នា ប៉ុន្តែមិនធំនោះទេ។ ដូច្នេះមិនមានបញ្ហាពិសេសជាមួយឌីស I/O ទេ។

ប៉ុន្តែមានភាពខុសគ្នាយ៉ាងធ្ងន់ធ្ងរនៅក្នុងពេលវេលាដំណើរការ និងពេលវេលាប្រតិបត្តិសំណួរ។

ចូររាប់ចំនួនអាសយដ្ឋាន IP តែមួយគត់ ប្រសិនបើពួកវាត្រូវបានរក្សាទុកជាលេខ។ វាដំណើរការរហូតដល់ 137 លានបន្ទាត់ក្នុងមួយវិនាទី។ ប្រសិនបើដូចគ្នានៅក្នុងទម្រង់នៃខ្សែនោះ 37 លានបន្ទាត់ក្នុងមួយវិនាទី។ ខ្ញុំ​មិន​ដឹង​ថា​ហេតុ​អ្វី​បាន​ជា​រឿង​ចៃដន្យ​នេះ​កើត​ឡើង។ ខ្ញុំបានអនុវត្តសំណើទាំងនេះដោយខ្លួនឯង។ ប៉ុន្តែនៅតែយឺតជាង 4 ដង។

ហើយប្រសិនបើអ្នកគណនាភាពខុសគ្នានៃទំហំថាសនោះ វាក៏មានភាពខុសគ្នាផងដែរ។ ហើយភាពខុសគ្នាគឺប្រហែលមួយភាគបួន ពីព្រោះមានអាសយដ្ឋាន IP ប្លែកៗជាច្រើន។ ហើយ​ប្រសិនបើ​មាន​បន្ទាត់​ដែលមាន​អត្ថន័យ​ខុសៗ​គ្នា​តិចតួច នោះ​ពួកវា​នឹង​ត្រូវ​បាន​បង្ហាប់​យ៉ាង​ងាយស្រួល​តាម​វចនានុក្រម​ទៅជា​បរិមាណ​ប្រហាក់ប្រហែល។

ហើយភាពខុសគ្នានៃពេលវេលាបួនដងមិនស្ថិតនៅលើផ្លូវទេ។ ប្រហែល​ជា​អ្នក​មិន​ហ៊ាន​និយាយ​ទេ ប៉ុន្តែ​ពេល​ខ្ញុំ​ឃើញ​ការ​ខុស​គ្នា​បែប​នេះ វា​ធ្វើ​ឲ្យ​ខ្ញុំ​សោក​ស្តាយ។

សូមក្រឡេកមើលករណីផ្សេងៗ។

1. ករណីមួយនៅពេលដែលអ្នកមានតម្លៃខុសគ្នាតិចតួច។ ក្នុងករណីនេះ យើងប្រើការអនុវត្តសាមញ្ញមួយ ដែលអ្នកប្រហែលជាដឹង និងអាចប្រើសម្រាប់ DBMS ណាមួយ។ ទាំងអស់នេះសមហេតុផលមិនត្រឹមតែសម្រាប់ ClickHouse ប៉ុណ្ណោះទេ។ គ្រាន់តែសរសេរលេខសម្គាល់ទៅក្នុងមូលដ្ឋានទិន្នន័យ។ ហើយ​អ្នក​អាច​បំប្លែង​ទៅ​ជា​ខ្សែអក្សរ និង​ត្រឡប់​មក​វិញ​នៅ​ផ្នែក​ម្ខាង​នៃ​កម្មវិធី​របស់​អ្នក។

ឧទាហរណ៍អ្នកមានតំបន់មួយ។ ហើយអ្នកកំពុងព្យាយាមរក្សាទុកវាជាខ្សែអក្សរ។ ហើយវានឹងត្រូវបានសរសេរនៅទីនោះ៖ តំបន់មូស្គូ និងតំបន់មូស្គូ។ ហើយនៅពេលដែលខ្ញុំឃើញថាវានិយាយថា "មូស្គូ" វាគ្មានអ្វីសោះ ប៉ុន្តែនៅពេលដែលវាជាទីក្រុងមូស្គូ វាបានក្លាយទៅជាសោកសៅទាំងស្រុង។ នេះជាចំនួនបៃ។

ផ្ទុយទៅវិញ យើងគ្រាន់តែសរសេរលេខ Ulnt32 និង 250។ យើងមាន 250 នៅក្នុង Yandex ប៉ុន្តែអ្នកប្រហែលជាខុសគ្នា។ ក្នុងករណី ខ្ញុំនឹងនិយាយថា ClickHouse មានសមត្ថភាពភ្ជាប់មកជាមួយដើម្បីធ្វើការជាមួយ Geobase ។ អ្នកគ្រាន់តែសរសេរថតដែលមានតំបន់ រួមទាំងឋានានុក្រមមួយ ពោលគឺនឹងមានទីក្រុងម៉ូស្គូ តំបន់មូស្គូ និងអ្វីៗគ្រប់យ៉ាងដែលអ្នកត្រូវការ។ ហើយ​អ្នក​អាច​បំប្លែង​នៅ​កម្រិត​សំណើ។

ជម្រើសទីពីរគឺប្រហែលដូចគ្នា ប៉ុន្តែដោយមានការគាំទ្រនៅខាងក្នុង ClickHouse ។ នេះគឺជាប្រភេទទិន្នន័យ Enum ។ អ្នកគ្រាន់តែសរសេរតម្លៃទាំងអស់ដែលអ្នកត្រូវការនៅខាងក្នុង Enum ។ ឧទាហរណ៍ ប្រភេទនៃឧបករណ៍ ហើយសរសេរនៅទីនោះ៖ កុំព្យូទ័រលើតុ ទូរសព្ទចល័ត ថេប្លេត ទូរទស្សន៍។ សរុបមាន 4 ជម្រើស។

គុណវិបត្តិគឺថាអ្នកត្រូវផ្លាស់ប្តូរវាជាទៀងទាត់។ មានតែជម្រើសមួយប៉ុណ្ណោះដែលត្រូវបានបន្ថែម។ តោះធ្វើការផ្លាស់ប្តូរតារាង។ ជាការពិត តារាងផ្លាស់ប្តូរនៅក្នុង ClickHouse គឺឥតគិតថ្លៃ។ ជាពិសេសឥតគិតថ្លៃសម្រាប់ Enum ដោយសារតែទិន្នន័យនៅលើថាសមិនផ្លាស់ប្តូរ។ ប៉ុន្តែទោះជាយ៉ាងណាក៏ដោយ ការផ្លាស់ប្តូរទទួលបានសោ* នៅលើតុ ហើយត្រូវរង់ចាំរហូតដល់ការជ្រើសរើសទាំងអស់ត្រូវបានប្រតិបត្តិ។ ហើយមានតែបន្ទាប់ពីការផ្លាស់ប្តូរនេះនឹងត្រូវបានប្រតិបត្តិ ពោលគឺនៅតែមានការរអាក់រអួលមួយចំនួន។

* នៅក្នុងកំណែចុងក្រោយបំផុតរបស់ ClickHouse, ALTER ត្រូវបានធ្វើឡើងដោយមិនទប់ស្កាត់ទាំងស្រុង។

ជម្រើសមួយទៀតដែលមានតែមួយគត់សម្រាប់ ClickHouse គឺការភ្ជាប់វចនានុក្រមខាងក្រៅ។ អ្នកអាចសរសេរលេខនៅក្នុង ClickHouse និងរក្សាបញ្ជីឈ្មោះរបស់អ្នកនៅក្នុងប្រព័ន្ធណាមួយដែលងាយស្រួលសម្រាប់អ្នក។ ឧទាហរណ៍អ្នកអាចប្រើ: MySQL, Mongo, Postgres ។ អ្នកថែមទាំងអាចបង្កើត microservice ផ្ទាល់ខ្លួនរបស់អ្នកដែលនឹងផ្ញើទិន្នន័យនេះតាមរយៈ http ។ ហើយនៅកម្រិត ClickHouse អ្នកសរសេរមុខងារដែលនឹងបម្លែងទិន្នន័យនេះពីលេខទៅជាខ្សែអក្សរ។

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

នេះជាឧទាហរណ៍មួយ។ មាន Yandex.Direct ។ ហើយមានក្រុមហ៊ុនផ្សាយពាណិជ្ជកម្ម និងបដា។ ប្រហែលជាមានក្រុមហ៊ុនផ្សាយពាណិជ្ជកម្មរាប់សិបលាន។ ហើយពួកវាប្រហាក់ប្រហែលនឹង RAM ។ ហើយ​មាន​បដា​រាប់​ពាន់​លាន វា​មិន​សម​ទេ។ ហើយយើងប្រើវចនានុក្រមឃ្លាំងសម្ងាត់ពី MySQL ។

បញ្ហាតែមួយគត់គឺថាវចនានុក្រមឃ្លាំងសម្ងាត់នឹងដំណើរការល្អប្រសិនបើអត្រាបុកគឺជិត 100% ។ ប្រសិនបើវាតូចជាងនោះ នៅពេលដំណើរការសំណួរសម្រាប់បណ្តុំទិន្នន័យនីមួយៗ អ្នកនឹងត្រូវយកសោដែលបាត់ ហើយទៅយកទិន្នន័យពី MySQL ។ អំពី ClickHouse ខ្ញុំនៅតែអាចធានាថា - បាទ វាមិនថយចុះទេ ខ្ញុំនឹងមិននិយាយអំពីប្រព័ន្ធផ្សេងទៀតទេ។

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

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

បញ្ហាតែមួយគត់គឺថាប្រសិនបើ hash គឺ 64-bit នោះអ្នកនឹងស្ទើរតែមានការប៉ះទង្គិច។ ដោយសារតែប្រសិនបើមានបន្ទាត់មួយពាន់លាននៅទីនោះ នោះប្រូបាប៊ីលីតេនឹងក្លាយទៅជាគួរឱ្យកត់សម្គាល់រួចទៅហើយ។

ហើយវានឹងមិនល្អទេក្នុងការដកឈ្មោះក្រុមហ៊ុនផ្សាយពាណិជ្ជកម្មតាមរបៀបនេះ។ ប្រសិនបើយុទ្ធនាការផ្សាយពាណិជ្ជកម្មរបស់ក្រុមហ៊ុនផ្សេងៗគ្នាត្រូវបានលាយបញ្ចូលគ្នា នោះនឹងមានអ្វីមួយដែលមិនអាចយល់បាន។

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

ជាប្រាក់រង្វាន់ សម្រាប់ប្រតិបត្តិការជាច្រើន hashes តែឯងគឺគ្រប់គ្រាន់ហើយ ខ្សែអក្សរខ្លួនឯងមិនចាំបាច់ត្រូវរក្សាទុកនៅកន្លែងណានោះទេ។

ឧទាហរណ៍មួយទៀតគឺប្រសិនបើខ្សែអក្សរខ្លី ឧទាហរណ៍ ដែនគេហទំព័រ។ ពួកគេអាចត្រូវបានរក្សាទុកដូច។ ឬឧទាហរណ៍ភាសាកម្មវិធីរុករក ru - 2 បៃ។ ជាការពិតណាស់ ខ្ញុំពិតជាមានអារម្មណ៍សោកស្តាយចំពោះបៃ ប៉ុន្តែកុំបារម្ភ 2 បៃមិនមែនជាការអាណិតនោះទេ។ សូមរក្សាវាឱ្យនៅដដែល កុំបារម្ភ។

ករណីមួយទៀតគឺនៅពេលដែល ផ្ទុយទៅវិញ មានបន្ទាត់ច្រើន ហើយមានចំនុចពិសេសជាច្រើននៅក្នុងពួកវា ហើយសូម្បីតែឈុតក៏គ្មានដែនកំណត់ដែរ។ ឧទាហរណ៍ធម្មតាគឺឃ្លាស្វែងរក ឬ URLs ។ ស្វែងរកឃ្លា រួមទាំងការវាយអក្សរ។ តោះមើលថាតើមានឃ្លាស្វែងរកប្លែកៗប៉ុន្មានក្នុងមួយថ្ងៃ។ ហើយវាប្រែថាពួកគេស្ទើរតែពាក់កណ្តាលនៃព្រឹត្តិការណ៍ទាំងអស់។ ហើយក្នុងករណីនេះ អ្នកប្រហែលជាគិតថាអ្នកត្រូវការធ្វើឱ្យទិន្នន័យធម្មតា រាប់លេខសម្គាល់ ហើយដាក់វានៅក្នុងតារាងដាច់ដោយឡែកមួយ។ ប៉ុន្តែអ្នកមិនចាំបាច់ធ្វើវាទេ។ គ្រាន់តែរក្សាបន្ទាត់ទាំងនេះដូចដែលពួកគេមាន។

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

ហើយប្រសិនបើទិន្នន័យត្រូវបានរក្សាទុកនៅនឹងកន្លែងនោះវាត្រូវបានអានយ៉ាងសាមញ្ញតាមលំដាប់ដែលត្រូវការពីប្រព័ន្ធឯកសារហើយអ្វីៗគឺល្អ។

ប្រសិនបើអ្នកមាន URLs ឬខ្សែអក្សរវែងស្មុគ្រស្មាញផ្សេងទៀត នោះវាមានតម្លៃពិចារណាថាអ្នកអាចគណនាប្រភេទនៃការដកស្រង់មួយចំនួនជាមុន ហើយសរសេរវានៅក្នុងជួរឈរដាច់ដោយឡែកមួយ។

ឧទាហរណ៍សម្រាប់ URLs អ្នកអាចរក្សាទុកដែនដោយឡែកពីគ្នា។ ហើយប្រសិនបើអ្នកពិតជាត្រូវការដែន នោះគ្រាន់តែប្រើជួរឈរនេះ ហើយ URLs នឹងនៅទីនោះ ហើយអ្នកនឹងមិនប៉ះពួកវាទេ។

តោះមើលថាតើអ្វីជាភាពខុសគ្នា។ ClickHouse មានមុខងារពិសេសដែលគណនាដែន។ វាលឿនណាស់ យើងបានបង្កើនប្រសិទ្ធភាពវា។ ហើយនិយាយឱ្យត្រង់ទៅ វាមិនអនុលោមតាម RFC នោះទេ ប៉ុន្តែទោះជាយ៉ាងណា វាចាត់ទុកអ្វីៗទាំងអស់ដែលយើងត្រូវការ។

ហើយក្នុងករណីមួយ យើងគ្រាន់តែទទួលបាន URLs និងគណនាដែន។ វាដំណើរការរហូតដល់ 166 មិល្លីវិនាទី។ ហើយប្រសិនបើអ្នកយកដែនដែលត្រៀមរួចជាស្រេច នោះវាប្រែទៅជាត្រឹមតែ 67 មីលីវិនាទី ពោលគឺលឿនជាងជិតបីដង។ ហើយ​វា​លឿន​ជាង​នេះ មិន​មែន​ដោយសារ​យើង​ត្រូវ​ធ្វើ​ការ​គណនា​ខ្លះ​ទេ ប៉ុន្តែ​ដោយសារ​យើង​អាន​ទិន្នន័យ​តិច។

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

ហើយប្រសិនបើអ្នកក្រឡេកមើលបរិមាណទិន្នន័យនៅលើឌីស វាប្រែថា URL គឺ 126 មេកាបៃ ហើយដែនមានត្រឹមតែ 5 មេកាបៃប៉ុណ្ណោះ។ វាប្រែចេញតិចជាង 25 ដង។ ប៉ុន្តែទោះជាយ៉ាងណា សំណើនេះត្រូវបានប្រតិបត្តិលឿនជាង 4 ដងប៉ុណ្ណោះ។ ប៉ុន្តែនោះដោយសារតែទិន្នន័យក្តៅ។ ហើយប្រសិនបើវាត្រជាក់ វាប្រហែលជាលឿនជាង 25 ដង ដោយសារថាស I/O ។

ដោយវិធីនេះ ប្រសិនបើអ្នកប៉ាន់ស្មានថាតើដែនមួយមានទំហំតូចជាង URL ប៉ុនណា វាប្រែជាតូចជាងប្រហែល 4 ដង។ ប៉ុន្តែសម្រាប់ហេតុផលមួយចំនួន ទិន្នន័យប្រើប្រាស់តិចជាង 25 ដងនៅលើថាស។ ហេតុអ្វី? ដោយសារតែការបង្ហាប់។ ហើយ URL ត្រូវបានបង្ហាប់ ហើយដែនត្រូវបានបង្ហាប់។ ប៉ុន្តែជាញឹកញាប់ URL មានផ្ទុកសំរាមជាច្រើន។

ហើយជាការពិតណាស់វាចំណាយដើម្បីប្រើប្រភេទទិន្នន័យត្រឹមត្រូវដែលត្រូវបានរចនាឡើងជាពិសេសសម្រាប់តម្លៃដែលចង់បានឬដែលសមរម្យ។ ប្រសិនបើអ្នកស្ថិតនៅក្នុង IPv4 បន្ទាប់មករក្សាទុក UInt32*។ ប្រសិនបើ IPv6 បន្ទាប់មក FixedString(16) ដោយសារតែអាសយដ្ឋាន IPv6 គឺ 128 ប៊ីត ពោលគឺត្រូវបានរក្សាទុកដោយផ្ទាល់ក្នុងទម្រង់គោលពីរ។

ប៉ុន្តែចុះយ៉ាងណាបើពេលខ្លះអ្នកមានអាសយដ្ឋាន IPv4 ហើយពេលខ្លះ IPv6? បាទ/ចាស អ្នកអាចរក្សាទុកទាំងពីរ។ ជួរឈរមួយសម្រាប់ IPv4 មួយទៀតសម្រាប់ IPv6 ។ ជាការពិតណាស់មានជម្រើសមួយដើម្បីបង្ហាញ IPv4 នៅក្នុង IPv6 ។ វានឹងដំណើរការផងដែរ ប៉ុន្តែប្រសិនបើអ្នកជារឿយៗត្រូវការអាសយដ្ឋាន IPv4 នៅក្នុងសំណើ នោះវាជាការប្រសើរណាស់ក្នុងការដាក់វានៅក្នុងជួរឈរដាច់ដោយឡែកមួយ។

* ClickHouse ឥឡូវនេះមានប្រភេទទិន្នន័យ IPv4, IPv6 ដាច់ដោយឡែកដែលរក្សាទុកទិន្នន័យប្រកបដោយប្រសិទ្ធភាពដូចលេខ ប៉ុន្តែតំណាងឱ្យពួកវាយ៉ាងងាយស្រួលដូចខ្សែអក្សរ។

វាក៏សំខាន់ផងដែរក្នុងការកត់សម្គាល់ថាវាមានតម្លៃក្នុងការដំណើរការទិន្នន័យជាមុន។ ឧទាហរណ៍ អ្នកទទួលបានកំណត់ហេតុឆៅមួយចំនួន។ ហើយប្រហែលជាអ្នកមិនគួរគ្រាន់តែដាក់ពួកវានៅក្នុង ClickHouse ភ្លាមៗនោះទេ បើទោះបីជាវាគួរឱ្យចង់ធ្វើអ្វីក៏ដោយ ហើយអ្វីៗនឹងដំណើរការ។ ប៉ុន្តែវានៅតែមានតម្លៃក្នុងការអនុវត្តការគណនាដែលអាចធ្វើទៅបាន។

ឧទាហរណ៍កំណែកម្មវិធីរុករក។ នៅក្នុងនាយកដ្ឋានក្បែរនោះ ដែលខ្ញុំមិនចង់ចង្អុលដៃ កំណែកម្មវិធីរុករកត្រូវបានរក្សាទុកដូចនេះ នោះគឺដូចជាខ្សែអក្សរ៖ 12.3។ ហើយ​បន្ទាប់​មក​ដើម្បី​ធ្វើ​របាយការណ៍ គេ​យក​ខ្សែ​នេះ​ហើយ​ចែក​វា​ជា​អារេ​មួយ ហើយ​បន្ទាប់​មក​ចូល​ទៅ​ក្នុង​ធាតុ​ទីមួយ​នៃ​អារេ។ តាមធម្មជាតិ អ្វីៗដំណើរការយឺត។ ខ្ញុំ​បាន​សួរ​ថា ហេតុ​អ្វី​បាន​ជា​គេ​ធ្វើ​បែប​នេះ? ពួកគេបានប្រាប់ខ្ញុំថា ពួកគេមិនចូលចិត្តការបង្កើនប្រសិទ្ធភាពមុនអាយុ។ ហើយ​ខ្ញុំ​មិន​ចូល​ចិត្ត​ទុទិដ្ឋិនិយម​មុន​អាយុ។

ដូច្នេះក្នុងករណីនេះ វានឹងកាន់តែត្រឹមត្រូវក្នុងការបែងចែកជា 4 ជួរ។ កុំខ្លាចនៅទីនេះ ព្រោះនេះជា ClickHouse។ ClickHouse គឺជាមូលដ្ឋានទិន្នន័យជួរឈរ។ ហើយសសរតូចៗកាន់តែស្អាត កាន់តែល្អ វានឹងមាន 5 BrowserVersions បង្កើត 5 ជួរឈរ។ នេះល្អណាស់។

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

ឧទាហរណ៍ សេវាកម្មវិភាគរបស់យើងមួយមានប៉ារ៉ាម៉ែត្រព្រឹត្តិការណ៍មួយចំនួន។ ហើយប្រសិនបើមានប៉ារ៉ាម៉ែត្រជាច្រើនសម្រាប់ព្រឹត្តិការណ៍ យើងគ្រាន់តែរក្សាទុក 512 ដំបូងដែលមក។ ពីព្រោះ 512 មិនមែនជាការអាណិតទេ។

ហើយប្រសិនបើអ្នកមិនអាចសម្រេចចិត្តលើប្រភេទទិន្នន័យរបស់អ្នកបានទេ នោះអ្នកក៏អាចកត់ត្រាទិន្នន័យនៅក្នុង ClickHouse ប៉ុន្តែនៅក្នុងតារាងបណ្តោះអាសន្ននៃប្រភេទ Log ពិសេសសម្រាប់ទិន្នន័យបណ្តោះអាសន្ន។ បន្ទាប់ពីនេះអ្នកអាចវិភាគអ្វីដែលការចែកចាយតម្លៃដែលអ្នកមាននៅទីនោះអ្វីដែលមានជាទូទៅនិងបង្កើតប្រភេទត្រឹមត្រូវ។

* ClickHouse ឥឡូវនេះមានប្រភេទទិន្នន័យ ខាឌីនទាប ដែលអនុញ្ញាតឱ្យអ្នករក្សាទុកខ្សែអក្សរប្រកបដោយប្រសិទ្ធភាពជាមួយនឹងការខិតខំប្រឹងប្រែងតិច។

ឥឡូវនេះសូមក្រឡេកមើលករណីគួរឱ្យចាប់អារម្មណ៍មួយទៀត។ ពេលខ្លះអ្វីៗដំណើរការយ៉ាងចម្លែកសម្រាប់មនុស្ស។ ខ្ញុំចូលមកមើលរឿងនេះ។ ហើយភ្លាមៗនោះ វាហាក់បីដូចជានេះត្រូវបានធ្វើដោយអ្នកគ្រប់គ្រងឆ្លាតវៃដែលមានបទពិសោធន៍ និងបទពិសោធន៍យ៉ាងទូលំទូលាយក្នុងការដំឡើង MySQL កំណែ 3.23។

នៅទីនេះយើងឃើញតុមួយពាន់ ដែលតារាងនីមួយៗកត់ត្រានៅសល់នៃការបែងចែកអ្នកណាដឹងដោយមួយពាន់។

ជាគោលការណ៍ ខ្ញុំគោរពបទពិសោធន៍របស់អ្នកដទៃ រួមទាំងការយល់ដឹងអំពីទុក្ខលំបាកដែលអាចទទួលបានតាមរយៈបទពិសោធន៍នេះ។

ហើយហេតុផលគឺច្បាស់ជាងឬតិច។ ទាំងនេះគឺជាគំរូចាស់ដែលប្រហែលជាបានប្រមូលផ្តុំនៅពេលធ្វើការជាមួយប្រព័ន្ធផ្សេងទៀត។ ឧទាហរណ៍ តារាង MyISAM មិនមានកូនសោចម្បងដែលដាក់ជាចង្កោមទេ។ ហើយវិធីនៃការបែងចែកទិន្នន័យនេះអាចជាការប៉ុនប៉ងអស់សង្ឃឹមដើម្បីទទួលបានមុខងារដូចគ្នា។

ហេតុផលមួយទៀតគឺថាវាពិបាកក្នុងការធ្វើប្រតិបត្តិការផ្លាស់ប្តូរណាមួយនៅលើតុធំ។ អ្វីគ្រប់យ៉ាងនឹងត្រូវបានរារាំង។ ទោះបីជានៅក្នុងកំណែទំនើបនៃ MySQL បញ្ហានេះលែងធ្ងន់ធ្ងរទៀតហើយ។

ឬឧទាហរណ៍ microsharding ប៉ុន្តែមានច្រើនទៀតនៅពេលក្រោយ។

មិនចាំបាច់ធ្វើបែបនេះនៅក្នុង ClickHouse ទេ ព្រោះជាដំបូង គន្លឹះចម្បងត្រូវបានចង្កោម ទិន្នន័យត្រូវបានតម្រៀបដោយសោចម្បង។

ហើយពេលខ្លះមនុស្សសួរខ្ញុំថា "តើដំណើរការនៃសំណួរជួរនៅក្នុង ClickHouse ប្រែប្រួលអាស្រ័យលើទំហំតារាងយ៉ាងដូចម្តេច?" ខ្ញុំ​និយាយ​ថា​វា​មិន​បាន​ផ្លាស់​ប្តូ​រ​អ្វី​ទាំង​អស់​។ ឧទាហរណ៍ អ្នកមានតារាងមួយពាន់ជួរ ហើយអ្នកអានជួរមួយលានជួរ។ អ្វីគ្រប់យ៉ាងគឺល្អ។ ប្រសិនបើមានជួរមួយពាន់ពាន់លាននៅក្នុងតារាង ហើយអ្នកអានមួយលានជួរ វានឹងស្ទើរតែដូចគ្នា។

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

ការផ្លាស់ប្តូរនៅក្នុង ClickHouse គឺឥតគិតថ្លៃប្រសិនបើការផ្លាស់ប្តូរបន្ថែម / ទម្លាក់ជួរឈរ។

ហើយ​អ្នក​មិន​គួរ​ធ្វើ​តុ​តូច​ទេ ព្រោះ​បើ​អ្នក​មាន ១០ ជួរ ឬ ១០,០០០ ជួរ​ក្នុង​តារាង នោះ​វា​គ្មាន​បញ្ហា​អ្វី​ទាំង​អស់។ ClickHouse គឺជាប្រព័ន្ធដែលបង្កើនប្រសិទ្ធភាពលំហូរចេញ មិនមែនភាពយឺតយ៉ាវទេ ដូច្នេះវាគ្មានន័យទេក្នុងដំណើរការ 10 បន្ទាត់។

វាជាការត្រឹមត្រូវក្នុងការប្រើតុធំមួយ។ កម្ចាត់គំរូចាស់ អ្វីៗនឹងល្អ។

ហើយជាប្រាក់រង្វាន់ នៅក្នុងកំណែចុងក្រោយបំផុតឥឡូវនេះ យើងមានសមត្ថភាពក្នុងការបង្កើតសោបែងចែកតាមអំពើចិត្ត ដើម្បីអនុវត្តប្រតិបត្តិការថែទាំគ្រប់ប្រភេទនៅលើភាគថាសនីមួយៗ។

ឧទាហរណ៍ អ្នកត្រូវការតារាងតូចៗជាច្រើន ជាឧទាហរណ៍ នៅពេលដែលមានតម្រូវការដំណើរការទិន្នន័យកម្រិតមធ្យមមួយចំនួន អ្នកទទួលបានកំណាត់ ហើយអ្នកត្រូវធ្វើការបំប្លែងលើពួកវា មុនពេលសរសេរទៅតារាងចុងក្រោយ។ សម្រាប់ករណីនេះមានម៉ាស៊ីនតុដ៏អស្ចារ្យ - StripeLog ។ វាដូចជា TinyLog ល្អជាង។

* ឥឡូវនេះ ClickHouse ក៏មានផងដែរ។ ការបញ្ចូលមុខងារតារាង.

ការប្រឆាំងនឹងលំនាំមួយទៀតគឺ microsharding ។ ឧទាហរណ៍ អ្នកត្រូវ Shard data ហើយអ្នកមាន 5 servers ហើយថ្ងៃស្អែកនឹងមាន 6 server។ ហើយអ្នកគិតអំពីរបៀបធ្វើសមតុល្យទិន្នន័យនេះឡើងវិញ។ ហើយជំនួសមកវិញ អ្នកមិនបំបែកទៅជា 5 shards ប៉ុន្តែចូលទៅក្នុង 1 shards ។ ហើយ​បន្ទាប់​មក​អ្នក​ផ្គូផ្គង microshards នីមួយៗ​ទៅ​ម៉ាស៊ីន​មេ​ដាច់​ដោយ​ឡែក។ ហើយអ្នកនឹងទទួលបានឧទាហរណ៍ 000 ClickHouses នៅលើម៉ាស៊ីនមេតែមួយ។ ញែកឧទាហរណ៍នៅលើច្រកដាច់ដោយឡែកឬមូលដ្ឋានទិន្នន័យដាច់ដោយឡែក។

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

ហេតុផលមួយទៀតគឺថាការបែងចែកការងារនៅទូទាំងករណីទាំងនេះនឹងមិនស្មើគ្នា។ ខ្លះនឹងបញ្ចប់មុន ខ្លះបញ្ចប់នៅពេលក្រោយ។ ប្រសិនបើអ្វីៗទាំងអស់នេះបានកើតឡើងក្នុងឧទាហរណ៍មួយ នោះ ClickHouse ខ្លួនវានឹងរកវិធីចែកចាយទិន្នន័យយ៉ាងត្រឹមត្រូវក្នុងចំណោមខ្សែស្រឡាយ។

ហើយហេតុផលមួយទៀតគឺថា អ្នកនឹងមានទំនាក់ទំនងអន្តរដំណើរការតាមរយៈ TCP ។ ទិន្នន័យ​នឹង​ត្រូវ​បាន​ធ្វើ​ជា​សៀរៀល, deserialized, ហើយ​នេះ​គឺ​ជា​ចំនួន​ដ៏ច្រើន​នៃ microshards ។ វានឹងមិនដំណើរការប្រកបដោយប្រសិទ្ធភាពទេ។

គំរូមួយទៀត ទោះបីវាស្ទើរតែមិនអាចហៅថា antipattern ក៏ដោយ។ នេះគឺជាចំនួនដ៏ធំនៃការប្រមូលផ្តុំជាមុន។

ជាទូទៅការប្រមូលផ្តុំមុនគឺល្អ។ អ្នក​មាន​ជួរ​មួយ​ពាន់​លាន អ្នក​បាន​បូក​បញ្ចូល​វា ហើយ​វា​បាន​ក្លាយ​ជា 1 ជួរ ហើយ​ឥឡូវ​សំណួរ​ត្រូវ​បាន​ប្រតិបត្តិ​ភ្លាមៗ។ អ្វីគ្រប់យ៉ាងគឺអស្ចារ្យណាស់។ អ្នក​អាច​ធ្វើ​ដូច​នេះ​បាន។ ហើយសម្រាប់រឿងនេះ សូម្បីតែ ClickHouse មានប្រភេទតារាងពិសេស AggregatingMergeTree ដែលដំណើរការការប្រមូលផ្តុំបន្ថែមនៅពេលដែលទិន្នន័យត្រូវបានបញ្ចូល។

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

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

ហើយអ្វីដែលពិសេសនោះ? ការពិតគឺថា ពេលខ្លះមនុស្សទាំងនេះមកពីនាយកដ្ឋានជិតខាងបានទៅសុំបន្ថែមជួរឈរមួយទៀតទៅសោចម្បង។ នោះគឺយើងបានប្រមូលផ្តុំទិន្នន័យដូចនេះ ប៉ុន្តែឥឡូវនេះយើងចង់បានបន្ថែមទៀត។ ប៉ុន្តែ ClickHouse មិនមានសោចម្បងផ្លាស់ប្តូរទេ។ ដូច្នេះ​ហើយ យើង​ត្រូវ​សរសេរ​អក្សរ​ខ្លះ​ក្នុង C++។ ហើយ​ខ្ញុំ​មិន​ចូល​ចិត្ត​ស្គ្រីប​ទេ ទោះ​បី​ជា​វា​នៅ​ក្នុង C++ ក៏ដោយ។

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

ករណីគួរឱ្យចាប់អារម្មណ៍មួយទៀតគឺសំណួរនៅក្នុងរង្វិលជុំគ្មានកំណត់។ ពេល​ខ្លះ​ខ្ញុំ​ទៅ​កាន់​ម៉ាស៊ីន​បម្រើ​ផលិតកម្ម​មួយ​ចំនួន ហើយ​មើល​បញ្ជី​ដំណើរការ​នៅ​ទីនោះ។ ហើយរាល់ពេលដែលខ្ញុំដឹងថាមានរឿងដ៏អាក្រក់មួយកំពុងកើតឡើង។

ឧទាហរណ៍ដូចនេះ។ វាច្បាស់ណាស់ថាអ្វីៗទាំងអស់អាចធ្វើបានក្នុងសំណើមួយ។ គ្រាន់តែសរសេរ url និងបញ្ជីនៅទីនោះ។

ហេតុអ្វីបានជាសំណួរបែបនេះជាច្រើននៅក្នុងរង្វិលជុំគ្មានទីបញ្ចប់មិនល្អ? ប្រសិនបើលិបិក្រមមិនត្រូវបានប្រើទេ នោះអ្នកនឹងមានការឆ្លងកាត់ជាច្រើនលើទិន្នន័យដូចគ្នា។ ប៉ុន្តែប្រសិនបើលិបិក្រមត្រូវបានប្រើ ឧទាហរណ៍ អ្នកមានកូនសោចម្បងសម្រាប់ ru ហើយអ្នកសរសេរ url = អ្វីមួយនៅទីនោះ។ ហើយអ្នកគិតថាប្រសិនបើមានតែ URL មួយត្រូវបានអានពីតារាង នោះអ្វីៗនឹងល្អ។ ប៉ុន្តែតាមពិតទេ។ ដោយសារតែ ClickHouse ធ្វើអ្វីគ្រប់យ៉ាងជាបាច់។

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

ហើយជាប្រាក់រង្វាន់ អ្នកអាចកត់សម្គាល់ថានៅក្នុង ClickHouse អ្នកមិនគួរភ័យខ្លាចក្នុងការផ្ទេរសូម្បីតែមេកាបៃ និងរាប់រយមេហ្គាបៃទៅផ្នែក IN ។ ខ្ញុំចាំពីការអនុវត្តរបស់យើងថាប្រសិនបើនៅក្នុង MySQL យើងផ្ទេរតម្លៃជាច្រើនទៅផ្នែក IN ឧទាហរណ៍យើងផ្ទេរ 100 មេកាបៃនៃលេខមួយចំនួននៅទីនោះ បន្ទាប់មក MySQL ស៊ីអង្គចងចាំ 10 ជីហ្គាបៃ ហើយគ្មានអ្វីផ្សេងទៀតកើតឡើងចំពោះវាទេ។ ដំណើរការមិនល្អ។

ហើយទីពីរគឺថានៅក្នុង ClickHouse ប្រសិនបើសំណួររបស់អ្នកប្រើលិបិក្រម នោះវាមិនតែងតែយឺតជាងការស្កេនពេញលេញនោះទេ ពោលគឺប្រសិនបើអ្នកត្រូវការអានស្ទើរតែតារាងទាំងមូល វានឹងបន្តបន្ទាប់គ្នា ហើយអានតារាងទាំងមូល។ ជាទូទៅគាត់នឹងដោះស្រាយដោយខ្លួនឯង។

ប៉ុន្តែ​ទោះ​ជា​យ៉ាង​ណា​ក៏​មាន​ការ​លំបាក​ខ្លះ​ដែរ។ ឧទាហរណ៍ ការពិតដែលថា IN ជាមួយ subquery មិនប្រើលិបិក្រមទេ។ ប៉ុន្តែនេះគឺជាបញ្ហារបស់យើង ហើយយើងត្រូវដោះស្រាយវា។ មិនមានអ្វីជាមូលដ្ឋាននៅទីនេះទេ។ យើងនឹងជួសជុលវា * ។

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

* ប្រើរួចហើយ; អ្វីគ្រប់យ៉ាងត្រូវបានជួសជុលដូចដែលបានសន្យា។

ហើយករណីធម្មតាមួយគឺនៅពេលដែលសំណើមកពី API ។ ឧទាហរណ៍ អ្នកបានបង្កើតសេវាកម្មផ្ទាល់ខ្លួនរបស់អ្នក។ ហើយប្រសិនបើនរណាម្នាក់ត្រូវការសេវាកម្មរបស់អ្នក នោះអ្នកបើក API ហើយពីរថ្ងៃក្រោយមកអ្នកឃើញថាមានអ្វីមួយដែលមិនអាចយល់បានកំពុងកើតឡើង។ អ្វីគ្រប់យ៉ាងគឺលើសទម្ងន់ហើយសំណើដ៏គួរឱ្យភ័យខ្លាចមួយចំនួនបានចូលមកដែលមិនគួរកើតឡើង។

ហើយមានដំណោះស្រាយតែមួយគត់។ ប្រសិនបើអ្នកបានបើក API នោះអ្នកនឹងត្រូវកាត់វា។ ជាឧទាហរណ៍ សូមណែនាំប្រភេទកូតាមួយចំនួន។ មិនមានជម្រើសធម្មតាផ្សេងទៀតទេ។ បើមិនដូច្នោះទេពួកគេនឹងសរសេរស្គ្រីបភ្លាមៗហើយនឹងមានបញ្ហា។

ហើយ ClickHouse មានលក្ខណៈពិសេសមួយ - ការគណនាកូតា។ លើសពីនេះទៅទៀត អ្នកអាចផ្ទេរសោកូតារបស់អ្នក។ ជាឧទាហរណ៍ លេខសម្គាល់អ្នកប្រើប្រាស់ខាងក្នុង។ ហើយកូតានឹងត្រូវបានគណនាដោយឯករាជ្យសម្រាប់ពួកគេម្នាក់ៗ។

ឥឡូវនេះរឿងគួរឱ្យចាប់អារម្មណ៍មួយទៀត។ នេះគឺជាការចម្លងដោយដៃ។

ខ្ញុំដឹងពីករណីជាច្រើនដែលទោះបីជា ClickHouse មានការគាំទ្រការចម្លងដែលភ្ជាប់មកជាមួយក៏ដោយ ក៏មនុស្សចម្លង ClickHouse ដោយដៃ។

តើអ្វីជាគោលការណ៍? អ្នកមានបំពង់ដំណើរការទិន្នន័យ។ ហើយវាដំណើរការដោយឯករាជ្យឧទាហរណ៍នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នា។ អ្នកសរសេរទិន្នន័យដូចគ្នាតាមរបៀបដូចគ្នានៅក្នុង ClickHouse ។ ពិត ការអនុវត្តបង្ហាញថាទិន្នន័យនឹងនៅតែខុសគ្នាដោយសារលក្ខណៈពិសេសមួយចំនួននៅក្នុងកូដរបស់អ្នក។ ខ្ញុំសង្ឃឹមថាវាស្ថិតនៅក្នុងរបស់អ្នក។

ហើយពីពេលមួយទៅពេលមួយ អ្នកនឹងនៅតែត្រូវធ្វើសមកាលកម្មដោយដៃ។ ឧទាហរណ៍ ម្តងក្នុងមួយខែអ្នកគ្រប់គ្រងធ្វើ rsync ។

តាមពិតទៅ វាកាន់តែងាយស្រួលប្រើការចម្លងដែលបានបង្កើតឡើងនៅក្នុង ClickHouse ។ ប៉ុន្តែវាអាចមាន contraindications មួយចំនួនព្រោះសម្រាប់ការនេះអ្នកត្រូវប្រើ ZooKeeper ។ ខ្ញុំនឹងមិននិយាយអ្វីអាក្រក់អំពី ZooKeeper ជាគោលការណ៍ប្រព័ន្ធដំណើរការទេ ប៉ុន្តែវាកើតឡើងដែលមនុស្សមិនប្រើវាដោយសារតែ java-phobia ពីព្រោះ ClickHouse គឺជាប្រព័ន្ធដ៏ល្អមួយ ដែលសរសេរជា C++ ដែលអ្នកអាចប្រើ និង អ្វី​គ្រប់យ៉ាង​នឹង​ល្អ​ប្រសើរ​ឡើង ។ ហើយ ZooKeeper គឺនៅក្នុង java ។ ហើយដូចម្ដេចដែលអ្នកមិនចង់មើល ប៉ុន្តែបន្ទាប់មកអ្នកអាចប្រើការចម្លងដោយដៃ។

ClickHouse គឺជាប្រព័ន្ធអនុវត្តជាក់ស្តែង។ នាងគិតពីតម្រូវការរបស់អ្នក។ ប្រសិនបើអ្នកមានការចម្លងដោយដៃ នោះអ្នកអាចបង្កើតតារាងចែកចាយដែលមើលការចម្លងដោយដៃរបស់អ្នក ហើយធ្វើការបរាជ័យរវាងពួកវា។ ហើយមានសូម្បីតែជម្រើសពិសេសដែលអនុញ្ញាតឱ្យអ្នកជៀសវាងការរអិល ទោះបីជាខ្សែរបស់អ្នកបែកគ្នាជាប្រព័ន្ធក៏ដោយ។

បញ្ហាបន្ថែមទៀតអាចកើតឡើងប្រសិនបើអ្នកប្រើម៉ាស៊ីនតារាងបុព្វកាល។ ClickHouse គឺជាអ្នកសាងសង់ដែលមានម៉ាស៊ីនតារាងផ្សេងៗគ្នា។ សម្រាប់ករណីធ្ងន់ធ្ងរទាំងអស់ ដូចដែលបានសរសេរនៅក្នុងឯកសារ សូមប្រើតារាងពីគ្រួសារ MergeTree ។ ហើយនៅសល់ទាំងអស់ - នេះគឺដូច្នេះសម្រាប់ករណីបុគ្គលឬសម្រាប់ការធ្វើតេស្ត។

នៅក្នុងតារាង MergeTree អ្នកមិនចាំបាច់មានកាលបរិច្ឆេទ និងពេលវេលាទេ។ អ្នកនៅតែអាចប្រើវាបាន។ ប្រសិនបើមិនមានកាលបរិច្ឆេទ និងពេលវេលាទេ សូមសរសេរថាលំនាំដើមគឺ 2000។ វានឹងដំណើរការ ហើយនឹងមិនត្រូវការធនធានទេ។

ហើយនៅក្នុងកំណែថ្មីនៃម៉ាស៊ីនមេ អ្នកថែមទាំងអាចបញ្ជាក់បានថាអ្នកមានការបែងចែកតាមបំណងដោយមិនមានសោភាគថាស។ វានឹងដូចគ្នា។

ម្យ៉ាងវិញទៀត អ្នកអាចប្រើម៉ាស៊ីនតារាងបុព្វកាល។ ឧទាហរណ៍ បំពេញទិន្នន័យម្តង ហើយមើល បង្វិល និងលុប។ អ្នកអាចប្រើ Log ។

ឬរក្សាទុកភាគតូចសម្រាប់ដំណើរការកម្រិតមធ្យមគឺ StripeLog ឬ TinyLog ។

អង្គចងចាំអាចប្រើប្រាស់បាន ប្រសិនបើចំនួនទិន្នន័យតូច ហើយអ្នកអាចបង្វិលអ្វីមួយនៅក្នុង RAM បាន។

ClickHouse ពិតជាមិនចូលចិត្តទិន្នន័យដែលបានកែប្រែឡើងវិញទេ។

នេះជាឧទាហរណ៍ធម្មតា។ នេះគឺជាចំនួនដ៏ច្រើននៃ URLs ។ អ្នកដាក់វានៅក្នុងតារាងបន្ទាប់។ ហើយបន្ទាប់មកពួកគេបានសម្រេចចិត្តធ្វើ JOIN ជាមួយពួកគេ ប៉ុន្តែនេះនឹងមិនដំណើរការទេ ជាក្បួន ព្រោះ ClickHouse គាំទ្រតែ Hash JOIN ប៉ុណ្ណោះ។ ប្រសិនបើមិនមាន RAM គ្រប់គ្រាន់សម្រាប់ទិន្នន័យជាច្រើនដែលត្រូវការភ្ជាប់ នោះ JOIN នឹងមិនដំណើរការ*។

ប្រសិនបើទិន្នន័យមានអត្រាខ្ពស់ នោះកុំបារម្ភ រក្សាទុកវាក្នុងទម្រង់មិនប្រក្រតី URLs ដោយផ្ទាល់នៅក្នុងតារាងមេ។

* ហើយឥឡូវនេះ ClickHouse ក៏មានការរួមបញ្ចូលគ្នាផងដែរ ហើយវាដំណើរការក្នុងលក្ខខណ្ឌដែលទិន្នន័យកម្រិតមធ្យមមិនសមនឹង RAM ។ ប៉ុន្តែនេះមិនមានប្រសិទ្ធភាពទេ ហើយអនុសាសន៍នៅតែមានជាធរមាន។

ឧទាហរណ៍ពីរបីទៀត ប៉ុន្តែខ្ញុំសង្ស័យរួចហើយថាតើពួកគេប្រឆាំងឬអត់។

ClickHouse មានគុណវិបត្តិដែលគេស្គាល់មួយ។ វាមិនដឹងពីរបៀបអាប់ដេត*។ នៅក្នុងវិធីមួយចំនួននេះសូម្បីតែល្អ។ ប្រសិនបើអ្នកមានទិន្នន័យសំខាន់ៗមួយចំនួន ឧទាហរណ៍ គណនេយ្យ នោះគ្មាននរណាម្នាក់នឹងអាចផ្ញើវាបានទេ ព្រោះមិនមានការធ្វើបច្ចុប្បន្នភាព។

* ការ​គាំទ្រ​សម្រាប់​ការ​ធ្វើ​ឱ្យ​ទាន់​សម័យ​និង​លុប​ក្នុង​របៀប​បាច់​ត្រូវ​បាន​បន្ថែម​ជា​យូរ​មក​ហើយ​។

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

ការចូលរួមដែលបានចែកចាយនៅក្នុង ClickHouse ក៏ត្រូវបានដោះស្រាយយ៉ាងលំបាកដោយអ្នករៀបចំផែនការសំណួរផងដែរ។

អាក្រក់ ប៉ុន្តែពេលខ្លះ Ok។

ដោយប្រើ ClickHouse ដើម្បីអានទិន្នន័យត្រឡប់មកវិញដោយប្រើជ្រើសរើស*។

ខ្ញុំនឹងមិនណែនាំឱ្យប្រើ ClickHouse សម្រាប់ការគណនាដ៏ស្មុគស្មាញនោះទេ។ ប៉ុន្តែនេះមិនមែនជាការពិតទាំងស្រុងនោះទេ ពីព្រោះយើងកំពុងចាកចេញពីការណែនាំនេះរួចហើយ។ ហើយថ្មីៗនេះ យើងបានបន្ថែមសមត្ថភាពក្នុងការអនុវត្តគំរូរៀនម៉ាស៊ីននៅក្នុង ClickHouse - Catboost ។ ហើយ​វា​រំខាន​ខ្ញុំ​ដោយ​សារ​តែ​ខ្ញុំ​គិត​ថា “តើ​គួរ​ឲ្យ​រន្ធត់​មែន​ទែន។ នេះជាចំនួនវដ្តក្នុងមួយបៃដែលវាប្រែចេញ! ខ្ញុំពិតជាស្អប់ខ្ជះខ្ជាយនាឡិកាលើបៃ។

ប៉ុន្តែកុំភ័យខ្លាច ដំឡើង ClickHouse អ្វីគ្រប់យ៉ាងនឹងល្អ។ ប្រសិនបើមានអ្វី យើងមានសហគមន៍។ និយាយអញ្ចឹងសហគមន៍គឺអ្នក។ ហើយប្រសិនបើអ្នកមានបញ្ហាណាមួយ យ៉ាងហោចណាស់អ្នកអាចចូលទៅកាន់ការជជែករបស់យើង ហើយសង្ឃឹមថាពួកគេនឹងជួយអ្នក។

សំណួរ

អរគុណសម្រាប់របាយការណ៍! តើខ្ញុំអាចត្អូញត្អែរអំពីការគាំង ClickHouse នៅឯណា?

អ្នកអាចត្អូញត្អែរមកខ្ញុំផ្ទាល់ឥឡូវនេះ។

ថ្មីៗនេះខ្ញុំបានចាប់ផ្តើមប្រើ ClickHouse ។ ខ្ញុំបានទម្លាក់ចំណុចប្រទាក់ cli ភ្លាមៗ។

ពិន្ទុអ្វី។

បន្តិចក្រោយមក ខ្ញុំបានគាំងម៉ាស៊ីនមេជាមួយនឹងការជ្រើសរើសតូចមួយ។

អ្នកមានទេពកោសល្យ។

ខ្ញុំបានបើកកំហុស GitHub ប៉ុន្តែវាមិនត្រូវបានគេអើពើទេ។

យើងនឹងឃើញ។

Alexey បានបោកបញ្ឆោតខ្ញុំឱ្យចូលរួមក្នុងរបាយការណ៍ដោយសន្យាថានឹងប្រាប់ខ្ញុំពីរបៀបដែលអ្នកចូលប្រើទិន្នន័យនៅខាងក្នុង។

សាមញ្ញ​ណាស់។

ខ្ញុំបានដឹងរឿងនេះកាលពីម្សិលមិញ។ ជាក់លាក់បន្ថែមទៀត។

មិនមានល្បិចដ៏គួរឱ្យភ័យខ្លាចនៅទីនោះទេ។ មានតែការបង្ហាប់ប្លុកដោយប្លុកប៉ុណ្ណោះ។ លំនាំដើមគឺ LZ4 អ្នកអាចបើក ZSTD*។ ប្លុកពី 64 គីឡូបៃទៅ 1 មេកាបៃ។

* វាក៏មានការគាំទ្រសម្រាប់កូឌិកបង្ហាប់ពិសេសដែលអាចត្រូវបានប្រើនៅក្នុងខ្សែសង្វាក់ជាមួយក្បួនដោះស្រាយផ្សេងទៀត។

តើប្លុកគ្រាន់តែជាទិន្នន័យឆៅទេ?

មិនឆៅទាំងស្រុង។ មានអារេ។ ប្រសិនបើអ្នកមានជួរឈរលេខ នោះលេខក្នុងជួរដេកមួយត្រូវបានដាក់ក្នុងអារេមួយ។

វាច្បាស់ហើយ។

Alexey ជាឧទាហរណ៍មួយដែលនៅជាមួយ uniqExact លើ IPs ពោលគឺការពិតដែលថា uniqExact ត្រូវការពេលយូរក្នុងការគណនាតាមបន្ទាត់ជាងដោយលេខ ហើយដូច្នេះនៅលើ។ ចុះ​បើ​យើង​ប្រើ​ការ​ក្លែង​ត្រចៀក​ហើយ​បោះ​ចោល​នៅ​ពេល​អាន​ភស្តុតាង? នោះគឺអ្នកហាក់ដូចជាបាននិយាយថានៅលើថាសរបស់យើងវាមិនខុសគ្នាខ្លាំងទេ។ ប្រសិនបើយើងអានបន្ទាត់ពីឌីស និងខាស តើការប្រមូលផ្តុំរបស់យើងលឿនជាងឬអត់? ឬតើយើងនឹងនៅតែទទួលបានតិចតួចនៅទីនេះ? វាហាក់ដូចជាខ្ញុំដែលអ្នកបានសាកល្បងវា ប៉ុន្តែសម្រាប់ហេតុផលមួយចំនួនមិនបានបង្ហាញពីវានៅក្នុងគោល។

ខ្ញុំគិតថាវានឹងយឺតជាងបើគ្មានការសម្ដែង។ ក្នុងករណីនេះ អាសយដ្ឋាន IP ត្រូវតែញែកចេញពីខ្សែអក្សរ។ ជាការពិតណាស់នៅ ClickHouse ការញែកអាសយដ្ឋាន IP របស់យើងក៏ត្រូវបានធ្វើឱ្យប្រសើរផងដែរ។ យើង​បាន​ព្យាយាម​យ៉ាង​ខ្លាំង ប៉ុន្តែ​នៅ​ទីនោះ អ្នក​មាន​លេខ​សរសេរ​ក្នុង​ទម្រង់​មួយ​ម៉ឺន។ មិនស្រួលខ្លាំងណាស់។ ម្យ៉ាងវិញទៀត មុខងារ uniqExact នឹងដំណើរការយឺតជាងនៅលើខ្សែអក្សរ មិនត្រឹមតែដោយសារតែទាំងនេះជាខ្សែប៉ុណ្ណោះទេ ប៉ុន្តែក៏ដោយសារតែឯកទេសផ្សេងគ្នានៃក្បួនដោះស្រាយត្រូវបានជ្រើសរើសផងដែរ។ ខ្សែអក្សរត្រូវបានដំណើរការយ៉ាងសាមញ្ញខុសគ្នា។

ចុះបើយើងយកប្រភេទទិន្នន័យបឋមជាង? ឧទាហរណ៍ យើងសរសេរលេខសម្គាល់អ្នកប្រើប្រាស់ដែលយើងមាន សរសេរជាបន្ទាត់ រួចវាយវាចុះ វានឹងកាន់តែសប្បាយឬអត់?

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

Alexey អរគុណច្រើនសម្រាប់របាយការណ៍! ហើយសូមថ្លែងអំណរគុណយ៉ាងជ្រាលជ្រៅចំពោះ ClickHouse! ខ្ញុំមានសំណួរអំពីផែនការ។ តើមានគម្រោងសម្រាប់លក្ខណៈពិសេសដើម្បីធ្វើបច្ចុប្បន្នភាពវចនានុក្រមមិនពេញលេញទេ?

នោះគឺជាការចាប់ផ្ដើមឡើងវិញដោយផ្នែក?

បាទ​បាទ។ ដូចជាសមត្ថភាពក្នុងការកំណត់វាល MySQL នៅទីនោះ ឧ. ធ្វើបច្ចុប្បន្នភាពបន្ទាប់ពីនោះ មានតែទិន្នន័យនេះប៉ុណ្ណោះដែលត្រូវបានផ្ទុកប្រសិនបើវចនានុក្រមមានទំហំធំណាស់។

លក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍ណាស់។ ហើយខ្ញុំគិតថាមាននរណាម្នាក់បានណែនាំវានៅក្នុងការជជែករបស់យើង។ ប្រហែលជាសូម្បីតែអ្នកក៏ដោយ។

ខ្ញុំមិនគិតដូច្នេះទេ។

ល្អណាស់ ឥឡូវនេះវាប្រែថាមានសំណើពីរ។ ហើយអ្នកអាចចាប់ផ្តើមធ្វើវាបន្តិចម្តងៗ។ ប៉ុន្តែខ្ញុំចង់ព្រមានអ្នកភ្លាមៗថាមុខងារនេះគឺសាមញ្ញណាស់ក្នុងការអនុវត្ត។ នោះគឺតាមទ្រឹស្ដី អ្នកគ្រាន់តែត្រូវសរសេរលេខកំណែក្នុងតារាង ហើយបន្ទាប់មកសរសេរ៖ កំណែតិចជាង និងបែបនោះ។ នេះមានន័យថា ភាគច្រើនទំនងជាយើងនឹងផ្តល់ជូនអ្នកចូលចិត្ត។ តើអ្នកជាអ្នកចូលចិត្តទេ?

បាទ/ចាស ប៉ុន្តែជាអកុសល មិនមែននៅក្នុង C++ ទេ។

តើមិត្តរួមការងាររបស់អ្នកចេះសរសេរ C++ ដែរឬទេ?

ខ្ញុំនឹងស្វែងរកនរណាម្នាក់។

អស្ចារ្យ * ។

* លក្ខណៈពិសេសត្រូវបានបន្ថែមពីរខែបន្ទាប់ពីរបាយការណ៍ - អ្នកនិពន្ធសំណួរបានបង្កើតវាហើយផ្ញើរបស់គាត់។ ទាញសំណើ.

សូមអរគុណ!

សួស្តី! អរគុណសម្រាប់របាយការណ៍! អ្នកបាននិយាយថា ClickHouse គឺល្អណាស់ក្នុងការប្រើប្រាស់ធនធានទាំងអស់ដែលមានសម្រាប់វា។ ហើយ​វាគ្មិន​នៅ​ក្បែរ Luxoft បាន​និយាយ​អំពី​ដំណោះ​ស្រាយ​របស់​គាត់​សម្រាប់ Russian Post។ គាត់បាននិយាយថាពួកគេពិតជាចូលចិត្ត ClickHouse ប៉ុន្តែពួកគេមិនបានប្រើវាជំនួសដៃគូប្រកួតប្រជែងសំខាន់របស់ពួកគេនោះទេព្រោះវាស៊ីស៊ីភីយូទាំងអស់។ ហើយពួកគេមិនអាចដោតវាទៅក្នុងស្ថាបត្យកម្មរបស់ពួកគេ ចូលទៅក្នុង ZooKeeper របស់ពួកគេជាមួយនឹង dockers បានទេ។ តើវាអាចទៅរួចទេក្នុងការកំណត់ ClickHouse ដើម្បីកុំឱ្យវាប្រើប្រាស់អ្វីៗទាំងអស់ដែលមានសម្រាប់វា?

បាទ វាអាចទៅរួច និងងាយស្រួលណាស់។ ប្រសិនបើអ្នកចង់ប្រើប្រាស់ស្នូលតិច នោះគ្រាន់តែសរសេរ set max_threads = 1. ហើយនោះហើយជាវា វានឹងប្រតិបត្តិសំណើក្នុងស្នូលមួយ។ លើសពីនេះទៅទៀត អ្នកអាចបញ្ជាក់ការកំណត់ផ្សេងៗសម្រាប់អ្នកប្រើប្រាស់ផ្សេងៗគ្នា។ ដូច្នេះគ្មានបញ្ហាទេ។ ហើយប្រាប់សហការីរបស់អ្នកពី Luxoft ថាវាមិនល្អទេដែលពួកគេមិនបានរកឃើញការកំណត់នេះនៅក្នុងឯកសារ។

Alexey ជំរាបសួរ! ខ្ញុំចង់សួរអំពីសំណួរនេះ។ នេះមិនមែនជាលើកទីមួយទេដែលខ្ញុំបានលឺថាមនុស្សជាច្រើនចាប់ផ្តើមប្រើ ClickHouse ជាកន្លែងផ្ទុកសម្រាប់កំណត់ហេតុ។ នៅ​ក្នុង​របាយការណ៍ អ្នក​បាន​និយាយ​ថា​កុំ​ធ្វើ​បែប​នេះ ពោល​គឺ​អ្នក​មិន​ត្រូវ​ការ​ទុក​ខ្សែ​វែង​ទេ។ តើ​អ្នក​គិត​យ៉ាង​ណា​ចំពោះ​វា?

ទីមួយ កំណត់ហេតុជាក្បួនមិនមែនជាខ្សែវែងទេ។ ជាការពិតណាស់មានករណីលើកលែង។ ឧទាហរណ៍ សេវាមួយចំនួនដែលសរសេរក្នុង java បោះករណីលើកលែងមួយ វាត្រូវបានកត់ត្រាទុក។ ហើយដូច្នេះនៅលើរង្វិលជុំគ្មានទីបញ្ចប់ហើយចន្លោះនៅលើដ្រាយវ៍រឹងនឹងអស់។ ដំណោះស្រាយគឺសាមញ្ញណាស់។ ប្រសិនបើបន្ទាត់វែងណាស់បន្ទាប់មកកាត់វា។ តើយូរមានន័យយ៉ាងណា? រាប់សិបគីឡូបៃគឺអាក្រក់*។

* នៅក្នុងកំណែចុងក្រោយបំផុតរបស់ ClickHouse "ការកែប្រែសន្ទស្សន៍អាដាប់ធ័រ" ត្រូវបានបើក ដែលលុបបំបាត់បញ្ហានៃការរក្សាទុកជួរវែងសម្រាប់ផ្នែកភាគច្រើន។

តើគីឡូបៃធម្មតាទេ?

វាជារឿងធម្មតា។

សួស្តី! អរគុណសម្រាប់របាយការណ៍! ខ្ញុំបានសួរអំពីរឿងនេះរួចហើយនៅក្នុងការជជែក ប៉ុន្តែខ្ញុំមិនចាំថាខ្ញុំបានទទួលចម្លើយទេ។ តើមានគម្រោងពង្រីកផ្នែក WITH តាមរបៀប CTE ដែរឬទេ?

នៅឡើយ។ ផ្នែក WITH របស់យើងគឺមានភាពច្របូកច្របល់បន្តិច។ វាដូចជាលក្ខណៈពិសេសតូចមួយសម្រាប់យើង។

ខ្ញុំ​យល់។ សូមអរគុណ!

អរគុណសម្រាប់របាយការណ៍! គួរ​ឱ្យ​ចាប់អារម្មណ៍​ណាស់! សំណួរសកល។ តើ​មាន​គម្រោង​កែប្រែ​ការ​លុប​ទិន្នន័យ ប្រហែល​ជា​ក្នុង​ទម្រង់​នៃ​ stubs ខ្លះ​ដែរ​ឬ​ទេ?

ចាំបាច់។ នេះគឺជាកិច្ចការដំបូងរបស់យើងនៅក្នុងជួររបស់យើង។ ឥឡូវនេះយើងកំពុងគិតយ៉ាងសកម្មអំពីរបៀបធ្វើអ្វីគ្រប់យ៉ាងឱ្យបានត្រឹមត្រូវ។ ហើយអ្នកគួរតែចាប់ផ្តើមចុចក្តារចុច*។

* ចុចប៊ូតុងនៅលើក្តារចុចហើយធ្វើអ្វីៗគ្រប់យ៉ាង។

តើនេះអាចប៉ះពាល់ដល់ដំណើរការប្រព័ន្ធឬអត់? តើ​ការ​បញ្ចូល​នឹង​លឿន​ដូច​ពេល​នេះ​ទេ?

ប្រហែលជាការលុបខ្លួនឯង ហើយការអាប់ដេតខ្លួនឯងនឹងធ្ងន់ណាស់ ប៉ុន្តែវានឹងមិនប៉ះពាល់ដល់ដំណើរការនៃជម្រើស ឬដំណើរការបញ្ចូលទេ។

និងសំណួរតូចមួយទៀត។ នៅឯបទបង្ហាញ អ្នកបាននិយាយអំពីសោចម្បង។ ដូច្នោះហើយ យើងមានការបែងចែកជាប្រចាំខែតាមលំនាំដើម តើត្រូវទេ? ហើយ​ពេល​យើង​កំណត់​ជួរ​កាលបរិច្ឆេទ​ដែល​សម​នឹង​មួយ​ខែ​នោះ​មាន​តែ​ភាគ​ថា​ស​នេះ​ត្រូវ​បាន​អាន​ទេ?

បាទ។

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

បាទ។

ប្រហែលជាវាសមហេតុផលក្នុងការដាក់វាលមួយនៅក្នុងសោចម្បងដែលនឹងបង្រួមទិន្នន័យបានប្រសើរជាងប្រសិនបើវាត្រូវបានតម្រៀបតាមវាលនេះ។ ឧទាហរណ៍ លេខសម្គាល់អ្នកប្រើប្រាស់។ ជាឧទាហរណ៍ អ្នកប្រើប្រាស់ចូលទៅកាន់គេហទំព័រដូចគ្នា។ ក្នុងករណីនេះដាក់លេខសម្គាល់អ្នកប្រើប្រាស់និងពេលវេលា។ ហើយបន្ទាប់មកទិន្នន័យរបស់អ្នកនឹងត្រូវបានបង្ហាប់ប្រសើរជាងមុន។ ចំពោះកាលបរិច្ឆេទ ប្រសិនបើអ្នកពិតជាមិនមាន និងមិនដែលមានសំណួរជួរនៅលើកាលបរិច្ឆេទ នោះអ្នកមិនចាំបាច់ដាក់កាលបរិច្ឆេទនៅក្នុងគន្លឹះចម្បងនោះទេ។

OK អរគុណច្រើន!

ប្រភព: www.habr.com