🥇HighLoad++, Yuri Nasretdinov (VKontakte)៖ របៀបដែល VK បញ្ចូលទិន្នន័យទៅក្នុង ClickHouse ពីម៉ាស៊ីនមេរាប់ម៉ឺន

HighLoad++ Moscow 2018, សាលសភា។ ថ្ងៃទី 9 ខែវិច្ឆិកាម៉ោង 15:00

សេចក្តីសង្ខេប និងបទបង្ហាញ៖ http://www.highload.ru/moscow/2018/abstracts/4066

Yuri Nasretdinov (VKontakte)៖ របាយការណ៍នឹងនិយាយអំពីបទពិសោធន៍នៃការអនុវត្ត ClickHouse នៅក្នុងក្រុមហ៊ុនរបស់យើង - ហេតុអ្វីបានជាយើងត្រូវការវា តើយើងរក្សាទុកទិន្នន័យប៉ុន្មាន របៀបដែលយើងសរសេរវាជាដើម។

សំភារៈបន្ថែម៖ ដោយប្រើ Clickhouse ជាការជំនួសសម្រាប់ ELK, Big Query និង TimescaleDB

Yuri Nasretdinov៖ - សួស្តីអ្នកទាំងអស់គ្នា! ឈ្មោះរបស់ខ្ញុំគឺ Yuri Nasretdinov ដូចដែលខ្ញុំបានណែនាំរួចហើយ។ ខ្ញុំធ្វើការនៅ VKontakte ។ ខ្ញុំនឹងនិយាយអំពីរបៀបដែលយើងបញ្ចូលទិន្នន័យទៅក្នុង ClickHouse ពីកងនាវាម៉ាស៊ីនមេរបស់យើង (រាប់ម៉ឺននាក់)។

តើឈើមានអ្វីខ្លះ ហើយហេតុអ្វីបានជាប្រមូលវា?

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

ហេតុអ្វីបានជាយើងត្រូវធ្វើអ្វីទាំងអស់ (អ្វីគ្រប់យ៉ាងតែងតែល្អនៅលើ VKontakte មែនទេ?) យើងចង់ប្រមូលកំណត់ហេតុបំបាត់កំហុស (ហើយមានទិន្នន័យរាប់រយ terabytes នៅទីនោះ) ប្រហែលជាវាងាយស្រួលជាងក្នុងការគណនាស្ថិតិ។ ហើយយើងមានម៉ាស៊ីនបម្រើរាប់ម៉ឺនដែលអ្វីៗទាំងអស់នេះត្រូវធ្វើ។

ហេតុអ្វីបានជាយើងសម្រេចចិត្ត? យើងប្រហែលជាមានដំណោះស្រាយសម្រាប់ការរក្សាទុកកំណត់ហេតុ។ នៅទីនេះ - មាន "Backend VK" សាធារណៈបែបនេះ។ ខ្ញុំសូមផ្តល់អនុសាសន៍យ៉ាងខ្លាំងឱ្យជាវទៅវា។

តើកំណត់ហេតុជាអ្វី? នេះគឺជាម៉ាស៊ីនដែលត្រឡប់អារេទទេ។ ម៉ាស៊ីននៅក្នុង VK គឺជាអ្វីដែលអ្នកផ្សេងទៀតហៅថា microservices ។ ហើយនេះគឺជាស្ទីគ័រញញឹម (មានអ្នកចូលចិត្តច្រើនណាស់)។ យ៉ាងម៉េចដែរ? អញ្ចឹងស្តាប់បន្តទៀត!

តើអ្វីអាចប្រើដើម្បីរក្សាទុកកំណត់ហេតុ? វាមិនអាចទៅរួចទេដែលមិននិយាយអំពី Hadup ។ បន្ទាប់មកឧទាហរណ៍ Rsyslog (រក្សាទុកកំណត់ហេតុទាំងនេះនៅក្នុងឯកសារ) ។ អិលអេសឌី។ អ្នកណាដឹងថា LSD ជាអ្វី? ទេ មិនមែន LSD នេះទេ។ រក្សាទុកឯកសាររៀងៗខ្លួនផងដែរ។ ជាការប្រសើរណាស់, ClickHouse គឺជាជម្រើសចម្លែក។

Clickhouse និងអ្នកប្រកួតប្រជែង៖ តម្រូវការ និងឱកាស

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

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

តោះមើលអ្វីដែលប្រភពបើកចំហផ្តល់ឱ្យយើង។ ដំបូងយើងមាន Logs Engine - នេះគឺជាម៉ាស៊ីនរបស់យើង; ជាគោលការណ៍ គាត់អាចធ្វើអ្វីគ្រប់យ៉ាង គាត់ថែមទាំងអាចសរសេរបន្ទាត់វែងៗទៀតផង។ ជាការប្រសើរណាស់ វាមិនមានតម្លាភាពក្នុងការបង្ហាប់ទិន្នន័យទេ យើងអាចបង្ហាប់ជួរឈរធំៗដោយខ្លួនឯងបាន ប្រសិនបើយើងចង់... យើងមិនចង់ (ប្រសិនបើអាច)។ បញ្ហាតែមួយគត់គឺថាគាត់អាចផ្តល់ឱ្យតែអ្វីដែលសមនៅក្នុងការចងចាំរបស់គាត់; ដើម្បីអានអ្វីដែលនៅសល់ អ្នកត្រូវយក binlog របស់ម៉ាស៊ីននេះ ហើយតាមនោះ វាត្រូវចំណាយពេលយូរណាស់។

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

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

បន្ទាប់មកមានការអភិវឌ្ឍន៍ "badushka" នៃ LSD ។ សំខាន់ដូចគ្នានឹង "Rsyslog"៖ វាគាំទ្រខ្សែវែងប៉ុន្តែវាមិនអាចដំណើរការបានតាមរយៈ UDP ហើយតាមពិតដោយសារតែរឿងនេះ ជាអកុសល រឿងជាច្រើនចាំបាច់ត្រូវសរសេរឡើងវិញនៅទីនោះ។ LSD ត្រូវបានរចនាឡើងវិញដើម្បីអាចកត់ត្រាពីម៉ាស៊ីនបម្រើរាប់ម៉ឺន។

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

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

តើយើងនឹងបញ្ចូលវាដោយរបៀបណា? មែកធាង

