ClickHouse សម្រាប់អ្នកប្រើប្រាស់កម្រិតខ្ពស់នៅក្នុងសំណួរ និងចម្លើយ

នៅក្នុងខែមេសា វិស្វករ Avito បានប្រមូលផ្តុំគ្នាសម្រាប់ការប្រជុំតាមអ៊ីនធឺណិតជាមួយអ្នកអភិវឌ្ឍន៍ ClickHouse សំខាន់ Alexey Milvidov និង Kirill Shvakov ដែលជាអ្នកអភិវឌ្ឍន៍ Golang មកពីក្រុមហ៊ុន Integros ។ យើងបានពិភាក្សាអំពីរបៀបដែលយើងប្រើប្រព័ន្ធគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ និងការលំបាកអ្វីខ្លះដែលយើងជួបប្រទះ។

ដោយផ្អែកលើការប្រជុំ យើងបានចងក្រងអត្ថបទមួយដែលមានចម្លើយរបស់អ្នកជំនាញចំពោះសំណួររបស់យើង និងទស្សនិកជនអំពីការបម្រុងទុក ការបញ្ជូនទិន្នន័យឡើងវិញ វចនានុក្រមខាងក្រៅ កម្មវិធីបញ្ជា Golang និងការអាប់ដេតកំណែ ClickHouse ។ វាអាចមានប្រយោជន៍សម្រាប់អ្នកអភិវឌ្ឍន៍ដែលធ្វើការយ៉ាងសកម្មជាមួយ Yandex DBMS ហើយចាប់អារម្មណ៍លើបច្ចុប្បន្ន និងអនាគតរបស់វា។ តាមលំនាំដើម ចម្លើយគឺមកពី Alexey Milovidov លុះត្រាតែសរសេរផ្សេង។

សូមប្រយ័ត្ន មានអត្ថបទជាច្រើននៅក្រោមការកាត់។ យើងសង្ឃឹមថាខ្លឹមសារដែលមានសំណួរនឹងជួយអ្នកក្នុងការរុករក។

មាតិកា

• ClickHouse ត្រូវបានធ្វើបច្ចុប្បន្នភាពឥតឈប់ឈរ ប៉ុន្តែទិន្នន័យរបស់យើងគឺមិនមែនទេ។ អ្វីដែលត្រូវធ្វើអំពីវា?
• តើអ្វីជាការអនុវត្តល្អបំផុតនាពេលបច្ចុប្បន្នសម្រាប់ការបម្រុងទុកទិន្នន័យពី ClickHouse?
• តើវាអាចទៅរួចទេក្នុងការរៀបចំភាពយឺតយ៉ាវដែលអាចគ្រប់គ្រងបាននៃការចម្លងនៅក្នុង shafts ?
• ចុះបើរចនាសម្ព័ន្ធតារាងបានផ្លាស់ប្តូរ?
• តើអ្វីជាការអនុវត្តល្អបំផុតនាពេលបច្ចុប្បន្នក្នុងការបញ្ជូនទិន្នន័យឡើងវិញ?
• ClickHouse មានឧបករណ៍ប្រើប្រាស់ clickhouse-copier ។ តើអ្នកអាចប្រាប់យើងអំពីនាងបានទេ?
• អ្នក​មាន​អ្វី​ដែល​អ្នក​បើក​យន្តហោះ​ហៅ​ថា​ការ​បញ្ជូន​បន្ត។ ចុះនាងវិញ?
• តើវាអាចទៅរួចទេក្នុងការបញ្ចូលបំណែកទិន្នន័យទាំងអស់ចូលគ្នា មុនពេលផ្លាស់ទីវាទៅថាសយឺត?
• តើធ្វើដូចម្តេចដើម្បីធ្វើចំណាកស្រុកទៅកំណែថ្មីរបស់ ClickHouse ប្រសិនបើមិនមានវិធីដើម្បីពិនិត្យមើលភាពឆបគ្នាជាមុនទេ?
• Kill query សន្មត់ថាសម្លាប់ queries ប៉ុន្តែវាមិនមែនទេ។ ហេតុអ្វី?
• តើធ្វើដូចម្តេចដើម្បីគណនាពេលវេលាឆ្លើយតបនៅក្រោមការផ្ទុកអាន?
• តើខ្ញុំអាចកែប្រែអ្វីខ្លះនៅក្នុង ClickHouse ដើម្បីឱ្យទិន្នន័យកាន់តែច្រើននៅក្នុងឃ្លាំងសម្ងាត់?
• តើខ្ញុំអាចកំណត់រចនាសម្ព័ន្ធ storage_configuration សម្រាប់ការផ្ទុកនៅក្នុង RAM ដោយរបៀបណា?
• តើ Low Cardinality មានប្រសិទ្ធភាពដល់កម្រិតណាខ្លះ?
• តើអ្វីជាការអនុវត្តល្អបំផុតសម្រាប់ការស្វែងរកអត្ថបទពេញតារាងដែលមានប្រាំពាន់លានជួរ?
• តើអ្វីជាវិធីល្អបំផុតក្នុងការរៀបចំការចូលទៅកាន់ ClickHouse សម្រាប់អ្នកប្រើប្រាស់មួយចំនួនធំ?
• តើវាអាចទៅរួចទេក្នុងការផ្តល់លទ្ធផលនៃសំណួរមួយទៅកាន់អតិថិជនដប់?
• ចុះប្រតិបត្តិការអសមកាល និងទិដ្ឋភាពជាក់ស្តែង?
• ClickHouse មានកំណត់ហេតុជាច្រើន។ តើខ្ញុំអាចមើលអ្វីគ្រប់យ៉ាងដែលកំពុងកើតឡើងជាមួយម៉ាស៊ីនមេនៅពេលណាមួយបានដោយរបៀបណា?
• តើធ្វើដូចម្តេចដើម្បីមានឥទ្ធិពលលើការរួមបញ្ចូលគ្នាដើម្បីកុំឱ្យ server ធ្លាក់ចូលទៅក្នុង OOM?
• តើការអភិវឌ្ឍន៍កម្មវិធីបញ្ជា Golang សម្រាប់ ClickHouse នឹងដំណើរការយ៉ាងដូចម្តេច?
• វចនានុក្រម​ខាង​ក្រៅ​មិន​ដំណើរការ​ទេ បន្ទាប់​ពី​ចាប់ផ្ដើម​ឡើង​វិញ​ដោយ​បើក​ការ​កំណត់ lazy_load។ អ្វី​ដែល​ត្រូវធ្វើ?
• អ្វីដែលត្រូវធ្វើជាមួយការពិតដែលថាវចនានុក្រមផ្ទុកឡើងវិញប្រព័ន្ធមិនផ្ទុកវចនានុក្រមណាមួយក្នុងចំណោមវចនានុក្រមជាច្រើនប្រសិនបើយ៉ាងហោចណាស់មួយក្នុងចំណោមពួកគេបរាជ័យដោយមានកំហុស?
• តើមានវិធីដើម្បីកំណត់រចនាសម្ព័ន្ធព័ត៌មានលម្អិតនៅក្នុង ClickHouse config ប៉ុន្តែមិនបង្ហាញពួកវាក្នុងករណីមានកំហុសទេ?
• ប្រាក់រង្វាន់៖ ពង្រីកផ្ទៃខាងក្រោយពីការជួបជុំ

ប្រសិនបើអ្នកមិនចង់អានអត្ថបទ អ្នកអាចមើលការថតការជួបជុំ នៅលើឆានែល YouTube របស់យើង។. លេខ​កូដ​ពេល​វេលា​គឺ​នៅ​ក្នុង​មតិ​ដំបូង​នៅ​ក្រោម​វីដេអូ។

ClickHouse ត្រូវបានធ្វើបច្ចុប្បន្នភាពឥតឈប់ឈរ ប៉ុន្តែទិន្នន័យរបស់យើងគឺមិនមែនទេ។ អ្វីដែលត្រូវធ្វើអំពីវា?

ClickHouse ត្រូវបានធ្វើបច្ចុប្បន្នភាពឥតឈប់ឈរ ហើយទិន្នន័យរបស់យើងដែលត្រូវបានកែលម្អដំណើរការចុងក្រោយគឺមិនត្រូវបានអាប់ដេតទេ ហើយស្ថិតនៅក្នុងច្បាប់ចម្លងបម្រុងទុក។

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

ស្ថានភាពដែលអ្នកបានស្ដារទិន្នន័យពីការបម្រុងទុកក្នុងទម្រង់ចាស់ ប៉ុន្តែវាមិនភ្ជាប់ទៅកំណែថ្មីគឺមិនអាចទៅរួចទេ។ យើង​ប្រាកដ​ថា​ទ្រង់ទ្រាយ​ទិន្នន័យ​ក្នុង ClickHouse តែងតែ​ត្រូវ​គ្នា​ទៅ​ក្រោយ។ នេះមានសារៈសំខាន់ជាងភាពឆបគ្នាថយក្រោយក្នុងលក្ខខណ្ឌនៃមុខងារ ប្រសិនបើឥរិយាបថនៃមុខងារកម្រប្រើមួយចំនួនបានផ្លាស់ប្តូរ។ កំណែថ្មីរបស់ ClickHouse គួរតែអាចអានទិន្នន័យដែលបានរក្សាទុកនៅលើថាសជានិច្ច។ នេះគឺជាច្បាប់។

តើអ្វីជាការអនុវត្តល្អបំផុតនាពេលបច្ចុប្បន្នសម្រាប់ការបម្រុងទុកទិន្នន័យពី ClickHouse?

តើធ្វើដូចម្តេចដើម្បីធ្វើឱ្យការបម្រុងទុកដោយពិចារណាថាយើងបានបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការចុងក្រោយ, មូលដ្ឋានទិន្នន័យដ៏ធំនៃ terabytes និងទិន្នន័យដែលត្រូវបានធ្វើបច្ចុប្បន្នភាពនិយាយថាសម្រាប់រយៈពេលបីថ្ងៃចុងក្រោយហើយបន្ទាប់មកមិនមាននីតិវិធីកើតឡើងចំពោះពួកគេទេ?

យើងអាចបង្កើតដំណោះស្រាយផ្ទាល់ខ្លួនរបស់យើង ហើយសរសេរនៅលើ bash: ប្រមូលច្បាប់ចម្លងបម្រុងទុកទាំងនេះតាមមធ្យោបាយបែបនេះ។ ប្រហែល​ជា​មិន​ចាំ​បាច់​មាន​ឈើ​ច្រត់​អ្វី​ទេ ហើយ​កង់​ត្រូវ​បាន​បង្កើត​តាំង​ពី​យូរ​មក​ហើយ?

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

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

ខ្ញុំនឹងចាប់ផ្តើមជាមួយនឹងដំណោះស្រាយដ៏សាមញ្ញបំផុត ហើយបញ្ចប់ជាមួយនឹងដំណោះស្រាយដែលស្មុគ្រស្មាញបំផុត អាស្រ័យលើបរិមាណទិន្នន័យ និងទំហំនៃចង្កោម។ ចង្កោមកាន់តែធំ ដំណោះស្រាយកាន់តែស្មុគស្មាញ។

ប្រសិនបើតារាងដែលមានទិន្នន័យប្រើតែពីរបីជីហ្គាបៃ ការបម្រុងទុកអាចត្រូវបានធ្វើដូចនេះ៖

1. រក្សាទុកនិយមន័យតារាង ឧ. ទិន្នន័យមេតា − បង្ហាញតារាងបង្កើត.
2. ធ្វើការចាក់សំរាមដោយប្រើម៉ាស៊ីនភ្ញៀវ ClickHouse - ជ្រើស * ពីតុ ទៅឯកសារមួយ។ តាមលំនាំដើម អ្នកនឹងទទួលបានឯកសារជាទម្រង់ TabSeparated។ ប្រសិនបើអ្នកចង់បានវាកាន់តែមានប្រសិទ្ធភាព អ្នកអាចធ្វើវាក្នុងទម្រង់ដើម។

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

សម្រាប់ករណីកម្រិតខ្ពស់បន្ថែមទៀត ClickHouse មានសមត្ថភាពក្នុងការបង្កើតរូបភាពនៃភាគថាសនៅក្នុងប្រព័ន្ធឯកសារមូលដ្ឋាន។ មុខងារនេះអាចប្រើបានតាមសំណើ។ ផ្លាស់ប្តូរភាគថាសបង្កកតារាង. ឬសាមញ្ញ ផ្លាស់ប្តូរតារាងបង្កក - នេះគឺជារូបថតនៃតារាងទាំងមូល។

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

ការស្តារការបម្រុងទុកបែបនេះគឺងាយស្រួលណាស់។ ដំបូង អ្នកបង្កើតតារាងដោយប្រើនិយមន័យតារាងដែលមានស្រាប់។ បន្ទាប់មកចម្លងរូបថតដែលបានរក្សាទុកនៃភាគថាសទៅថត-ផ្ដាច់សម្រាប់ទិន្នន័យតារាង ហើយដំណើរការសំណួរ ភ្ជាប់ភាគថាស. ដំណោះស្រាយនេះគឺពិតជាសមរម្យសម្រាប់បរិមាណទិន្នន័យធ្ងន់ធ្ងរបំផុត។

ពេលខ្លះអ្នកត្រូវការអ្វីដែលកាន់តែត្រជាក់ - ក្នុងករណីដែលអ្នកមានរាប់សិប ឬរាប់រយ terabytes នៅលើ server នីមួយៗ និងរាប់រយ servers ។ មានដំណោះស្រាយនៅទីនេះដែលខ្ញុំបានយកពីសហសេវិករបស់ខ្ញុំពី Yandex.Metrica ។ ខ្ញុំនឹងមិនណែនាំវាដល់មនុស្សគ្រប់គ្នាទេ - អានវាហើយសម្រេចចិត្តដោយខ្លួនឯងថាតើវាសមរម្យឬអត់។

ដំបូង​អ្នក​ត្រូវ​បង្កើត​ម៉ាស៊ីន​បម្រើ​ជា​ច្រើន​ដែល​មាន​ធ្នើរ​ថាស​ធំ។ បន្ទាប់មក ដំឡើងម៉ាស៊ីនមេ ClickHouse ជាច្រើននៅលើម៉ាស៊ីនមេទាំងនេះ ហើយកំណត់រចនាសម្ព័ន្ធពួកវា ដើម្បីឱ្យពួកគេធ្វើការជាអ្នកចម្លងមួយផ្សេងទៀតសម្រាប់ shards ដូចគ្នា។ ហើយបន្ទាប់មកប្រើប្រព័ន្ធឯកសារ ឬឧបករណ៍មួយចំនួននៅលើម៉ាស៊ីនមេទាំងនេះ ដែលអនុញ្ញាតឱ្យអ្នកបង្កើតរូបថត។ មានជម្រើសពីរនៅទីនេះ។ ជម្រើសទីមួយគឺរូបថត LVM ជម្រើសទីពីរគឺ ZFS នៅលើលីនុច។

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

តើវាអាចទៅរួចទេក្នុងការរៀបចំភាពយឺតយ៉ាវដែលអាចគ្រប់គ្រងបាននៃការចម្លងនៅក្នុង shafts ?

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

តើ​វា​អាច​ធ្វើ​ការ​ត្រឡប់​មក​វិញ​សម្រាប់​ការ​កែប្រែ​ខ្លះ​ដែរ​ឬ​ទេ? ជាឧទាហរណ៍ នៅក្នុងស្ទីលដែលមានស្រាប់ ចូរយកវា ហើយនិយាយថារហូតដល់ពេលនេះអនុវត្តការផ្លាស់ប្ដូរ ហើយចាប់ពីពេលនេះឈប់អនុវត្តការផ្លាស់ប្ដូរ?

ប្រសិនបើពាក្យបញ្ជាបានមកដល់ចង្កោមរបស់យើង ហើយបំបែកវា នោះយើងមានលក្ខខណ្ឌចម្លងតាមលក្ខខណ្ឌជាមួយនឹងភាពយឺតយ៉ាវមួយម៉ោង ដែលយើងអាចនិយាយបានថាអនុញ្ញាតឱ្យយើងប្រើវានៅពេលនេះ ប៉ុន្តែយើងនឹងមិនអនុវត្តការផ្លាស់ប្តូរដប់នាទីចុងក្រោយចំពោះវាទេ?

ទីមួយអំពីភាពយឺតយ៉ាវដែលបានគ្រប់គ្រងនៃការចម្លង។ មានសំណើបែបនេះពីអ្នកប្រើប្រាស់ ហើយយើងបានបង្កើតបញ្ហានៅលើ Github ជាមួយនឹងសំណើ៖ "ប្រសិនបើនរណាម្នាក់ត្រូវការវា ចូលចិត្តវា សូមដាក់បេះដូង។" គ្មាន​អ្នក​ណា​បញ្ជូន​ទេ ហើយ​បញ្ហា​ត្រូវ​បាន​បិទ។ ទោះយ៉ាងណាក៏ដោយ អ្នកអាចទទួលបានឱកាសនេះរួចហើយដោយការដំឡើង ClickHouse ។ ពិត តែចាប់ផ្តើមពីកំណែ 20.3 ប៉ុណ្ណោះ។

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

ទីមួយ ពួកវាបន្តត្រូវបានរក្សាទុក ដរាបណាមានសំណួរជ្រើសរើសដែលប្រើពួកវា ដើម្បីធានាបាននូវប្រតិបត្តិការមិនទប់ស្កាត់។ សំណួរជ្រើសរើសត្រូវបានអានយ៉ាងងាយស្រួលពីកំណាត់ចាស់។

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

ឥឡូវនេះសំណួរក្លាយជាថាតើវាការពារប្រឆាំងនឹងការកែប្រែយ៉ាងដូចម្តេច។ វាមានតម្លៃក្នុងការពិនិត្យមើលឱ្យកាន់តែស៊ីជម្រៅនៅទីនេះ ពីព្រោះនៅក្នុងកំណែចាស់របស់ ClickHouse ការផ្លាស់ប្តូរដំណើរការតាមរបៀបដែលវាគ្រាន់តែផ្លាស់ប្តូរកំណាត់ដោយផ្ទាល់។ មានបំណែកនៃទិន្នន័យដែលមានឯកសារមួយចំនួន ហើយយើងធ្វើឧទាហរណ៍។ ផ្លាស់ប្តូរជួរឈរទម្លាក់. បន្ទាប់មកជួរឈរនេះត្រូវបានដកចេញពីកំណាត់ទាំងអស់។

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

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

ចុះបើរចនាសម្ព័ន្ធតារាងបានផ្លាស់ប្តូរ?

តើធ្វើដូចម្តេចដើម្បីស្ដារការបម្រុងទុកដែលត្រូវបានធ្វើឡើងជាមួយនឹងគ្រោងការណ៍ចាស់? ហើយសំណួរទីពីរគឺអំពីករណីដែលមានរូបថត និងឧបករណ៍ប្រព័ន្ធឯកសារ។ តើ Btrfs ល្អនៅទីនេះជំនួសឱ្យ ZFS នៅលើ Linux LVM ដែរឬទេ?

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

ឥឡូវនេះសំណួរទីពីរគឺថាតើ Btrfs អាចត្រូវបានប្រើដែរឬទេ។ ដើម្បីចាប់ផ្តើម ប្រសិនបើអ្នកមាន LVM នោះរូបថត LVM គឺគ្រប់គ្រាន់ហើយ ប្រព័ន្ធឯកសារអាចជា ext4 វាមិនមានបញ្ហាទេ។ ជាមួយនឹង Btrts អ្វីគ្រប់យ៉ាងអាស្រ័យលើបទពិសោធន៍របស់អ្នកក្នុងការប្រើប្រាស់វា។ នេះគឺជាប្រព័ន្ធឯកសារដែលមានភាពចាស់ទុំ ប៉ុន្តែនៅតែមានការសង្ស័យមួយចំនួនអំពីរបៀបដែលអ្វីៗនឹងដំណើរការនៅក្នុងការអនុវត្តនៅក្នុងសេណារីយ៉ូជាក់លាក់មួយ។ ខ្ញុំនឹងមិនណែនាំឱ្យប្រើវាទេ លុះត្រាតែអ្នកមាន Btrfs នៅក្នុងការផលិត។

តើអ្វីជាការអនុវត្តល្អបំផុតនាពេលបច្ចុប្បន្នក្នុងការបញ្ជូនទិន្នន័យឡើងវិញ?

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

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

វិធីដំបូងដែលអាចធ្វើបានគឺចម្លងផ្នែកនៃភាគថាសទៅម៉ាស៊ីនមេថ្មីដោយប្រើសំណើ ផ្លាស់ប្តូរភាគថាសទាញយកតារាង. ជាឧទាហរណ៍ អ្នកមានភាគដោយខែ ហើយអ្នកយកខែដំបូងនៃឆ្នាំ 2017 ហើយចម្លងវាទៅម៉ាស៊ីនមេថ្មី បន្ទាប់មកចម្លងខែទីបីទៅម៉ាស៊ីនមេថ្មីផ្សេងទៀត។ ហើយ​អ្នក​ធ្វើ​បែប​នេះ​រហូត​ដល់​វា​កាន់​តែ​ច្រើន​ឬ​តិច។

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

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

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