តើអ្នកណាខ្លះដែលមិនទាន់បានឮ ឬដឹងអំពី "ClickHouse"? ខ្ញុំត្រូវប្រាប់អ្នកមែនទេ? លឿនណាស់។ ការបញ្ចូលនៅទីនោះ - 1-2 ជីហ្គាបៃក្នុងមួយវិនាទីការផ្ទុះឡើងដល់ 10 ជីហ្គាបៃក្នុងមួយវិនាទីពិតជាអាចទប់ទល់នឹងការកំណត់រចនាសម្ព័ន្ធនេះ - មាន Xeons 6-core ចំនួនពីរ (ដែលមិនមែនសូម្បីតែខ្លាំងបំផុត) RAM 256 ជីហ្គាបៃ 20 តេរ៉ាបៃ នៅក្នុង RAID (គ្មាននរណាម្នាក់បានកំណត់រចនាសម្ព័ន្ធទេ ការកំណត់លំនាំដើម)។ Alexey Milovidov អ្នកអភិវឌ្ឍន៍ ClickHouse ប្រហែលជាអង្គុយយំនៅទីនោះ ពីព្រោះយើងមិនបានកំណត់រចនាសម្ព័ន្ធអ្វីទាំងអស់ (អ្វីៗដំណើរការដូចនោះសម្រាប់យើង)។ ដូច្នោះហើយ ល្បឿនស្កេនប្រហែល 6 ពាន់លានបន្ទាត់ក្នុងមួយវិនាទីអាចទទួលបាន ប្រសិនបើទិន្នន័យត្រូវបានបង្ហាប់បានល្អ។ ប្រសិនបើអ្នកចូលចិត្ត % នៅលើខ្សែអក្សរ - 100 លានបន្ទាត់ក្នុងមួយវិនាទី នោះគឺវាហាក់ដូចជាលឿនណាស់។

តើយើងនឹងបញ្ចូលវាដោយរបៀបណា? អ្នកដឹងថា VK ប្រើ PHP ។ យើងនឹងបញ្ចូលពីបុគ្គលិក PHP នីមួយៗតាមរយៈ HTTP ទៅក្នុង “ClickHouse” ទៅក្នុងតារាង MergeTree សម្រាប់កំណត់ត្រានីមួយៗ។ តើអ្នកណាឃើញបញ្ហាជាមួយគ្រោងការណ៍នេះ? សម្រាប់ហេតុផលមួយចំនួន មិនមែនគ្រប់គ្នាលើកដៃឡើងនោះទេ។ ចាំខ្ញំុប្រាប់អ្នក។

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

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

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

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

ធ្វើការជាមួយតារាងសតិបណ្ដោះអាសន្ន

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

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

តើ Kittenhouse គឺជាអ្វី ហើយតើវាដំណើរការយ៉ាងដូចម្តេច?

តើ KittenHouse ជាអ្វី? នេះគឺជាប្រូកស៊ី។ ទាយមើលថាភាសាអ្វី? ខ្ញុំបានប្រមូលប្រធានបទដែលបំផ្លើសបំផុតនៅក្នុងរបាយការណ៍របស់ខ្ញុំ - "Clickhouse" ទៅ ប្រហែលជាខ្ញុំនឹងចងចាំអ្វីផ្សេងទៀត។ បាទ វាត្រូវបានសរសេរនៅក្នុង Go ព្រោះខ្ញុំពិតជាមិនដឹងពីរបៀបសរសេរក្នុង C ខ្ញុំមិនចង់ទេ។

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

ប៉ុន្តែបន្ទាប់មករឿងនេះបានកើតឡើង។ យើងបានប្រើការចែកចាយដែលអាចទុកចិត្តបាន សរសេរកំណត់ហេតុ បន្ទាប់មកសម្រេចចិត្ត (វាជាចង្កោមសាកល្បងតាមលក្ខខណ្ឌ)... វាត្រូវបានដាក់ចេញអស់រយៈពេលជាច្រើនម៉ោង ហើយបានត្រលប់មកវិញ ហើយការបញ្ចូលបានចាប់ផ្តើមពីម៉ាស៊ីនមេមួយពាន់ - វាប្រែថា Clickhouse នៅតែមាន "Thread on connection" - ដូច្នោះហើយនៅក្នុងការតភ្ជាប់មួយពាន់ការបញ្ចូលសកម្មនាំឱ្យមានការផ្ទុកជាមធ្យមនៅលើម៉ាស៊ីនមេប្រហែលមួយពាន់កន្លះ។ គួរឱ្យភ្ញាក់ផ្អើល ម៉ាស៊ីនមេបានទទួលយកសំណើ ប៉ុន្តែទិន្នន័យនៅតែត្រូវបានបញ្ចូលបន្ទាប់ពីពេលខ្លះ។ ប៉ុន្តែវាពិបាកណាស់សម្រាប់ម៉ាស៊ីនបម្រើក្នុងការបម្រើវា...

បន្ថែម nginx

ដំណោះស្រាយបែបនេះសម្រាប់ Thread per connection model គឺ nginx ។ យើងបានដំឡើង nginx នៅពីមុខ Clickhouse ក្នុងពេលដំណាលគ្នារៀបចំសមតុល្យសម្រាប់ការចម្លងពីរ (ល្បឿនបញ្ចូលរបស់យើងកើនឡើង 2 ដង ទោះបីជាវាមិនមែនជាការពិតក៏ដោយ) និងកំណត់ចំនួននៃការតភ្ជាប់ទៅ Clickhouse ទៅ ឡើងលើ ហើយតាមនោះ ច្រើនជាង 50 ការតភ្ជាប់ វាហាក់បីដូចជាគ្មានចំណុចណាមួយក្នុងការបញ្ចូលទេ។

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

បន្ទាប់មកយើងបានរកឃើញបញ្ហាដ៏គួរឱ្យចាប់អារម្មណ៍នេះ៖ ប្រសិនបើអ្នកប្រើវិធីសាស្ត្រមិនស្តង់ដារនៃការបញ្ចូលក្នុងរបៀប SQL វាបង្ខំ AST-based SQL parser ដែលមានភាពយឺតយ៉ាវ។ អាស្រ័យហេតុនេះ យើងបានបន្ថែមការកំណត់ដើម្បីធានាថាវាមិនដែលកើតឡើងនោះទេ។ យើងបានផ្ទុកតុល្យភាព ពិនិត្យសុខភាព ដូច្នេះប្រសិនបើមនុស្សម្នាក់ស្លាប់ យើងនៅតែទុកទិន្នន័យ។ ឥឡូវនេះយើងមានតារាងជាច្រើនដែលយើងត្រូវមានចង្កោម Clickhouse ផ្សេងៗគ្នា។ ហើយយើងក៏ចាប់ផ្តើមគិតអំពីការប្រើប្រាស់ផ្សេងទៀតផងដែរ - ឧទាហរណ៍ យើងចង់សរសេរកំណត់ហេតុពីម៉ូឌុល nginx ប៉ុន្តែពួកគេមិនដឹងពីរបៀបទំនាក់ទំនងដោយប្រើ RPC របស់យើង។ ជាការប្រសើរណាស់, ខ្ញុំចង់បង្រៀនពួកគេពីរបៀបផ្ញើយ៉ាងហោចណាស់ដូចម្ដេច - ឧទាហរណ៍, ដើម្បីទទួលបានព្រឹត្តិការណ៍នៅលើ localhost តាមរយៈ UDP ហើយបន្ទាប់មកបញ្ជូនពួកគេទៅ Clickhouse ។

មួយជំហានឆ្ងាយពីដំណោះស្រាយ

គ្រោងការណ៍ចុងក្រោយបានចាប់ផ្តើមមើលទៅដូចនេះ (កំណែទីបួននៃគ្រោងការណ៍នេះ): នៅលើម៉ាស៊ីនមេនីមួយៗនៅពីមុខ Clickhouse មាន nginx (នៅលើម៉ាស៊ីនមេដូចគ្នា) ហើយវាគ្រាន់តែស្នើសុំប្រូកស៊ីទៅម៉ាស៊ីនមេដែលមានដែនកំណត់លើចំនួននៃការតភ្ជាប់ 50 បំណែក។ ហើយគ្រោងការណ៍នេះបានដំណើរការល្អហើយ អ្វីៗគឺល្អជាមួយវា។

យើងរស់នៅបែបនេះប្រហែលមួយខែ។ មនុស្សគ្រប់គ្នាសប្បាយចិត្ត ពួកគេបានបន្ថែមតារាង ពួកគេបានបន្ថែម ពួកគេបានបន្ថែម... ជាទូទៅ វាប្រែថាវិធីដែលយើងបន្ថែមតារាងសតិបណ្ដោះអាសន្នគឺមិនល្អបំផុតទេ (សូមដាក់វាតាមវិធីនោះ)។ យើងបានធ្វើ 16 បំណែកក្នុងតារាងនីមួយៗ និងចន្លោះពេលពីរបីវិនាទី។ យើងមានតារាងចំនួន 20 ហើយតារាងនីមួយៗបានទទួលការបញ្ចូលចំនួន 8 ក្នុងមួយវិនាទី ហើយនៅចំណុចនេះ "Clickhouse" បានចាប់ផ្តើម... កំណត់ត្រាបានចាប់ផ្តើមថយចុះ។ មិនត្រឹមតែមិនឆ្លង... តាមលំនាំដើម nginx មានរឿងគួរឱ្យចាប់អារម្មណ៍មួយថា ប្រសិនបើការតភ្ជាប់បានបញ្ចប់នៅចរន្តទឹក នោះវាគ្រាន់តែត្រឡប់ "502" ទៅនឹងសំណើថ្មីទាំងអស់។

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

ការជំនួស nginx ដោយប្រើប្រូកស៊ីបញ្ច្រាស

ខ្ញុំបានសម្រេចចិត្តថាយើងត្រូវគ្រប់គ្រងវាដោយខ្លួនឯង យើងមិនចាំបាច់ទុកវាទៅ nginx ទេ - nginx មិនដឹងថាមានតារាងអ្វីខ្លះនៅក្នុង Clickhouse ហើយខ្ញុំបានជំនួស nginx ដោយប្រូកស៊ីបញ្ច្រាស ដែលខ្ញុំក៏បានសរសេរខ្លួនឯងដែរ។

តើគាត់កំពុងធ្វើអ្វី? វាដំណើរការដោយផ្អែកលើបណ្ណាល័យ fasthttp "goshnoy" នោះគឺលឿនស្ទើរតែលឿនដូច nginx ។ សូមអភ័យទោស Igor ប្រសិនបើអ្នកមានវត្តមាននៅទីនេះ (ចំណាំ៖ Igor Sysoev គឺជាអ្នកសរសេរកម្មវិធីជនជាតិរុស្សីដែលបានបង្កើតម៉ាស៊ីនមេបណ្តាញ nginx)។ វាអាចយល់ពីប្រភេទនៃសំណួរទាំងនេះ - INSERT ឬ SELECT - អាស្រ័យហេតុនេះ វាផ្ទុកនូវបណ្តុំនៃការតភ្ជាប់ផ្សេងៗគ្នាសម្រាប់ប្រភេទសំណួរផ្សេងៗគ្នា។

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

ការបញ្ចូលការធ្វើសមកាលកម្ម និងការជំនួសជាសំខាន់ nginx ធ្វើដូចគ្នានឹង nginx ពីមុនដែរ - អ្នកមិនចាំបាច់ផ្លាស់ប្តូរ "Kittenhouse" ក្នុងស្រុកសម្រាប់រឿងនេះទេ។ ហើយចាប់តាំងពីវាប្រើ fasthttp វាលឿនណាស់ - អ្នកអាចធ្វើសំណើច្រើនជាង 100 ពាន់ក្នុងមួយវិនាទីសម្រាប់ការបញ្ចូលតែមួយតាមរយៈប្រូកស៊ីបញ្ច្រាស។ តាមទ្រឹស្តី អ្នកអាចបញ្ចូលបន្ទាត់មួយក្នុងពេលតែមួយទៅក្នុងប្រូកស៊ីបញ្ច្រាសរបស់ kittenhouse ប៉ុន្តែយើងមិនធ្វើដូច្នោះទេ។

គ្រោងការណ៍បានចាប់ផ្តើមមើលទៅដូចនេះ: "Kittenhouse" ដែលជាប្រូកស៊ីបញ្ច្រាសដាក់សំណើជាច្រើនចូលទៅក្នុងតារាងហើយផ្ទុយទៅវិញតារាងទ្រនាប់បញ្ចូលពួកវាទៅក្នុងផ្នែកសំខាន់ៗ។

ឃាតករគឺជាដំណោះស្រាយបណ្តោះអាសន្ន Kitten គឺអចិន្រ្តៃយ៍