ប៉ុន្តែមានករណីដែលស្មុគស្មាញជាង។ ប្រសិនបើនៅកម្រិតតក្កវិជ្ជាកម្មវិធី អ្នកពឹងផ្អែកលើគ្រោងការណ៍បំបែកពិសេស ដែលអតិថិជននេះមានទីតាំងនៅលើ shard បែបនេះ ហើយសំណើអាចត្រូវបានផ្ញើដោយផ្ទាល់នៅទីនោះ ហើយមិនមែនទៅតារាងចែកចាយនោះទេ។ ឬអ្នកកំពុងប្រើកំណែថ្មីនៃ ClickHouse ហើយបានបើកការកំណត់ បង្កើនប្រសិទ្ធភាពការរំលង shards ដែលមិនប្រើ. ក្នុងករណីនេះ កំឡុងពេលជ្រើសរើសសំណួរ កន្សោមនៅក្នុងផ្នែកដែលនឹងត្រូវបានវិភាគ ហើយវានឹងត្រូវបានគណនាថាតើ shards ត្រូវការប្រើដោយយោងទៅតាមគ្រោងការណ៍ sharding ។ វាដំណើរការបានផ្តល់ឱ្យថាទិន្នន័យត្រូវបានបែងចែកយ៉ាងពិតប្រាកដស្របតាមគ្រោងការណ៍នៃការបំបែកនេះ។ ប្រសិនបើអ្នករៀបចំពួកគេឡើងវិញដោយដៃ ការឆ្លើយឆ្លងអាចផ្លាស់ប្តូរ។

ដូច្នេះនេះគឺជាវិធីសាស្រ្តលេខមួយ។ ហើយ​ខ្ញុំ​កំពុង​រង់ចាំ​ចម្លើយ​របស់​អ្នក ថាតើ​វិធីសាស្ត្រ​សមស្រប​ឬ​ក៏​សូម​បន្ត​ទៅមុខទៀត។

Vladimir Kolobaev អ្នកគ្រប់គ្រងប្រព័ន្ធនាំមុខនៅ Avito៖ Alexey វិធីសាស្ត្រដែលអ្នកបានរៀបរាប់មិនដំណើរការល្អទេ នៅពេលដែលអ្នកត្រូវការចែកចាយបន្ទុក រួមទាំងការអានផងដែរ។ យើងអាចយកភាគថាសដែលប្រចាំខែ ហើយអាចយកខែមុនទៅ node ផ្សេងទៀត ប៉ុន្តែនៅពេលដែលមានសំណើសម្រាប់ទិន្នន័យនេះ យើងនឹងផ្ទុកវាតែប៉ុណ្ណោះ។ ប៉ុន្តែយើងចង់ផ្ទុកចង្កោមទាំងមូល ពីព្រោះបើមិនដូច្នេះទេ សម្រាប់ពេលខ្លះ បន្ទុកអានទាំងមូលនឹងត្រូវបានដំណើរការដោយបន្ទះពីរ។

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

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

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

ខ្ញុំមានចំណុចមួយចំនួនទៀតដើម្បីឆ្លើយសំណួររបស់អ្នក។ មួយក្នុងចំណោមពួកគេគឺអំពីរបៀបបង្កើតគ្រោងការណ៍ sharding ដំបូងដូច្នេះថាការ sharding ឡើងវិញនឹងបណ្តាលឱ្យមានការឈឺចាប់តិច។ នេះមិនតែងតែអាចធ្វើទៅបានទេ។

ឧទាហរណ៍ អ្នកមានទិន្នន័យត្រួតពិនិត្យ។ ការតាមដានទិន្នន័យកំពុងកើនឡើងដោយសារហេតុផលបីយ៉ាង។ ទីមួយគឺការប្រមូលផ្តុំទិន្នន័យប្រវត្តិសាស្ត្រ។ ទីពីរ​គឺ​កំណើន​ចរាចរណ៍។ ហើយ​ទី​៣ គឺ​ការ​កើន​ឡើង​នូវ​ចំនួន​វត្ថុ​ដែល​ត្រូវ​តាម​ដាន។ មានសេវាមីក្រូ និងរង្វាស់ថ្មីដែលត្រូវការរក្សាទុក។

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

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

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

អ្នកពិតជាត្រឹមត្រូវណាស់ យើងមានបទពិសោធន៍ភាគច្រើននៃសំណើអាននៅថ្ងៃចុងក្រោយ ដូចជាប្រព័ន្ធត្រួតពិនិត្យណាមួយ។ ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ ការផ្ទុកទិន្នន័យប្រវត្តិសាស្រ្តក៏មានទំហំធំផងដែរ។ វាជាមូលដ្ឋានពីប្រព័ន្ធដាស់តឿនដែលដើរជុំវិញរាល់សាមសិបវិនាទី ហើយនិយាយទៅកាន់ ClickHouse ថា "ផ្តល់ឱ្យខ្ញុំនូវទិន្នន័យសម្រាប់រយៈពេលប្រាំមួយសប្តាហ៍ចុងក្រោយនេះ។ ឥឡូវ​នេះ​បង្កើត​ឱ្យ​ខ្ញុំ​នូវ​ប្រភេទ​នៃ​ការ​ផ្លាស់​ប្តូរ​មធ្យម​ភាគ​មួយ​ចំនួន​ពី​ពួក​វា ហើយ​យើង​ប្រៀបធៀប​តម្លៃ​បច្ចុប្បន្ន​ជាមួយ​នឹង​តម្លៃ​ប្រវត្តិសាស្ត្រ»។

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

Alexey Milovidov៖ ជាអកុសល វាមិនដំណើរការល្អសម្រាប់សេណារីយ៉ូរបស់អ្នកទេ ប៉ុន្តែខ្ញុំនឹងរៀបរាប់អំពីគ្រោងការណ៍ការបំបែកដ៏អាក្រក់ និងស្មុគស្មាញពីរដែលអ្នកមិនចាំបាច់ប្រើ ប៉ុន្តែដែលត្រូវបានប្រើនៅក្នុងសេវាកម្មមិត្តរបស់ខ្ញុំ។

មានចង្កោមចម្បងជាមួយព្រឹត្តិការណ៍ Yandex.Metrica ។ ព្រឹត្តិការណ៍គឺជាការមើលទំព័រ ការចុច និងការបំប្លែង។ សំណើភាគច្រើនចូលទៅកាន់គេហទំព័រជាក់លាក់។ អ្នកបើកសេវាកម្ម Yandex.Metrica អ្នកមានគេហទំព័រមួយ - avito.ru ចូលទៅកាន់របាយការណ៍ ហើយសំណើត្រូវបានធ្វើឡើងសម្រាប់គេហទំព័ររបស់អ្នក។

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

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

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

មានជម្រើសមួយដែលផ្ទុយពី diametrically ។ ស្រមៃមើលថាតើយើងចែករំលែកទិន្នន័យឆ្លងកាត់គេហទំព័រមួយ ហើយសំណើសម្រាប់គេហទំព័រមួយទៅ shard មួយ។ ឥឡូវនេះ ចង្កោមនឹងអាចដោះស្រាយសំណើចំនួន 1 ម៉ឺនក្នុងមួយវិនាទី ប៉ុន្តែនៅលើ shard មួយសំណើណាមួយនឹងដំណើរការយឺតពេក។ វា​នឹង​លែង​ធ្វើ​មាត្រដ្ឋាន​ក្នុង​លក្ខខណ្ឌ​នៃ​កម្រិត​បញ្ជូន​ទៀត​ហើយ។ ជាពិសេសប្រសិនបើនេះជាគេហទំព័រ avito.ru ។ ខ្ញុំនឹងមិនបង្ហាញអាថ៌កំបាំងទេប្រសិនបើខ្ញុំនិយាយថា Avito គឺជាគេហទំព័រមួយក្នុងចំណោមគេហទំព័រដែលមានអ្នកចូលមើលច្រើនបំផុតនៅក្នុង RuNet ។ ហើយ​ការ​កែច្នៃ​វា​នៅ​លើ​ផ្នែក​មួយ​នឹង​ក្លាយ​ជា​ឆ្កួត។

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

តើនេះមានទំហំប៉ុនណា? ចំនួនចង្កោមមិនផ្លាស់ប្តូរទេ - ដូចដែលវាគឺសាមសិបប្រាំបួនកាលពីប៉ុន្មានឆ្នាំមុនវានៅតែមានដូច្នេះ។ ប៉ុន្តែនៅក្នុងពួកវានីមួយៗ យើងបង្កើនចំនួន shard ជាបណ្តើរៗ នៅពេលដែលទិន្នន័យប្រមូលផ្តុំ។ ហើយគ្រោងការណ៍ sharding ជាទូទៅគឺនេះ៖ ការបែងចែកទៅជាចង្កោមទាំងនេះកើតឡើងនៅទូទាំងគេហទំព័រ ហើយដើម្បីយល់ពីគេហទំព័រណាដែលស្ថិតនៅលើចង្កោមនោះ metabase ដាច់ដោយឡែកមួយត្រូវបានប្រើនៅក្នុង MySQL ។ គេហទំព័រមួយនៅលើចង្កោមមួយ។ ហើយនៅក្នុងវា ការបំបែកកើតឡើងដោយផ្អែកលើលេខសម្គាល់អ្នកទស្សនា។

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

ប៉ុន្តែរឿងរបស់ខ្ញុំនឹងមិនពេញលេញទេប្រសិនបើខ្ញុំមិននិយាយថាយើងបោះបង់ចោលគ្រោងការណ៍នេះ។ នៅក្នុងគ្រោងការណ៍ថ្មី យើងបានផ្លាស់ប្តូរអ្វីគ្រប់យ៉ាង និងចម្លងទិន្នន័យទាំងអស់ដោយប្រើ clickhouse-copier ។