នេះជាបញ្ហាគួរឱ្យចាប់អារម្មណ៍... មានអ្នកណាបានប្រើ fasthttp ទេ? តើអ្នកណាបានប្រើ fasthttp ជាមួយសំណើ POST? ប្រហែលជា នេះពិតជាមិនគួរត្រូវបានធ្វើទេ ព្រោះវាផ្ទុកផ្នែកសំណើតាមលំនាំដើម ហើយទំហំសតិបណ្ដោះអាសន្នរបស់យើងត្រូវបានកំណត់ទៅ 16 មេកាបៃ។ សិលាចារឹកបានឈប់បន្តនៅចំណុចមួយចំនួន ហើយកំណាត់ទំហំ 16 មេកាបៃបានចាប់ផ្តើមមកដល់ពីគ្រប់ម៉ាស៊ីនមេរាប់ម៉ឺន ហើយពួកវាទាំងអស់ត្រូវបានផ្ទុកនៅក្នុងអង្គចងចាំមុនពេលបញ្ជូនទៅ Clickhouse ។ ដូច្នោះហើយ អង្គចងចាំបានអស់ ឃាតករក្រៅសតិបានមកសម្លាប់ប្រូកស៊ីបញ្ច្រាស (ឬ "Clickhouse" ដែលតាមទ្រឹស្តីអាច "ស៊ី" ច្រើនជាងប្រូកស៊ីបញ្ច្រាស) ។ វដ្តនេះបានធ្វើម្តងទៀតដោយខ្លួនឯង។ មិនមែនជាបញ្ហាដ៏រីករាយទេ។ ទោះបីជាយើងជំពប់ដួលលើរឿងនេះតែបន្ទាប់ពីប្រតិបត្តិការជាច្រើនខែ។

តើខ្ញុំបានធ្វើអ្វីខ្លះ? ជាថ្មីម្តងទៀត ខ្ញុំពិតជាមិនចង់យល់ថាអ្វីដែលបានកើតឡើងពិតប្រាកដ។ ខ្ញុំគិតថាវាច្បាស់ណាស់ដែលអ្នកមិនគួរទុកក្នុងការចងចាំ។ ខ្ញុំមិនអាចធ្វើការជួសជុលបានលឿន http ទោះបីជាខ្ញុំព្យាយាមក៏ដោយ។ ប៉ុន្តែខ្ញុំបានរកឃើញវិធីមួយដើម្បីធ្វើវា ដើម្បីកុំឱ្យវាត្រូវការបំណះអ្វីទាំងអស់ ហើយខ្ញុំបានបង្កើតវិធីផ្ទាល់ខ្លួនរបស់ខ្ញុំនៅក្នុង HTTP - ខ្ញុំបានហៅវាថា KITTEN ។ ជាការប្រសើរណាស់, វាជាឡូជីខល - "VK", "Kitten" ... តើមានអ្វីទៀត? ..

ប្រសិនបើសំណើមកដល់ម៉ាស៊ីនមេដោយប្រើវិធីសាស្ត្រ Kitten នោះម៉ាស៊ីនមេគួរតែឆ្លើយតប "meow" - ឡូជីខល។ ប្រសិនបើគាត់ឆ្លើយតបនឹងបញ្ហានេះ វាត្រូវបានចាត់ទុកថាគាត់យល់អំពីពិធីការនេះ ហើយបន្ទាប់មកខ្ញុំស្ទាក់ចាប់ការតភ្ជាប់ (fasthttp មានវិធីសាស្ត្របែបនេះ) ហើយការតភ្ជាប់នឹងចូលទៅក្នុងរបៀប "ឆៅ" ។ ហេតុអ្វីបានជាខ្ញុំត្រូវការវា? ខ្ញុំចង់គ្រប់គ្រងរបៀបដែលការអានពីការតភ្ជាប់ TCP កើតឡើង។ TCP មានទ្រព្យសម្បត្តិដ៏អស្ចារ្យមួយ៖ ប្រសិនបើគ្មាននរណាម្នាក់កំពុងអានពីផ្នែកម្ខាងទៀតនោះ ការសរសេរចាប់ផ្តើមរង់ចាំ ហើយការចងចាំមិនត្រូវបានចំណាយជាពិសេសលើរឿងនេះទេ។

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

តារាងបណ្ដោះអាសន្នគឺសោកសៅ

ថ្មីៗនេះ យើងបានជួបប្រទះលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍មួយផ្សេងទៀតនៃតារាងសតិបណ្ដោះអាសន្ន។ ហើយបញ្ហានេះមានការឈឺចាប់ខ្លាំងជាងបញ្ហាផ្សេងៗរួចទៅហើយ។ ចូរស្រមៃមើលស្ថានភាពនេះ៖ អ្នកកំពុងប្រើ Clickhouse យ៉ាងសកម្មរួចហើយ អ្នកមានម៉ាស៊ីនមេ Clickhouse រាប់សិប ហើយអ្នកមានសំណើមួយចំនួនដែលចំណាយពេលអានយូរណាស់ (ឧបមាថា ច្រើនជាង ៦០ វិនាទី)។ ហើយអ្នកមកធ្វើការផ្លាស់ប្តូរនៅពេលនេះ... ក្នុងពេលនេះ "ជ្រើសរើស" ដែលបានចាប់ផ្តើមមុនពេល "Alter" នឹងមិនត្រូវបានដាក់បញ្ចូលក្នុងតារាងនេះទេ "Alter" នឹងមិនចាប់ផ្តើមទេ - ប្រហែលជាលក្ខណៈពិសេសមួយចំនួននៃរបៀបដែល "Clickhouse" ដំណើរការនៅក្នុង កន្លែងនេះ។ ប្រហែលជានេះអាចជួសជុលបានទេ? ឬវាមិនអាចទៅរួច?

ជាទូទៅ វាច្បាស់ណាស់ថា តាមពិតនេះមិនមែនជាបញ្ហាធំនោះទេ ប៉ុន្តែជាមួយនឹងតារាងសតិបណ្ដោះអាសន្ន វាកាន់តែឈឺចាប់។ ពីព្រោះ ប្រសិនបើ ឧបមាថា ការអស់ពេល "Alter" របស់អ្នក (ហើយវាអាចនឹងអស់ពេលនៅលើម៉ាស៊ីនផ្សេងទៀត - មិនមែននៅលើរបស់អ្នកទេ ប៉ុន្តែនៅលើការចម្លងជាឧទាហរណ៍) បន្ទាប់មក... អ្នកបានលុបតារាងទ្រនាប់ "Alter" របស់អ្នក ( ឬម៉ាស៊ីនផ្សេងទៀត) អស់ពេល។ បន្ទាប់មកកំហុស "Alter" បានកើតឡើង) - អ្នកនៅតែត្រូវធានាថាទិន្នន័យនៅតែបន្តត្រូវបានសរសេរ៖ អ្នកបង្កើតតារាងសតិបណ្ដោះអាសន្នត្រឡប់មកវិញ (យោងទៅតាមគ្រោងការណ៍ដូចគ្នានឹងតារាងមេ) បន្ទាប់មក "Alter" ឆ្លងកាត់ បញ្ចប់ទាំងអស់ ហើយបណ្តុំតារាងចាប់ផ្តើមខុសពីគ្រោងការណ៍ពីមេ។ អាស្រ័យលើអ្វីដែលជា "Alter" ការបញ្ចូលអាចនឹងមិនចូលទៅកាន់តារាងសតិបណ្ដោះអាសន្ននេះទៀតទេ - នេះជាការសោកស្តាយខ្លាំងណាស់។

វាក៏មានសញ្ញាបែបនេះផងដែរ (ប្រហែលជាមាននរណាម្នាក់បានកត់សម្គាល់វា) - វាត្រូវបានគេហៅថា query_thread_log នៅក្នុងកំណែថ្មីរបស់ Clickhouse ។ តាមលំនាំដើម នៅក្នុងកំណែខ្លះមានមួយ។ នៅទីនេះយើងប្រមូលបាន 840 លានកំណត់ត្រាក្នុងរយៈពេលពីរបីខែ (100 ជីហ្គាបៃ) ។ នេះគឺដោយសារតែការពិតដែលថា "ការបញ្ចូល" ត្រូវបានសរសេរនៅទីនោះ (ប្រហែលជាឥឡូវនេះពួកគេមិនត្រូវបានសរសេរទេ) ។ ដូចដែលខ្ញុំបានប្រាប់អ្នកថា "ការបញ្ចូល" របស់យើងគឺតូច - យើងមាន "ការបញ្ចូល" ជាច្រើនទៅក្នុងតារាងទ្រនាប់។ វាច្បាស់ណាស់ថាវាត្រូវបានបិទ - ខ្ញុំគ្រាន់តែប្រាប់អ្នកពីអ្វីដែលខ្ញុំបានឃើញនៅលើម៉ាស៊ីនមេរបស់យើង។ ហេតុអ្វី? នេះជាទឡ្ហីករណ៍មួយផ្សេងទៀតប្រឆាំងនឹងការប្រើប្រាស់តារាងសតិបណ្ដោះអាសន្ន! Spotty សោកសៅណាស់។

អ្នកណាដឹងថាបុរសម្នាក់នេះឈ្មោះ Spotty? បុគ្គលិក VK លើកដៃឡើង។ យល់ព្រម។

អំពីផែនការសម្រាប់ "KitttenHouse"

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

ដូច្នោះហើយ នៅពេលដែល "បញ្ចូល" ត្រូវបានធ្វើឡើង វានឹងលែងធ្វើសមកាលកម្មទៀតហើយ - វានឹងដំណើរការជាតារាងសតិបណ្ដោះអាសន្នរួចហើយ នឹងបញ្ចូលទៅក្នុងតារាងមេ (ល្អនៅថ្ងៃណាមួយនៅពេលក្រោយ) ហើយរាយការណ៍តាមរយៈឆានែលដាច់ដោយឡែកមួយ ដែលការបញ្ចូលបានកន្លងផុតទៅហើយ។ មិនមាន។

ហេតុអ្វីខ្ញុំមិនអាចចាកចេញពីការបញ្ចូល synchronous? វាកាន់តែងាយស្រួល។ ការពិតគឺថាប្រសិនបើអ្នកបញ្ចូលពី 10 ពាន់ម៉ាស៊ីនបន្ទាប់មកអ្វីគ្រប់យ៉ាងគឺល្អ - អ្នកនឹងទទួលបានបន្តិចបន្តួចពីម៉ាស៊ីននីមួយៗអ្នកបញ្ចូលទីនោះម្តងក្នុងមួយវិនាទីអ្វីគ្រប់យ៉ាងគឺល្អ។ ប៉ុន្តែខ្ញុំចង់ឱ្យគ្រោងការណ៍នេះដំណើរការឧទាហរណ៍ពីម៉ាស៊ីនពីរដើម្បីឱ្យអ្នកអាចទាញយកក្នុងល្បឿនលឿន - ប្រហែលជាមិនទទួលបានអតិបរមាពី Clickhouse ប៉ុន្តែសរសេរយ៉ាងហោចណាស់ 100 មេហ្គាបៃក្នុងមួយវិនាទីពីម៉ាស៊ីនមួយតាមរយៈប្រូកស៊ីបញ្ច្រាស - គ្រោងការណ៍នេះត្រូវតែធ្វើមាត្រដ្ឋានទាំងបរិមាណធំ និងតូច ដូច្នេះយើងមិនអាចរង់ចាំមួយវិនាទីសម្រាប់ការបញ្ចូលនីមួយៗបានទេ ដូច្នេះវាត្រូវតែអសមកាល។ ហើយតាមរបៀបដូចគ្នា ការបញ្ជាក់អសមកាលគួរតែកើតឡើងបន្ទាប់ពីការបញ្ចូលត្រូវបានបញ្ចប់។ យើងនឹងដឹងថាវាឆ្លងឬអត់។

អ្វីដែលសំខាន់បំផុតនោះគឺថានៅក្នុងគ្រោងការណ៍នេះយើងដឹងច្បាស់ថាតើការបញ្ចូលបានកើតឡើងឬអត់។ ស្រមៃមើលស្ថានភាពនេះ៖ អ្នកមានតារាងសតិបណ្ដោះអាសន្ន អ្នកសរសេរអ្វីមួយទៅក្នុងវា ហើយបន្ទាប់មកឧបមាថា តារាងបានចូលទៅក្នុងរបៀបអានតែមួយ ហើយព្យាយាមបិទសតិបណ្ដោះអាសន្ន។ តើទិន្នន័យនឹងទៅណា? ពួកគេនឹងស្ថិតនៅក្នុងបណ្តុំ។ ប៉ុន្តែយើងមិនអាចប្រាកដអំពីរឿងនេះបានទេ - តើមានអ្វីកើតឡើងប្រសិនបើមានកំហុសផ្សេងទៀតដោយសារតែទិន្នន័យនឹងមិននៅតែមាននៅក្នុងសតិបណ្ដោះអាសន្ន ... (អាសយដ្ឋាន Alexey Milovidov, Yandex, អ្នកអភិវឌ្ឍន៍ ClickHouse) ឬតើវានឹងនៅដដែល? ជានិច្ច? Alexey បញ្ចុះបញ្ចូលយើងថាអ្វីៗនឹងល្អ។ យើងគ្មានហេតុផលមិនជឿគាត់ទេ។ ប៉ុន្តែទាំងអស់ដូចគ្នា៖ ប្រសិនបើយើងមិនប្រើតារាងសតិបណ្ដោះអាសន្នទេ នោះនឹងមិនមានបញ្ហាអ្វីជាមួយពួកគេទេ។ ការបង្កើតតារាងពីរដងច្រើនជាងនេះគឺមានការរអាក់រអួលផងដែរទោះបីជាជាគោលការណ៍មិនមានបញ្ហាធំដុំក៏ដោយ។ នេះគឺជាផែនការ។