នៅក្នុងគ្រោងការណ៍ថ្មីគេហទំព័រទាំងអស់ត្រូវបានបែងចែកជាពីរប្រភេទ - ធំនិងតូច។ ខ្ញុំមិនដឹងថាកម្រិតត្រូវបានជ្រើសរើសដោយរបៀបណានោះទេ ប៉ុន្តែលទ្ធផលគឺថាគេហទំព័រធំៗត្រូវបានកត់ត្រានៅលើចង្កោមមួយ ដែលមាន 120 shards ជាមួយការចម្លងចំនួន 360 នីមួយៗ ពោលគឺ 120 servers។ ហើយគ្រោងការណ៍ sharding គឺដូចជាការស្នើសុំណាមួយទៅ shards ទាំងអស់ក្នុងពេលតែមួយ។ ប្រសិនបើអ្នកឥឡូវនេះបើកទំព័ររបាយការណ៍ណាមួយសម្រាប់ avito.ru នៅក្នុង Yandex.Metrica សំណើនឹងទៅកាន់ម៉ាស៊ីនមេ 120 ។ មានគេហទំព័រធំៗមួយចំនួននៅក្នុង RuNet។ ហើយសំណើមិនមែនមួយពាន់ក្នុងមួយវិនាទីទេ ប៉ុន្តែសូម្បីតែតិចជាងមួយរយ។ ទាំងអស់នេះត្រូវបានទំពារដោយស្ងៀមស្ងាត់ដោយតារាងចែកចាយ ដែលពួកវានីមួយៗដំណើរការជាមួយម៉ាស៊ីនមេចំនួន XNUMX ។

ហើយចង្កោមទីពីរគឺសម្រាប់គេហទំព័រតូចៗ។ នេះគឺជាគ្រោងការណ៍ sharding ដោយផ្អែកលើលេខសម្គាល់គេហទំព័រ ហើយសំណើនីមួយៗត្រូវទៅ shard មួយ។

ClickHouse មានឧបករណ៍ប្រើប្រាស់ clickhouse-copier ។ តើអ្នកអាចប្រាប់យើងអំពីនាងបានទេ?

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

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

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

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

អ្នក​មាន​អ្វី​ដែល​អ្នក​បើក​យន្តហោះ​ហៅ​ថា​ការ​បញ្ជូន​បន្ត។ ចុះនាងវិញ?

ត្រលប់ទៅឆ្នាំ 2017 អ្នកមានរឿងសាកល្បងមួយហៅថា ការបញ្ជូនបន្ត។ មានជម្រើសមួយនៅក្នុង ClickHouse ។ តាម​ខ្ញុំ​យល់ វា​មិន​បាន​រលត់​ទេ។ តើអ្នកអាចប្រាប់ខ្ញុំបានទេថាហេតុអ្វីបានជារឿងនេះកើតឡើង? វាហាក់ដូចជាពាក់ព័ន្ធខ្លាំងណាស់។

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

តើវាអាចទៅរួចទេក្នុងការបញ្ចូលបំណែកទិន្នន័យទាំងអស់ចូលគ្នា មុនពេលផ្លាស់ទីវាទៅថាសយឺត?

សំណួរអំពី TTL ជាមួយការផ្លាស់ទីទៅជម្រើសថាសយឺតក្នុងបរិបទនៃការបញ្ចូលគ្នា។ តើមានវិធីផ្សេងក្រៅពីការប្រើប្រាស់ cron ដើម្បីបញ្ចូលផ្នែកទាំងអស់ទៅជាមួយមុនពេលផ្លាស់ទីពួកវាទៅឌីសយឺតទេ?

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

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

លក្ខណៈវិនិច្ឆ័យទីពីរគឺទំហំ។ វានិយាយអំពីការដឹកដុំធំៗ។ អ្នកអាចកែតម្រូវកម្រិតកំណត់ដោយផ្អែកលើទំហំទំនេរនៅលើថាសលឿន ហើយទិន្នន័យនឹងត្រូវបានផ្ទេរដោយស្វ័យប្រវត្តិ។

តើធ្វើដូចម្តេចដើម្បីធ្វើចំណាកស្រុកទៅកំណែថ្មីរបស់ ClickHouse ប្រសិនបើមិនមានវិធីដើម្បីពិនិត្យមើលភាពឆបគ្នាជាមុនទេ?

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

មានច្បាប់ "មាស" ជាច្រើននៅទីនេះ។ ដំបូង - អានកំណត់ហេតុផ្លាស់ប្តូរ. វាមានទំហំធំ ប៉ុន្តែមានកថាខណ្ឌដាច់ដោយឡែកអំពីការផ្លាស់ប្តូរដែលមិនឆបគ្នាថយក្រោយ។ កុំចាត់ទុកចំណុចទាំងនេះជាទង់ក្រហម។ ជាធម្មតាទាំងនេះគឺជាភាពមិនឆបគ្នាតិចតួចដែលទាក់ទងនឹងមុខងារគែមមួយចំនួនដែលអ្នកទំនងជាមិនប្រើ។

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

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

មានកំណែ 20.3.4 ។ លេខ 20 បង្ហាញពីឆ្នាំនៃការផលិត - 2020 ។ តាមទស្សនៈនៃអ្វីដែលនៅខាងក្នុងវាមិនមានបញ្ហាទេដូច្នេះយើងនឹងមិនយកចិត្តទុកដាក់ចំពោះរឿងនេះទេ។ បន្ទាប់គឺ 20.3 ។ យើងបង្កើនលេខទីពីរ - ក្នុងករណីនេះ 3 - រាល់ពេលដែលយើងចេញផ្សាយការចេញផ្សាយជាមួយនឹងមុខងារថ្មីមួយចំនួន។ ប្រសិនបើយើងចង់បន្ថែមលក្ខណៈពិសេសណាមួយទៅ ClickHouse យើងត្រូវបង្កើនចំនួននេះ។ នោះគឺនៅក្នុងកំណែ 20.4 ClickHouse នឹងដំណើរការកាន់តែប្រសើរ។ ខ្ទង់ទីបីគឺ 20.3.4 ។ នេះ 4 គឺជាចំនួននៃការចេញផ្សាយបំណះដែលយើងមិនបានបន្ថែមលក្ខណៈពិសេសថ្មី ប៉ុន្តែបានជួសជុលកំហុសមួយចំនួន។ ហើយ 4 មានន័យថាយើងបានធ្វើវាបួនដង។

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

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

Kirill Shvakov៖ ខ្ញុំចង់បន្ថែមបន្តិចអំពីបរិយាកាសសាកល្បង។ មនុស្សគ្រប់រូបមានការភ័យខ្លាចយ៉ាងខ្លាំងចំពោះបរិស្ថានសាកល្បង ហើយសម្រាប់ហេតុផលមួយចំនួនពួកគេជឿថា ប្រសិនបើអ្នកមានចង្កោម ClickHouse ធំខ្លាំង នោះបរិយាកាសសាកល្បងគួរតែមិនតិចជាង ឬតិចជាងដប់ដង។ វាមិនដូចនោះទាល់តែសោះ។

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

តើអាចធ្វើអ្វីបាន? វាជាការល្អក្នុងការផ្តល់នូវឧទាហរណ៍មួយនៅក្នុងឯកសារ ClickHouse អំពីរបៀបដាក់ពង្រាយចង្កោមតូចមួយដោយខ្លួនឯង - នៅក្នុង Docker នៅក្នុង LXC ប្រហែលជាបង្កើត Ansible playbook ពីព្រោះមនុស្សផ្សេងគ្នាមានការដាក់ពង្រាយខុសៗគ្នា។ នេះនឹងធ្វើឱ្យមានភាពសាមញ្ញច្រើន។ នៅពេលអ្នកយក និងដាក់ពង្រាយចង្កោមក្នុងរយៈពេលប្រាំនាទី វាកាន់តែងាយស្រួលក្នុងការព្យាយាមរកអ្វីមួយចេញ។ នេះ​គឺ​ជា​ការ​ងាយ​ស្រួល​ជាង​ព្រោះ​ការ​ចូល​ទៅ​ក្នុង​កំណែ​ផលិត​ដែល​អ្នក​មិន​បាន​ពិនិត្យ​គឺ​ជា​ផ្លូវ​ទៅ​កន្លែង​ណា​មួយ​។ ពេលខ្លះវាដំណើរការ ហើយពេលខ្លះវាមិនដំណើរការ។ ដូច្នេះហើយ សង្ឃឹម​ជោគជ័យ​គឺ​អាក្រក់។

Maxim Kotyakov វិស្វករផ្នែកខាងក្រោយជាន់ខ្ពស់ Avito៖ ខ្ញុំនឹងបន្ថែមបន្តិចបន្តួចអំពីបរិយាកាសសាកល្បងពីបញ្ហាជាបន្តបន្ទាប់សម្រាប់ក្រុមហ៊ុនធំៗ។ យើងមានចង្កោមការទទួលយក ClickHouse ពេញលេញ ជាមួយនឹងគ្រោងការណ៍ទិន្នន័យ និងការកំណត់ច្បាប់ចម្លងពិតប្រាកដនៃអ្វីដែលកំពុងផលិត។ ចង្កោមនេះត្រូវបានដាក់ពង្រាយនៅក្នុងធុងដែលចាស់ជាងជាមួយនឹងធនធានអប្បបរមា។ យើងសរសេរភាគរយជាក់លាក់នៃទិន្នន័យផលិតកម្មនៅទីនោះ ជាសំណាងល្អវាអាចទៅរួចក្នុងការចម្លងចរន្តនៅក្នុង Kafka ។ អ្វីគ្រប់យ៉ាងដែលនៅទីនោះត្រូវបានធ្វើសមកាលកម្ម និងធ្វើមាត្រដ្ឋាន - ទាំងនៅក្នុងលក្ខខណ្ឌនៃថាមពល និងនៅក្នុងលក្ខខណ្ឌនៃលំហូរ ហើយតាមទ្រឹស្តី អ្វីៗផ្សេងទៀតទាំងអស់គឺស្មើគ្នា វាគួរតែមានឥរិយាបទដូចជាការផលិតនៅក្នុងលក្ខខណ្ឌនៃម៉ែត្រ។ អ្វីគ្រប់យ៉ាងដែលអាចផ្ទុះបានត្រូវបានរមៀលចូលទៅក្នុងកន្លែងឈរនេះហើយទុកនៅទីនោះអស់រយៈពេលជាច្រើនថ្ងៃរហូតដល់វារួចរាល់។ ប៉ុន្តែតាមធម្មជាតិ ដំណោះស្រាយនេះមានតម្លៃថ្លៃ ពិបាក និងជាមួយនឹងការចំណាយគាំទ្រមិនសូន្យ។

Alexey Milovidov៖ ខ្ញុំនឹងប្រាប់អ្នកពីបរិយាកាសសាកល្បងរបស់មិត្តភ័ក្តិរបស់យើងពី Yandex.Metrica ។ ចង្កោមមួយមាន 600-odd servers មួយទៀតមាន 360 ហើយមាន cluster ទីបី និង ជាច្រើន។ បរិយាកាសសាកល្បងសម្រាប់មួយក្នុងចំណោមពួកគេគឺសាមញ្ញ XNUMX shards ជាមួយនឹងការចម្លងពីរគ្នា។ ហេតុអ្វីបានជាពីរកំណាត់? ដូច្នេះអ្នកមិននៅម្នាក់ឯងទេ។ ហើយគួរតែមានការចម្លងផងដែរ។ គ្រាន់តែជាចំនួនអប្បបរមាជាក់លាក់មួយដែលអ្នកអាចមានលទ្ធភាពទិញបាន។

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

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