ចូរនិយាយអំពីការអាន

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

វាសាមញ្ញណាស់ - វាអាចអានបានតែទិន្នន័យប៉ុណ្ណោះ។ គាត់មិនចេះបង្ហាញក្រាហ្វិក គាត់មិនចេះធ្វើអ្វីទេ។ ប៉ុន្តែវាអាចបង្ហាញពីអ្វីដែលយើងត្រូវការ៖ ឧទាហរណ៍ តើមានជួរដេកប៉ុន្មានក្នុងតារាង តើវាមានទំហំប៉ុនណា (ដោយមិនបំបែកវាទៅជាជួរឈរ) នោះគឺជាចំណុចប្រទាក់មូលដ្ឋានបំផុតគឺជាអ្វីដែលយើងត្រូវការ។

ហើយវាមើលទៅស្រដៀងទៅនឹង Sequel Pro ប៉ុន្តែបានធ្វើតែនៅលើ Twitter's Bootstrap និងកំណែទីពីរប៉ុណ្ណោះ។ អ្នកសួរថា "Yuri ហេតុអ្វីនៅលើកំណែទីពីរ?" ឆ្នាំអ្វី? 2018? ជាទូទៅខ្ញុំបានធ្វើវាជាយូរមកហើយសម្រាប់ "សាច់ដុំ" (MySQL) ហើយទើបតែបានផ្លាស់ប្តូរពីរបីជួរនៅក្នុងសំណួរនៅទីនោះ ហើយវាបានចាប់ផ្តើមធ្វើការសម្រាប់ "Clickhouse" ដែលសូមអរគុណជាពិសេស! ដោយសារតែឧបករណ៍ញែកគឺស្រដៀងទៅនឹង "សាច់ដុំ" ហើយសំណួរគឺស្រដៀងគ្នាខ្លាំងណាស់ - ងាយស្រួលណាស់ជាពិសេសនៅពេលដំបូង។

ជាការប្រសើរណាស់, វាអាចត្រងតារាង, អាចបង្ហាញរចនាសម្ព័ន្ធនិងមាតិកានៃតារាង, អនុញ្ញាតឱ្យអ្នកតម្រៀប, ត្រងតាមជួរឈរ, បង្ហាញសំណួរដែលបណ្តាលឱ្យលទ្ធផល, ជួរដេកដែលរងផលប៉ះពាល់ (ចំនួនជាលទ្ធផល) នោះគឺ ចំណុចជាមូលដ្ឋានសម្រាប់មើលទិន្នន័យ។ លឿនណាស់។

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

"Clickhouse" គឺសមរម្យសម្រាប់ dens

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

TCP? ជាទូទៅនៅក្នុង VK វាជាទម្លាប់ក្នុងការប្រើ UDP ។ ហើយនៅពេលដែលខ្ញុំប្រើ TCP... ពិតណាស់គ្មាននរណាម្នាក់ប្រាប់ខ្ញុំថា “Yuri អ្នកកំពុងនិយាយអំពីអ្វី! អ្នកមិនអាចទេ អ្នកត្រូវការ UDP ។ វាបានប្រែក្លាយថា TCP មិនគួរឱ្យខ្លាចនោះទេ។ រឿងតែមួយគត់គឺប្រសិនបើអ្នកមានសមាសធាតុសកម្មរាប់ម៉ឺនដែលអ្នកសរសេរ អ្នកត្រូវរៀបចំវាឱ្យកាន់តែប្រុងប្រយ័ត្នបន្តិច។ ប៉ុន្តែវាអាចទៅរួច និងងាយស្រួលណាស់។

ខ្ញុំបានសន្យាថានឹងបង្ហោះ "Kittenhouse" និង "Lighthouse" នៅលើ HighLoad Siberia ប្រសិនបើអ្នកគ្រប់គ្នាបានជាវ "VK backend" ជាសាធារណៈរបស់យើង... ហើយអ្នកដឹងទេ មិនមែនគ្រប់គ្នាបានជាវទេ... ជាការពិតណាស់ ខ្ញុំនឹងមិនទាមទារឱ្យអ្នកជាវប្រចាំរបស់យើងទេ។ សាធារណៈ។ នៅមានអ្នកច្រើនពេក នរណាម្នាក់អាចនឹងអាក់អន់ចិត្ត ប៉ុន្តែនៅតែសូម Subscribe (ហើយខ្ញុំត្រូវតែធ្វើភ្នែកដូចឆ្មា)។ នោះហើយជា ភ្ជាប់ទៅវាដោយវិធីនេះ។. អរគុណច្រើន! Github គឺជារបស់យើង។ នៅទីនេះ. ជាមួយនឹង Clickhouse សក់របស់អ្នកនឹងទន់រលោង។

ដឹកនាំ៖ - មិត្តភក្តិឥឡូវនេះសម្រាប់សំណួរ។ បន្ទាប់ពីយើងបង្ហាញវិញ្ញាបនបត្រនៃការដឹងគុណ និងរបាយការណ៍របស់អ្នកនៅលើ VHS ។

Yuri Nasretdinov (តទៅនេះហៅថា YN)៖ - តើអ្នកអាចកត់ត្រារបាយការណ៍របស់ខ្ញុំនៅលើ VHS យ៉ាងដូចម្តេចប្រសិនបើវាទើបតែបញ្ចប់?

ដឹកនាំ៖ - អ្នកក៏មិនអាចកំណត់បានទាំងស្រុងថាតើ "Clickhouse" នឹងដំណើរការឬអត់! មិត្ត 5 នាទីសម្រាប់សំណួរ!

សំណួរ

សំណួរពីទស្សនិកជន (តទៅនេះហៅថា Q)៖ - សួស្តីពេលរសៀល។ សូមអរគុណច្រើនចំពោះរបាយការណ៍។ ខ្ញុំមានសំណួរពីរ។ ខ្ញុំនឹងចាប់ផ្តើមជាមួយនឹងអ្វីដែលមិនសមហេតុផល៖ តើចំនួនអក្សរ t នៅក្នុងឈ្មោះ "Kittenhouse" នៅក្នុងដ្យាក្រាម (3, 4, 7 ... ) ប៉ះពាល់ដល់ការពេញចិត្តរបស់ឆ្មាដែរឬទេ?

YN៖ - តើបរិមាណអ្វី?

Z៖ - លិខិត t ។ មានបី t កន្លែងណាមួយនៅជុំវិញបី t ។

YN៖ - តើខ្ញុំមិនបានជួសជុលវាទេ? ជាការប្រសើរណាស់, វាកើតឡើង! ទាំងនេះគឺជាផលិតផលផ្សេងៗគ្នា - ខ្ញុំគ្រាន់តែបោកបញ្ឆោតអ្នកគ្រប់ពេល។ មិនអីទេ ខ្ញុំនិយាយលេង - វាមិនសំខាន់ទេ។ អា នៅទីនេះ! អត់ទេ វាជារឿងដូចគ្នា ខ្ញុំបានធ្វើការវាយអក្សរ។

Z៖ - សូមអរគុណ។ សំណួរទីពីរគឺធ្ងន់ធ្ងរ។ តាមដែលខ្ញុំយល់ នៅក្នុង Clickhouse តារាងសតិបណ្ដោះអាសន្នរស់នៅទាំងស្រុងក្នុងអង្គចងចាំ មិនត្រូវបានផ្ទុកទៅថាសទេ ហើយតាមនោះ ក៏មិនស្ថិតស្ថេរដែរ។

YN៖ - បាទ។

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

YN៖ - បាទ តាមទ្រឹស្ដីមិនមានភាពផ្ទុយគ្នានៅទីនេះទេ ពីព្រោះនៅពេលដែល Clickhouse ធ្លាក់ចុះ អ្នកពិតជាអាចរកឃើញវាតាមវិធីផ្សេងគ្នារាប់លាន។ ប្រសិនបើ Clickhouse គាំង (ប្រសិនបើវាបញ្ចប់មិនត្រឹមត្រូវ) អ្នកអាចនិយាយឡើងវិញនូវកំណត់ហេតុរបស់អ្នកបន្តិច ដែលអ្នកបានសរសេរចុះ ហើយចាប់ផ្តើមពីពេលដែលអ្វីៗគ្រប់យ៉ាងល្អ។ ចូរនិយាយថាអ្នកត្រលប់មកវិញមួយនាទី នោះគឺវាត្រូវបានចាត់ទុកថាអ្នកបានបំប៉ោងអ្វីៗទាំងអស់ក្នុងមួយនាទី។

Z៖ - នោះគឺ “ផ្ទះកូនឆ្មា” កាន់បង្អួចយូរជាង ហើយក្នុងករណីដួលរលំ តើអាចស្គាល់វា និងបង្វិលវាវិញបានទេ?

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

Z៖ - ជំរាបសួរ។ តាំងពីដើមដំបូងមក វាហាក់ដូចជាខ្ញុំថា អ្នកពិតជានឹងប្រើ UDP តាំងពីដើមដំបូងនៃរបាយការណ៍។ អ្នកមាន http ទាំងអស់នោះ... ហើយបញ្ហាភាគច្រើនដែលអ្នកបានពិពណ៌នា ដូចដែលខ្ញុំយល់គឺបណ្តាលមកពីដំណោះស្រាយពិសេសនេះ...

YN៖ - តើយើងប្រើ TCP អ្វីខ្លះ?

Z៖ - សំខាន់បាទ។

YN៖ - ទេ។

Z៖ - វាគឺជាមួយនឹង fasthttp ដែលអ្នកមានបញ្ហាជាមួយនឹងការតភ្ជាប់ដែលអ្នកមានបញ្ហា។ ប្រសិនបើអ្នកទើបតែបានប្រើ UDP អ្នកនឹងសន្សំខ្លួនឯងបានមួយរយៈ។ អញ្ចឹង វានឹងមានបញ្ហាជាមួយនឹងសារវែង ឬអ្វីផ្សេងទៀត...

YN៖ - ជាមួយអ្វី?

Z៖ - ជាមួយនឹងសារដ៏វែង ដោយសារវាប្រហែលជាមិនសមនឹង MTU អ្វីផ្សេងទៀត... ប្រហែលជាមានបញ្ហារបស់ពួកគេផ្ទាល់។ សំណួរគឺ៖ ហេតុអ្វីមិន UDP?

YN៖ - ខ្ញុំជឿថាអ្នកនិពន្ធដែលបានបង្កើត TCP/IP គឺឆ្លាតជាងខ្ញុំច្រើន ហើយដឹងច្បាស់ជាងខ្ញុំពីរបៀបធ្វើសៀរៀលកញ្ចប់ព័ត៌មាន (ដើម្បីឱ្យពួកគេទៅ) ក្នុងពេលដំណាលគ្នាកែតម្រូវបង្អួចបញ្ជូន កុំផ្ទុកលើសបណ្តាញ ផ្តល់មតិកែលម្អលើអ្វី។ មិនបានអាន មិនគិតពីផ្នែកម្ខាងទៀត... បញ្ហាទាំងអស់នេះ តាមគំនិតខ្ញុំនឹងមាននៅក្នុង UDP ទាល់តែខ្ញុំត្រូវសរសេរកូដច្រើនជាងដែលខ្ញុំបានសរសេររួចហើយ ដើម្បីអនុវត្តរឿងដដែលដោយខ្លួនឯង ហើយទំនងជាបំផុត យ៉ាងលំបាក។ ខ្ញុំមិនសូវចូលចិត្តសរសេរអក្សរ C ទេ ទុកឲ្យនៅទីនោះ...

Z៖ - ស្រួលៗ! ផ្ញើយល់ព្រម ហើយកុំរង់ចាំអ្វីទាំងអស់ - វាអសមកាលទាំងស្រុង។ ការជូនដំណឹងត្រឡប់មកវិញថាអ្វីគ្រប់យ៉ាងគឺល្អ - មានន័យថាវាបានមកដល់។ បើមិនមកនោះមានន័យថាអាក្រក់។

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

Z៖ - ខ្ញុំនឹងមិនខ្ជះខ្ជាយពេលវេលាទេ។ នេះចាំបាច់ត្រូវពិភាក្សាបន្ថែមទៀត។ សូមអរគុណ។

ដឹកនាំ៖ - អ្នកណាមានសំណួរ - ដៃទៅមេឃ!