អ្វីគ្រប់យ៉ាងគឺល្អ។ យើង​ចាប់​ផ្តើម​ឈាន​ទៅ​រក​ផលិតកម្ម។ ខ្ញុំទទួលបានសារថាការផ្ទុកនៅលើក្រាហ្វបានកើនឡើងជាច្រើនដង។ យើង​កំពុង​វិល​ត្រឡប់​កំណែ។ ខ្ញុំក្រឡេកមើលក្រាហ្វ ហើយឃើញ៖ បន្ទុកពិតជាកើនឡើងច្រើនដងក្នុងអំឡុងពេលដាក់ឱ្យដំណើរការ ហើយថយចុះមកវិញនៅពេលវាត្រូវបានដាក់ឱ្យដំណើរការ។ បន្ទាប់​មក​យើង​ចាប់​ផ្ដើម​ត្រឡប់​កំណែ។ ហើយ​បន្ទុក​បាន​កើន​ឡើង​ដូច​គ្នា ហើយ​ធ្លាក់​ចុះ​វិញ​តាម​វិធី​ដដែល។ ដូច្នេះការសន្និដ្ឋានគឺនេះ: បន្ទុកបានកើនឡើងដោយសារតែប្លង់មិនមានអ្វីគួរឱ្យភ្ញាក់ផ្អើលទេ។

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

Kill query សន្មត់ថាសម្លាប់ queries ប៉ុន្តែវាមិនមែនទេ។ ហេតុអ្វី?

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

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

ឥឡូវនេះនឹងមានចម្លើយចម្លែក។ ចំនុចនោះគឺថា kill query មិនសម្លាប់ queries ទេ។

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

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

តើធ្វើដូចម្តេចដើម្បីគណនាពេលវេលាឆ្លើយតបនៅក្រោមការផ្ទុកអាន?

មានតារាងដែលការប្រមូលផ្តុំដោយធាតុត្រូវបានរក្សាទុក - បញ្ជរផ្សេងៗ។ ចំនួនជួរគឺប្រហែលមួយរយលាន។ តើវាអាចទៅរួចទេក្នុងការពឹងផ្អែកលើពេលវេលាឆ្លើយតបដែលអាចព្យាករណ៍បាន ប្រសិនបើអ្នកចាក់ 1K RPS លើធាតុ 1K?

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

សំណើអានគឺខុសគ្នាខ្លាំងណាស់។ នៅក្នុងជម្រើសទី 1 ClickHouse អាចអនុវត្តសំណើរាប់ម៉ឺនដងក្នុងមួយវិនាទី ដូច្នេះសូម្បីតែសំណើសម្រាប់សោមួយនឹងត្រូវការធនធានមួយចំនួនរួចហើយ។ ហើយសំណួរចំណុចបែបនេះនឹងពិបាកជាងនៅក្នុងមូលដ្ឋានទិន្នន័យតម្លៃគន្លឹះមួយចំនួន ពីព្រោះសម្រាប់ការអាននីមួយៗ ចាំបាច់ត្រូវអានប្លុកទិន្នន័យតាមលិបិក្រម។ លិបិក្រមរបស់យើងមិនកំណត់កំណត់ត្រានីមួយៗទេ ប៉ុន្តែជួរនីមួយៗ។ នោះគឺអ្នកនឹងត្រូវអានជួរទាំងមូល - នេះគឺជា 8192 បន្ទាត់តាមលំនាំដើម។ ហើយអ្នកនឹងត្រូវបង្រួមប្លុកទិន្នន័យដែលបានបង្ហាប់ពី 64 KB ទៅ 1 MB ។ ជាធម្មតា សំណើចំណុចបែបនេះចំណាយពេលពីរបីមិល្លីវិនាទី។ ប៉ុន្តែនេះគឺជាជម្រើសដ៏សាមញ្ញបំផុត។

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

ប្រសិនបើអ្នកត្រូវការធ្វើមាត្រដ្ឋានចង្កោម ClickHouse ដោយចំនួនសំណើសាមញ្ញ នោះខ្ញុំសូមណែនាំរឿងសាមញ្ញបំផុត - បង្កើនចំនួនចម្លង និងផ្ញើសំណើទៅការចម្លងចៃដន្យ។ ប្រសិនបើការចម្លងមួយទទួលបានប្រាំរយសំណើក្នុងមួយវិនាទី ដែលមានភាពប្រាកដនិយមទាំងស្រុងនោះ ការចម្លងចំនួនបីនឹងមានមួយពាន់កន្លះ។

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

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

Kirill Shvakov៖ ខ្ញុំនឹងផ្តល់ដំបូន្មានក្នុងករណីមានគណនីធម្មតានៅទីនោះ។ នេះគឺជាស្ថានភាពស្ដង់ដារត្រឹមត្រូវនៅពេលដែលប្រភេទបញ្ជរមួយចំនួនត្រូវបានរក្សាទុកនៅក្នុង ClickHouse ។ ខ្ញុំ​មាន​អ្នក​ប្រើ គាត់​មក​ពី​ប្រទេស​បែប​នេះ ហើយ​ជា​កន្លែង​ទី​បី ហើយ​ខ្ញុំ​ត្រូវ​បង្កើន​អ្វី​មួយ​ជា​បន្តបន្ទាប់។ យក MySQL បង្កើតកូនសោពិសេសមួយ - នៅក្នុង MySQL វាគឺជាសោស្ទួន ហើយនៅក្នុង PostgreSQL វាគឺជាការប៉ះទង្គិចគ្នា - ហើយបន្ថែមសញ្ញាបូក។ នេះនឹងដំណើរការកាន់តែប្រសើរ។

នៅពេលដែលអ្នកមិនមានទិន្នន័យច្រើន វាមិនមានចំណុចច្រើនក្នុងការប្រើប្រាស់ ClickHouse ទេ។ មានមូលដ្ឋានទិន្នន័យធម្មតា ហើយពួកគេធ្វើការងារនេះបានល្អ។

តើខ្ញុំអាចកែប្រែអ្វីខ្លះនៅក្នុង ClickHouse ដើម្បីឱ្យទិន្នន័យកាន់តែច្រើននៅក្នុងឃ្លាំងសម្ងាត់?

ចូរស្រមៃមើលស្ថានភាពមួយ - ម៉ាស៊ីនមេមាន RAM ទំហំ 256 GB ក្នុងទម្លាប់ប្រចាំថ្ងៃ ClickHouse ត្រូវការប្រហែល 60-80 GB នៅកម្រិតកំពូល - រហូតដល់ 130 ។ អ្វីដែលអាចត្រូវបានបើក និងកែប្រែដើម្បីឱ្យទិន្នន័យកាន់តែច្រើននៅក្នុងឃ្លាំងសម្ងាត់ ហើយតាមនោះ។ មានការធ្វើដំណើរតិចជាងមុនទៅឌីស?

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

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

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

តើខ្ញុំអាចកំណត់រចនាសម្ព័ន្ធ storage_configuration សម្រាប់ការផ្ទុកនៅក្នុង RAM ដោយរបៀបណា?

នៅក្នុងឯកសារ ClickHouse ថ្មីខ្ញុំបានអានផ្នែកដែលទាក់ទង ជាមួយនឹងការផ្ទុកទិន្នន័យ. ការពិពណ៌នាមានឧទាហរណ៍ជាមួយ SSD លឿន។

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

ការ​កំណត់​នេះ​ប៉ះពាល់​ដល់​ទំហំ​ផ្ទុក​ទិន្នន័យ ហើយ​ទម្រង់​របស់​វា​មិន​មាន​ការ​ផ្លាស់​ប្តូរ​តាម​វិធី​ណា​មួយ​ឡើយ។
ចូរយើងពិនិត្យមើលឱ្យកាន់តែច្បាស់។

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

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

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

ក្នុងករណីនេះទិន្នន័យនៅក្នុង RAM ត្រូវបានរក្សាទុកក្នុងទម្រង់ដូចគ្នានឹងនៅលើឌីស។ សំណួរជ្រើសរើសតាមរបៀបដូចគ្នា ជ្រើសរើសបំណែកដែលត្រូវការអាន ជ្រើសរើសជួរទិន្នន័យចាំបាច់នៅក្នុងបំណែក និងអានពួកវា។ ហើយ Prewhere ដំណើរការដូចគ្នា ដោយមិនគិតពីថាតើទិន្នន័យស្ថិតនៅក្នុង RAM ឬនៅលើថាសនោះទេ។

តើ Low Cardinality មានប្រសិទ្ធភាពដល់កម្រិតណាខ្លះ?

Low Cardinality ត្រូវបានរចនាឡើងយ៉ាងឆ្លាតវៃ។ វាចងក្រងវចនានុក្រមទិន្នន័យ ប៉ុន្តែពួកវាមានមូលដ្ឋាន។ ទីមួយ មានវចនានុក្រមផ្សេងៗគ្នាសម្រាប់បំណែកនីមួយៗ ហើយទីពីរ សូម្បីតែក្នុងមួយដុំ ពួកគេអាចខុសគ្នាសម្រាប់ជួរនីមួយៗ។ នៅពេលដែលចំនួននៃតម្លៃតែមួយគត់ឈានដល់កម្រិតមួយ—មួយលាន ខ្ញុំគិតថា—វចនានុក្រមត្រូវបានទុកដាក់យ៉ាងសាមញ្ញ ហើយថ្មីមួយត្រូវបានបង្កើតឡើង។

ចម្លើយគឺជាទូទៅ៖ សម្រាប់ជួរក្នុងស្រុកនីមួយៗ - និយាយថាសម្រាប់មួយថ្ងៃៗ - កន្លែងណាមួយរហូតដល់មួយលានតម្លៃពិសេស Low Cardinality មានប្រសិទ្ធភាព។ ក្រោយមក វានឹងមាន​ពាក្យ​ថយក្រោយ​ដែល​វចនានុក្រម​ផ្សេងៗ​ជាច្រើន​នឹង​ត្រូវ​បាន​ប្រើ ហើយ​មិន​មែន​តែមួយ​ទេ។ វា​នឹង​ដំណើរការ​ប្រហែល​ដូច​គ្នា​នឹង​ជួរ​ឈរ​ខ្សែ​ធម្មតា ប្រហែល​ជា​មាន​ប្រសិទ្ធ​ភាព​តិច​តួច​ ប៉ុន្តែ​នឹង​មិន​មាន​ការ​ខូច​ខាត​មុខងារ​ធ្ងន់ធ្ងរ​ទេ។

តើអ្វីជាការអនុវត្តល្អបំផុតសម្រាប់ការស្វែងរកអត្ថបទពេញតារាងដែលមានប្រាំពាន់លានជួរ?

មានចម្លើយខុសៗគ្នា។ ទីមួយគឺនិយាយថា ClickHouse មិនមែនជាម៉ាស៊ីនស្វែងរកអត្ថបទពេញលេញទេ។ មានប្រព័ន្ធពិសេសសម្រាប់រឿងនេះឧទាហរណ៍។ Elasticsearch и Sphinx. ទោះជាយ៉ាងណាក៏ដោយ ខ្ញុំឃើញមនុស្សកាន់តែច្រើនឡើងនិយាយថាពួកគេកំពុងប្តូរពី Elasticsearch ទៅ ClickHouse ។

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

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

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

ក្នុង​ករណី​នេះ ខ្ញុំ​បាន​ត្រៀម​ខ្លួន​ជា​ស្រេច​ដើម្បី​ផ្តល់​ជូន​នូវ​ល្បិច​មួយ​ទៀត​។ វាជាការពិសោធន៍ - វាអាចដំណើរការបាន វាប្រហែលជាមិនមែនទេ។ ClickHouse មានលិបិក្រមអត្ថបទពេញក្នុងទម្រង់នៃតម្រង trigram Bloom ។ សហសេវិករបស់យើងនៅ Arenadata បានសាកល្បងលិបិក្រមទាំងនេះរួចហើយ ហើយជារឿយៗពួកគេធ្វើការយ៉ាងពិតប្រាកដដូចបំណង។

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

ថ្មីៗនេះ ClickHouse បានបន្ថែមមុខងារកម្រិតខ្ពស់បន្ថែមទៀតសម្រាប់ការស្វែងរកអត្ថបទពេញ។ នេះជាលើកដំបូង ការស្វែងរកសម្រាប់បណ្តុំនៃខ្សែអក្សររងក្នុងពេលតែមួយ រួមទាំងជម្រើសដែលប្រកាន់អក្សរតូចធំ មិនប្រកាន់អក្សរតូចធំ ដោយមានការគាំទ្រសម្រាប់ UTF-8 ឬសម្រាប់តែ ASCII ប៉ុណ្ណោះ។ ជ្រើសរើសប្រសិទ្ធភាពបំផុតដែលអ្នកត្រូវការ។

ការស្វែងរកកន្សោមធម្មតាជាច្រើននៅក្នុងសំបុត្រមួយក៏បានលេចឡើងផងដែរ។ អ្នកមិនចាំបាច់សរសេរ X ដូច substring មួយ ឬ X ដូច substring ផ្សេងទៀតទេ។ អ្នកសរសេរភ្លាមៗ ហើយអ្វីៗគ្រប់យ៉ាងត្រូវបានធ្វើប្រកបដោយប្រសិទ្ធភាពតាមដែលអាចធ្វើទៅបាន។

ទីបី ឥឡូវនេះមានការស្វែងរកប្រហាក់ប្រហែលសម្រាប់ regexps និងការស្វែងរកប្រហាក់ប្រហែលសម្រាប់ substrings ។ ប្រសិនបើនរណាម្នាក់សរសេរពាក្យខុស វានឹងត្រូវបានស្វែងរកសម្រាប់ការប្រកួតអតិបរមា។

តើអ្វីជាវិធីល្អបំផុតក្នុងការរៀបចំការចូលទៅកាន់ ClickHouse សម្រាប់អ្នកប្រើប្រាស់មួយចំនួនធំ?

ប្រាប់យើងពីរបៀបរៀបចំការចូលប្រើឱ្យកាន់តែប្រសើរឡើងសម្រាប់អ្នកប្រើប្រាស់ និងអ្នកវិភាគមួយចំនួនធំ។ របៀបបង្កើតជួរ កំណត់អាទិភាពសំណួរដែលស្របគ្នាអតិបរមា និងជាមួយឧបករណ៍អ្វីខ្លះ?

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

ជាគោលការណ៍ ម៉ាស៊ីនមេទាំងនេះមិនមានទិន្នន័យទេ ប៉ុន្តែចំនួន RAM នៅលើពួកវាមានសារៈសំខាន់ខ្លាំងណាស់សម្រាប់ការប្រតិបត្តិសំណើ។ ថាសក៏អាចត្រូវបានប្រើសម្រាប់ទិន្នន័យបណ្តោះអាសន្នប្រសិនបើការប្រមូលផ្តុំខាងក្រៅឬការតម្រៀបខាងក្រៅត្រូវបានបើក។

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

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

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

នេះ​ជា​ការ​កំណត់​ឆៅ​ខ្លាំង​ណាស់ ហើយ​មិន​សក្តិសម​សម្រាប់​ករណី​ដែល​ចង្កោម​មាន​បន្ទុក​ថេរ។ ប៉ុន្តែប្រសិនបើអ្នកមានសំណើខ្លីៗ ដែលមានសារៈសំខាន់ ហើយចង្កោមភាគច្រើននៅទំនេរ ការរៀបចំនេះគឺសមរម្យ។

ការកំណត់អាទិភាពបន្ទាប់ត្រូវបានគេហៅថា អាទិភាព​ខ្សែ​ប្រតិបត្តិការ OS. វាគ្រាន់តែកំណត់តម្លៃដ៏ល្អសម្រាប់ដំណើរការសំណើទាំងអស់សម្រាប់កម្មវិធីកំណត់ពេលលីនុច។ វាដំណើរការយ៉ាងដូច្នេះ ប៉ុន្តែវានៅតែដំណើរការ។ ប្រសិនបើអ្នកកំណត់តម្លៃដ៏ស្រស់ស្អាតអប្បបរមា - វាគឺជាតម្លៃធំបំផុត ហើយមានន័យថាជាអាទិភាពទាបបំផុត ហើយកំណត់ -19 សម្រាប់សំណើដែលមានអាទិភាពខ្ពស់ នោះ CPU នឹងប្រើប្រាស់សំណើដែលមានអាទិភាពទាបប្រហែល XNUMX ដងតិចជាងសំណើដែលមានអាទិភាពខ្ពស់។

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

សូមស្រមៃថា អ្នកកំណត់រចនាសម្ព័ន្ធ៖ ប្រសិនបើសំណួរមួយចំនួនដំណើរការតិចជាងមួយលានជួរក្នុងមួយវិនាទី អ្នកមិនអាចធ្វើវាបានទេ។ នេះបង្អាប់ឈ្មោះល្អរបស់យើង មូលដ្ឋានទិន្នន័យល្អរបស់យើង។ សូម​ហាម​ការ​នេះ។ តាមពិតមានការកំណត់ពីរ។ មួយត្រូវបានគេហៅថា ល្បឿនប្រតិបត្តិអប្បបរមា - ជាបន្ទាត់ក្នុងមួយវិនាទី ហើយទីពីរត្រូវបានគេហៅថាអស់ពេលមុនពេលពិនិត្យមើលល្បឿនប្រតិបត្តិអប្បបរមា - ដប់ប្រាំវិនាទីតាមលំនាំដើម។ នោះគឺដប់ប្រាំវិនាទីអាចធ្វើទៅបាន ហើយបន្ទាប់មក ប្រសិនបើវាយឺត នោះគ្រាន់តែបោះករណីលើកលែងមួយ ហើយបោះបង់សំណើនោះ។

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

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

តើវាអាចទៅរួចទេក្នុងការផ្តល់លទ្ធផលនៃសំណួរមួយទៅកាន់អតិថិជនដប់?

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

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

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

ទោះយ៉ាងណាក៏ដោយ យើងក៏ប្រឈមមុខនឹងស្ថានភាពនេះដែរ។ ឧទាហរណ៍ជាក់ស្តែងជាពិសេសគឺសំណួរដែលមាន  pagination ។ មានរបាយការណ៍មួយ វាមានទំព័រជាច្រើន ហើយមានសំណើសុំដែនកំណត់ 10. បន្ទាប់មករឿងដដែល ប៉ុន្តែកំណត់ 10,10 ។ បន្ទាប់មកទំព័របន្ទាប់មួយទៀត។ ហើយ​សំណួរ​សួរថា ហេតុអ្វី​បានជា​យើង​រាប់​ទាំងអស់​នេះ​រាល់ពេល​? ប៉ុន្តែ​ពេល​នេះ​គ្មាន​ដំណោះ​ស្រាយ​ទេ ហើយ​ក៏​គ្មាន​វិធី​ដើម្បី​ជៀស​វាង​ដែរ។

មានដំណោះស្រាយជំនួសដែលត្រូវបានដាក់ជា sidecar នៅជាប់ ClickHouse - ប្រូកស៊ី ClickHouse.

Kirill Shvakov៖ ClickHouse Proxy មានកម្មវិធីកំណត់អត្រាដែលភ្ជាប់មកជាមួយ និងឃ្លាំងសម្ងាត់លទ្ធផលដែលភ្ជាប់មកជាមួយ។ ការកំណត់ជាច្រើនត្រូវបានធ្វើឡើងនៅទីនោះ ដោយសារបញ្ហាស្រដៀងគ្នាកំពុងត្រូវបានដោះស្រាយ។ ប្រូកស៊ីអនុញ្ញាតឱ្យអ្នកកំណត់សំណើដោយតម្រង់ជួរ និងកំណត់រយៈពេលដែលឃ្លាំងសម្ងាត់សំណើមានជីវិត។ ប្រសិនបើសំណើពិតជាដូចគ្នា ប្រូកស៊ីនឹងផ្ញើវាច្រើនដង ប៉ុន្តែនឹងទៅ ClickHouse តែម្តងគត់។

Nginx ក៏មានឃ្លាំងសម្ងាត់នៅក្នុងកំណែឥតគិតថ្លៃ ហើយវានឹងដំណើរការផងដែរ។ Nginx ថែមទាំងមានការកំណត់ថាប្រសិនបើសំណើមកដល់ក្នុងពេលតែមួយ វានឹងបន្ថយល្បឿនផ្សេងទៀតរហូតដល់ការស្នើសុំមួយត្រូវបានបញ្ចប់។ ប៉ុន្តែវាគឺនៅក្នុង ClickHouse Proxy ដែលការដំឡើងត្រូវបានធ្វើបានប្រសើរជាងមុន។ វាត្រូវបានធ្វើឡើងជាពិសេសសម្រាប់ ClickHouse ជាពិសេសសម្រាប់សំណើទាំងនេះ ដូច្នេះវាសមស្របជាង។ ជាការប្រសើរណាស់, វាងាយស្រួលក្នុងការដំឡើង។