Z៖ - សួស្តី ខ្ញុំឈ្មោះសាសា។ នៅកន្លែងណាមួយនៅក្នុងពាក់កណ្តាលនៃរបាយការណ៍ អារម្មណ៍មួយបានលេចឡើងថា បន្ថែមពីលើ TCP វាអាចប្រើដំណោះស្រាយដែលត្រៀមរួចជាស្រេច - ប្រភេទ Kafka មួយចំនួន។

YN៖ - មែនហើយ ... ខ្ញុំបានប្រាប់អ្នកថាខ្ញុំមិនចង់ប្រើម៉ាស៊ីនមេកម្រិតមធ្យមទេព្រោះ ... នៅក្នុង Kafka វាប្រែថាយើងមានម៉ាស៊ីនមួយម៉ឺន។ តាមពិតយើងមានច្រើនទៀត - ម៉ាស៊ីនរាប់ម៉ឺននាក់។ វាក៏អាចធ្វើឱ្យឈឺចាប់ផងដែរក្នុងការធ្វើជាមួយ Kafka ដោយគ្មានប្រូកស៊ី។ លើសពីនេះទៀត សំខាន់បំផុត វានៅតែផ្តល់នូវ "ភាពយឺតយ៉ាវ" វាផ្តល់ឱ្យម៉ាស៊ីនបន្ថែមដែលអ្នកត្រូវមាន។ ប៉ុន្តែខ្ញុំមិនចង់មានពួកគេទេ - ខ្ញុំចង់ ...

Z៖ "ប៉ុន្តែនៅទីបំផុត វាបានក្លាយទៅជាបែបនេះយ៉ាងណាក៏ដោយ"។

YN៖ - អត់មានម្ចាស់ផ្ទះទេ! ទាំងអស់នេះដំណើរការលើម៉ាស៊ីន Clickhouse ។

Z៖ - មែនហើយ "Kittenhouse" ដែលជាកន្លែងបញ្ច្រាស - តើគាត់រស់នៅឯណា?

YN៖ - នៅលើម៉ាស៊ីន Clickhouse វាមិនសរសេរអ្វីទៅឌីសទេ។

Z៖ - ចូរយើងសន្មត់។

ដឹកនាំ៖ - តើអ្នកពេញចិត្តទេ? តើយើងអាចផ្តល់ប្រាក់ខែអោយអ្នកបានទេ?

Z៖ - បាទអ្នកអាចធ្វើបាន។ តាមការពិតមានឈើច្រត់ជាច្រើនដើម្បីទទួលបានរឿងដូចគ្នា ហើយឥឡូវនេះ - ចម្លើយពីមុនលើប្រធានបទ TCP ផ្ទុយពីខ្ញុំ ស្ថានភាពនេះ។ វាគ្រាន់តែមានអារម្មណ៍ថាអ្វីៗទាំងអស់អាចធ្វើបាននៅលើជង្គង់របស់ខ្ញុំក្នុងរយៈពេលតិចជាងនេះ។

YN៖ - ហើយហេតុអ្វីបានជាខ្ញុំមិនចង់ប្រើ Kafka ព្រោះមានការត្អូញត្អែរជាច្រើននៅក្នុងការជជែក Clickhouse Telegram ដែលជាឧទាហរណ៍ សារពី Kafka ត្រូវបានបាត់បង់។ មិនមែនមកពី Kafka ខ្លួនវានោះទេប៉ុន្តែនៅក្នុងការរួមបញ្ចូលនៃ Kafka និង Clickhaus; ឬអ្វីមួយមិនបានភ្ជាប់នៅទីនោះ។ និយាយឱ្យចំទៅ វានឹងចាំបាច់ក្នុងការសរសេរអតិថិជនសម្រាប់ Kafka បន្ទាប់មក។ ខ្ញុំគិតថាមិនអាចមានដំណោះស្រាយសាមញ្ញ ឬអាចទុកចិត្តបានជាងនេះទេ។

Z៖ - ប្រាប់ខ្ញុំចុះ ហេតុអ្វីបានជាអ្នកមិនសាកល្បងជួរ ឬឡានក្រុងធម្មតាខ្លះ? ចាប់តាំងពីអ្នកនិយាយថាជាមួយនឹងអសមកាល អ្នកអាចផ្ញើកំណត់ហេតុដោយខ្លួនឯងតាមជួរ ហើយទទួលការឆ្លើយតបដោយអសមកាលតាមជួរ?

YN៖ - សូមណែនាំថាតើជួរណាដែលអាចប្រើបាន?

Z៖ - ណាមួយ ទោះបីជាគ្មានការធានាថាពួកគេស្ថិតក្នុងលំដាប់ក៏ដោយ។ ប្រភេទមួយចំនួននៃ Redis, RMQ ...

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

ដឹកនាំ៖ - Yuri អរគុណច្រើន។ ខ្ញុំស្នើឱ្យបញ្ចប់សំណួរ និងចម្លើយនៅទីនេះ ហើយនិយាយថា តើអ្នកណាដែលសួរសំណួរដែលយើងនឹងផ្តល់សៀវភៅទៅ។

YN៖ - ខ្ញុំចង់ផ្តល់សៀវភៅដល់អ្នកដំបូងដែលសួរសំណួរមួយ។

ដឹកនាំ៖ - អស្ចារ្យណាស់! អស្ចារ្យ! អស្ចារ្យ! អរគុណច្រើន!

ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, cloud VPS សម្រាប់អ្នកអភិវឌ្ឍន៍ចាប់ពី $4.99, analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ ការពិតទាំងមូលអំពី VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ចាប់ពី $19 ឬរបៀបចែករំលែកម៉ាស៊ីនមេ? (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។

Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ចាប់ពី $199 នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អានអំពី របៀបបង្កើតក្រុមហ៊ុនហេដ្ឋារចនាសម្ព័ន្ធ ថ្នាក់ជាមួយនឹងការប្រើប្រាស់ម៉ាស៊ីនមេ Dell R730xd E5-2650 v4 ដែលមានតម្លៃ 9000 អឺរ៉ូសម្រាប់មួយកាក់?

ប្រភព: www.habr.com

HighLoad++, Yuri Nasretdinov (VKontakte)៖ របៀបដែល VK បញ្ចូលទិន្នន័យទៅក្នុង ClickHouse ពីម៉ាស៊ីនមេរាប់ម៉ឺន

តើ​ឈើ​មាន​អ្វី​ខ្លះ ហើយ​ហេតុ​អ្វី​បាន​ជា​ប្រមូល​វា?