ចុះប្រតិបត្តិការអសមកាល និងទិដ្ឋភាពជាក់ស្តែង?

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

មានដំណោះស្រាយជាក់ស្តែងមួយ - ដើម្បីអនុវត្តគន្លឹះនៅលើថ្នាក់ជាក់លាក់នៃ matviews កំឡុងពេលប្រតិបត្តិការដួលរលំអសមកាល។ តើ​មាន​គ្រាប់​ប្រាក់ ឬ​មាន​គម្រោង​អនុវត្ត​មុខងារ​ស្រដៀង​គ្នា​នេះ​ដែរ​ឬ​ទេ?

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

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

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

ហើយវាក៏សំខាន់ផងដែរ ពីរបៀបដែលវាដំណើរការសម្រាប់ទស្សនៈជាក់ស្តែង។ ប្រសិនបើទិន្នន័យត្រូវបានចម្លងនៅពេលបញ្ចូលទៅក្នុងតារាងមេ នោះវានឹងមិនចូលទៅក្នុងទិដ្ឋភាពជាក់ស្តែងនោះទេ។

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

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

Kirill Shvakov៖ យើង​ក៏​មាន​ការ​សាង​សង់​ឈើ​ច្រត់​កាល​ពី​ថ្ងៃ​នោះ​ដែរ។ មានបញ្ហាដែលថាមានការចាប់អារម្មណ៍លើការផ្សាយពាណិជ្ជកម្ម ហើយមានទិន្នន័យមួយចំនួនដែលយើងអាចបង្ហាញក្នុងពេលជាក់ស្តែង - ទាំងនេះគ្រាន់តែជាការចាប់អារម្មណ៍ប៉ុណ្ណោះ។ ពួកវាកម្រចម្លងគ្នាណាស់ ប៉ុន្តែប្រសិនបើរឿងនេះកើតឡើង យើងនឹងបង្រួមវានៅពេលក្រោយ។ ហើយមានរឿងដែលមិនអាចចម្លងបាន - ការចុច និងរឿងទាំងមូលនោះ។ ប៉ុន្តែខ្ញុំក៏ចង់បង្ហាញពួកគេស្ទើរតែភ្លាមៗដែរ។

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

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

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

ClickHouse មានកំណត់ហេតុជាច្រើន។ តើខ្ញុំអាចមើលអ្វីៗគ្រប់យ៉ាងដែលកើតឡើងចំពោះម៉ាស៊ីនមេបានដោយរបៀបណា?

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

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

មានផ្ទាំងគ្រប់គ្រង ទោះបីជាវាមិនមានស្តង់ដារក៏ដោយ។ នៅក្នុងក្រុមហ៊ុនរបស់យើង មានក្រុមប្រហែល 60 ប្រើប្រាស់ ClickHouse ហើយអ្វីដែលចម្លែកបំផុតនោះគឺថា ពួកគេជាច្រើនមានផ្ទាំងគ្រប់គ្រងដែលពួកគេបានបង្កើតសម្រាប់ខ្លួនគេ ហើយមានភាពខុសគ្នាបន្តិចបន្តួច។ ក្រុមខ្លះប្រើការដំឡើង Yandex.Cloud ខាងក្នុង។ មានរបាយការណ៍ដែលត្រៀមរួចជាស្រេចមួយចំនួន ទោះបីជាមិនមែនទាំងអស់ដែលចាំបាច់ក៏ដោយ។ អ្នកផ្សេងទៀតមានផ្ទាល់ខ្លួន។

សហការីរបស់ខ្ញុំមកពី Metrica មានផ្ទាំងគ្រប់គ្រងផ្ទាល់របស់ពួកគេនៅ Grafana ហើយខ្ញុំមានផ្ទាល់ខ្លួនសម្រាប់ចង្កោមរបស់ពួកគេ។ ខ្ញុំកំពុងមើលអ្វីៗនៅទីនោះដូចជា cache hit សម្រាប់ serif cache។ ហើយអ្វីដែលពិបាកជាងនេះទៅទៀតនោះគឺថាយើងប្រើប្រាស់ឧបករណ៍ផ្សេងៗ។ ខ្ញុំ​បាន​បង្កើត​ផ្ទាំង​គ្រប់គ្រង​របស់​ខ្ញុំ​ដោយ​ប្រើ​ឧបករណ៍​ចាស់​ណាស់​ដែល​មាន​ឈ្មោះ​ថា Graphite-web។ គាត់អាក្រក់ទាំងស្រុង។ ហើយនោះជារបៀបដែលខ្ញុំនៅតែប្រើវា ទោះបីជា Grafana ប្រហែលជាមានភាពងាយស្រួល និងស្រស់ស្អាតជាងក៏ដោយ។

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

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

ខ្ញុំបានជិះកង់ដោយខ្លួនឯង។ ប៉ុន្តែខ្ញុំមានសំណួរមួយ៖ ប្រសិនបើវាជាស្តង់ដារទាំងអស់ ហើយ Grafana ត្រូវបានប្រើប្រាស់ដោយមនុស្សគ្រប់គ្នា ហេតុអ្វីបានជាមិនមានផ្ទាំងគ្រប់គ្រងផ្លូវការបែបនេះនៅក្នុង Yandex?

Kirill Shvakov៖ តាមពិតទៅ ប្រភពទិន្នន័យដែលទៅ ClickHouse ឥឡូវនេះគាំទ្រ Altinity ។ ហើយខ្ញុំគ្រាន់តែចង់ផ្តល់វ៉ិចទ័រនៃកន្លែងដែលត្រូវជីក និងអ្នកណាត្រូវរុញ។ អ្នកអាចសួរពួកគេព្រោះ Yandex នៅតែបង្កើត ClickHouse ហើយមិនមែនជារឿងជុំវិញវាទេ។ Altinity គឺជាក្រុមហ៊ុនសំខាន់ដែលកំពុងផ្សព្វផ្សាយ ClickHouse ។ គេ​មិន​បោះបង់​គាត់​ចោល​ទេ តែ​នឹង​គាំទ្រ​គាត់។ ដោយសារតែជាគោលការណ៍ដើម្បីផ្ទុកផ្ទាំងគ្រប់គ្រងទៅគេហទំព័រ Grafana អ្នកគ្រាន់តែត្រូវចុះឈ្មោះ និងបង្ហោះវាប៉ុណ្ណោះ - មិនមានបញ្ហាពិសេសទេ។

Alexey Milovidov៖ កាលពីឆ្នាំមុន ClickHouse បានបន្ថែមសមត្ថភាពបង្កើតទម្រង់សំណួរជាច្រើន។ មានម៉ែត្រសម្រាប់សំណើនីមួយៗទាក់ទងនឹងការប្រើប្រាស់ធនធាន។ ហើយទើបតែថ្មីៗនេះ យើងបានបន្ថែមកម្រងព័ត៌មានសំណួរកម្រិតទាប ដើម្បីមើលកន្លែងដែលសំណួរត្រូវចំណាយរៀងរាល់មិល្លីវិនាទី។ ប៉ុន្តែដើម្បីប្រើមុខងារនេះ ខ្ញុំត្រូវបើកម៉ាស៊ីនភ្ញៀវកុងសូល ហើយវាយពាក្យស្នើសុំ ដែលខ្ញុំតែងតែភ្លេច។ ខ្ញុំ​បាន​រក្សា​ទុក​វា​នៅ​កន្លែង​ណា​មួយ ហើយ​បន្ត​ភ្លេច​កន្លែង​ណា​ឱ្យ​ប្រាកដ។

ខ្ញុំ​ប្រាថ្នា​ចង់​មាន​ឧបករណ៍​ដែល​និយាយ​យ៉ាង​សាមញ្ញ​ថា​នេះ​ជា​សំណួរ​ធ្ងន់ៗ​របស់​អ្នក​ដែល​ត្រូវ​បាន​ដាក់​ជា​ក្រុម​តាម​ថ្នាក់​សំណួរ។ ខ្ញុំបានចុចមួយ ហើយពួកគេនឹងប្រាប់ខ្ញុំថា នោះហើយជាមូលហេតុដែលវាធ្ងន់។ មិនមានដំណោះស្រាយបែបនេះទេឥឡូវនេះ។ ហើយវាពិតជាចម្លែកណាស់នៅពេលដែលមនុស្សសួរខ្ញុំថា "ប្រាប់ខ្ញុំតើមានផ្ទាំងគ្រប់គ្រងដែលត្រៀមរួចជាស្រេចសម្រាប់ Grafana ទេ?" ខ្ញុំនិយាយថា "ចូលទៅកាន់គេហទំព័រ Grafana មានសហគមន៍ "Dashboards" ហើយមានផ្ទាំងគ្រប់គ្រង ពី Dimka មានផ្ទាំងគ្រប់គ្រងពី Kostyan ។ ខ្ញុំ​មិន​ដឹង​ថា​វា​ជា​អ្វី​ទេ ខ្ញុំ​មិន​បាន​ប្រើ​វា​ដោយ​ខ្លួន​ឯង​ទេ»។

តើធ្វើដូចម្តេចដើម្បីមានឥទ្ធិពលលើការរួមបញ្ចូលគ្នាដើម្បីកុំឱ្យ server ធ្លាក់ចូលទៅក្នុង OOM?

ខ្ញុំមានតារាងមួយ មានភាគថាសតែមួយនៅក្នុងតារាង វាគឺ ReplaceingMergeTree។ ខ្ញុំ​បាន​សរសេរ​ទិន្នន័យ​ក្នុង​វា​អស់​រយៈពេល​បួន​ឆ្នាំ​ហើយ។ ខ្ញុំត្រូវធ្វើការផ្លាស់ប្តូរនៅក្នុងវា ហើយលុបទិន្នន័យមួយចំនួន។

ខ្ញុំបានធ្វើវា ហើយក្នុងអំឡុងពេលដំណើរការសំណើនេះ អង្គចងចាំទាំងអស់នៅលើ server ទាំងអស់នៅក្នុង cluster ត្រូវបានប្រើប្រាស់ ហើយ servers ទាំងអស់នៅក្នុង cluster បានចូលទៅក្នុង OOM ។ បន្ទាប់មកពួកគេទាំងអស់គ្នាបានក្រោកឡើងជាមួយគ្នា បានចាប់ផ្តើមបញ្ចូលគ្នានូវប្រតិបត្តិការដូចគ្នានេះ ប្លុកទិន្នន័យនេះហើយបានត្រលប់ទៅ OOM វិញ។ បន្ទាប់​មក​ពួក​គេ​ក្រោក​ឡើង​វិញ ហើយ​ដួល​ម្តង​ទៀត។ ហើយរឿងនេះមិនបានបញ្ឈប់ទេ។

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

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

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

Vladimir Kolobaev៖ ល្អ នេះគឺជាពេលដែលបន្ទាប់ពីកំហុសត្រូវបានជួសជុល ខ្ញុំបានទាញយកកំណែថ្មីសម្រាប់ខ្លួនខ្ញុំ ហើយនៅលើតុមួយទៀត មួយតូចជាងដែលមានភាគថាសច្រើន ខ្ញុំបានធ្វើប្រតិបត្តិការស្រដៀងគ្នានេះ។ ហើយក្នុងអំឡុងពេលបញ្ចូលគ្នានោះ RAM ប្រហែល 100 GB ត្រូវបានដុតនៅលើម៉ាស៊ីនមេ។ ខ្ញុំបានកាន់កាប់ 150 ស៊ី 100 ហើយបង្អួច 50 GB នៅសល់ ដូច្នេះខ្ញុំមិនបានធ្លាក់ចូលទៅក្នុង OOM ទេ។

តើបច្ចុប្បន្នអ្វីដែលការពារខ្ញុំពីការធ្លាក់ចូលទៅក្នុង OOM ប្រសិនបើវាពិតជាប្រើប្រាស់ RAM 100 GB? តើ​អ្នក​គួរ​ធ្វើ​យ៉ាង​ណា​ប្រសិន​បើ RAM នៅ​លើ​ការ​បញ្ចូល​គ្នា​ភ្លាមៗ​នោះ​អស់?

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

ជាការពិតណាស់ វានឹងមិនមែនជាការនាំអោយមានដែនកំណត់ RAM ដែល "គ្រាន់តែក្នុងករណី" ការពារប្រឆាំងនឹង OOM នោះទេ។ វានឹងមិនជួយឱ្យការបញ្ចូលគ្នាដើម្បីបញ្ចប់នោះទេ វានឹងចាប់ផ្តើមម្តងទៀត ឈានដល់កម្រិតមួយចំនួន បោះករណីលើកលែងមួយ ហើយបន្ទាប់មកចាប់ផ្តើមម្តងទៀត - គ្មានអ្វីល្អនឹងមកជាមួយនោះទេ។ ប៉ុន្តែជាគោលការណ៍ វានឹងមានប្រយោជន៍ក្នុងការណែនាំការរឹតបន្តឹងនេះ។

តើកម្មវិធីបញ្ជា Golang សម្រាប់ ClickHouse នឹងត្រូវបានអភិវឌ្ឍយ៉ាងដូចម្តេច?

កម្មវិធីបញ្ជា Golang ដែលត្រូវបានសរសេរដោយ Kirill Shvakov ឥឡូវនេះត្រូវបានគាំទ្រជាផ្លូវការដោយក្រុម ClickHouse ។ គាត់ នៅក្នុងឃ្លាំង ClickHouseឥឡូវនេះគាត់ធំហើយពិត។

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

ខ្ញុំមានសំណួរពីរ។ ឥឡូវនេះកម្មវិធីបញ្ជា Golang របស់ Kirill គឺស្ទើរតែជាវិធីលំនាំដើមដើម្បីទំនាក់ទំនងពី Golang ជាមួយ ClickHouse ។ លុះត្រាតែនរណាម្នាក់នៅតែទំនាក់ទំនងតាមរយៈចំណុចប្រទាក់ http ពីព្រោះគាត់ចូលចិត្តវិធីនោះ។ តើ​ការ​អភិវឌ្ឍ​របស់​អ្នកបើកបរ​នេះ​នឹង​បន្ត​ទៅ​មុខ​យ៉ាង​ណា? តើវានឹងត្រូវបានធ្វើសមកាលកម្មជាមួយនឹងការផ្លាស់ប្តូរបំបែកណាមួយនៅក្នុងឃ្លាំងខ្លួនវាដែរឬទេ? ហើយ​អ្វី​ទៅ​ជា​នីតិវិធី​សម្រាប់​ការ​ពិចារណា​បញ្ហា​មួយ?

Kirill Shvakov៖ ទីមួយ​គឺ​របៀប​ដែល​គ្រប់​យ៉ាង​ត្រូវ​បាន​រៀបចំ​រចនាសម្ព័ន្ធ​ការិយាធិបតេយ្យ។ ចំណុច​នេះ​មិន​ត្រូវ​បាន​គេ​ពិភាក្សា​ទេ ដូច្នេះ​ខ្ញុំ​គ្មាន​អ្វី​ត្រូវ​ឆ្លើយ​ទេ។

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

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

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

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

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

ខ្ញុំមិនដឹងពីរបៀបរៀបចំរឿងនេះទេ។ ខ្ញុំមិនមានពេលច្រើនទេ។ ប្រសិន​បើ​អ្នក​ខ្លះ​បញ្ចប់​ការ​បើក​បរ ខ្ញុំ​អាច​ជួយ​ពួក​គេ ហើយ​ប្រាប់​ពួក​គេ​ពី​អ្វី​ដែល​ត្រូវ​ធ្វើ។ ប៉ុន្តែការចូលរួមយ៉ាងសកម្មរបស់ Yandex ក្នុងការអភិវឌ្ឍន៍គម្រោងមិនទាន់ត្រូវបានពិភាក្សានៅឡើយ។

Alexey Milovidov៖ តាមពិតទៅ មិនទាន់មានការិយាធិបតេយ្យនៅឡើយទេទាក់ទងនឹងអ្នកបើកបរទាំងនេះ។ រឿងតែមួយគត់គឺថាពួកគេត្រូវបានបញ្ជូនទៅអង្គការផ្លូវការមួយ ពោលគឺកម្មវិធីបញ្ជានេះត្រូវបានទទួលស្គាល់ថាជាដំណោះស្រាយលំនាំដើមផ្លូវការសម្រាប់ Go ។ មានអ្នកបើកបរខ្លះទៀត ប៉ុន្តែពួកគេមកដោយឡែកពីគ្នា។

យើងមិនមានការអភិវឌ្ឍន៍ខាងក្នុងណាមួយសម្រាប់អ្នកបើកបរទាំងនេះទេ។ សំណួរគឺថាតើយើងអាចជួលបុគ្គលម្នាក់ មិនមែនសម្រាប់អ្នកបើកបរពិសេសនេះទេ ប៉ុន្តែសម្រាប់ការអភិវឌ្ឍន៍អ្នកបើកបរសហគមន៍ទាំងអស់ ឬយើងអាចស្វែងរកនរណាម្នាក់ពីខាងក្រៅ។

វចនានុក្រម​ខាង​ក្រៅ​មិន​អាច​ទាញ​យក​បាន​ទេ បន្ទាប់​ពី​ចាប់ផ្ដើម​ឡើង​វិញ​ដោយ​បើក​ការ​កំណត់ lazy_load។ អ្វី​ដែល​ត្រូវធ្វើ?

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

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

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

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

ចម្លើយចំពោះសំណួរចុងក្រោយគឺកំណែចាស់ ឬវាត្រូវការបំបាត់កំហុស។

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

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

ខ្ញុំ​ចង់​ធ្វើ​ឱ្យ​អ្នក​សប្បាយ​ចិត្ត។ ឥរិយាបថនេះត្រូវបានផ្លាស់ប្តូរ។ នេះមានន័យថាប្រសិនបើអ្នកធ្វើបច្ចុប្បន្នភាព ClickHouse វានឹងផ្លាស់ប្តូរផងដែរ។ ប្រសិនបើអ្នកមិនសប្បាយចិត្តនឹងអាកប្បកិរិយាបច្ចុប្បន្នរបស់អ្នក។ ប្រព័ន្ធផ្ទុកវចនានុក្រមឡើងវិញធ្វើបច្ចុប្បន្នភាពដោយខ្លួនឯង ហើយសង្ឃឹមថាវានឹងផ្លាស់ប្តូរកាន់តែប្រសើរឡើង។

តើមានវិធីដើម្បីកំណត់រចនាសម្ព័ន្ធព័ត៌មានលម្អិតនៅក្នុង ClickHouse config ប៉ុន្តែមិនបង្ហាញពួកវាក្នុងករណីមានកំហុសទេ?

សំណួរបន្ទាប់គឺអំពីកំហុសទាក់ទងនឹងវចនានុក្រម ពោលគឺព័ត៌មានលម្អិត។ យើងបានបញ្ជាក់ព័ត៌មានលម្អិតនៃការតភ្ជាប់នៅក្នុង ClickHouse config សម្រាប់វចនានុក្រម ហើយប្រសិនបើមានកំហុស យើងទទួលបានព័ត៌មានលម្អិតទាំងនេះ និងពាក្យសម្ងាត់ជាការឆ្លើយតប។

យើងបានដោះស្រាយកំហុសនេះដោយបន្ថែមព័ត៌មានលម្អិតទៅការកំណត់កម្មវិធីបញ្ជា ODBC ។ តើ​មាន​វិធី​ណា​មួយ​ក្នុង​ការ​កំណត់​រចនាសម្ព័ន្ធ​សេចក្ដី​លម្អិត​ក្នុង​ការ​កំណត់​រចនាសម្ព័ន្ធ ClickHouse ប៉ុន្តែ​មិន​បង្ហាញ​សេចក្ដី​លម្អិត​ទាំង​នេះ​ក្នុង​ករណី​មាន​កំហុស​ទេ?

ដំណោះស្រាយពិតប្រាកដនៅទីនេះគឺដើម្បីបញ្ជាក់អត្តសញ្ញាណទាំងនេះនៅក្នុង odbc.ini ហើយនៅក្នុង ClickHouse ខ្លួនវាផ្ទាល់ដើម្បីបញ្ជាក់តែឈ្មោះប្រភពទិន្នន័យ ODBC ប៉ុណ្ណោះ។ វានឹងមិនកើតឡើងសម្រាប់ប្រភពវចនានុក្រមផ្សេងទៀតទេ - ទាំងវចនានុក្រមជាមួយ MySQL ឬសម្រាប់អ្នកផ្សេងទៀត អ្នកមិនគួរឃើញពាក្យសម្ងាត់នៅពេលទទួលបានសារកំហុស។ សម្រាប់ ODBC ខ្ញុំនឹងមើលផងដែរ - ប្រសិនបើវាមាន អ្នកគ្រាន់តែត្រូវការលុបវាចេញ។

ប្រាក់រង្វាន់៖ ពង្រីកផ្ទៃខាងក្រោយពីការជួបជុំ

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

ប្រភព: www.habr.com