ទ្រឹស្តី និងការអនុវត្តនៃការប្រើប្រាស់ ClickHouse នៅក្នុងកម្មវិធីពិត។ Alexander Zaitsev (2018)

ទោះបីជាការពិតដែលថាឥឡូវនេះមានទិន្នន័យច្រើនស្ទើរតែគ្រប់ទីកន្លែងក៏ដោយ មូលដ្ឋានទិន្នន័យវិភាគនៅតែកម្រនិងអសកម្ម។ ពួកគេត្រូវបានគេស្គាល់តិចតួច ហើយថែមទាំងអាចប្រើប្រាស់វាបានយ៉ាងមានប្រសិទ្ធភាពទៀតផង។ មនុស្សជាច្រើនបន្ត "បរិភោគដើមត្រសក់" ជាមួយ MySQL ឬ PostgreSQL ដែលត្រូវបានរចនាឡើងសម្រាប់សេណារីយ៉ូផ្សេងទៀត រងទុក្ខជាមួយ NoSQL ឬបង់ប្រាក់លើសសម្រាប់ដំណោះស្រាយពាណិជ្ជកម្ម។ ClickHouse ផ្លាស់ប្តូរច្បាប់នៃហ្គេម និងកាត់បន្ថយកម្រិតចាប់ផ្ដើមសម្រាប់ការចូលទៅក្នុងពិភពនៃ DBMS វិភាគ។

រាយការណ៍ពី BackEnd Conf 2018 ហើយវាត្រូវបានបោះពុម្ពដោយមានការអនុញ្ញាតពីវាគ្មិន។

តើខ្ញុំជានរណា ហើយហេតុអ្វីបានជាខ្ញុំនិយាយអំពី ClickHouse? ខ្ញុំជានាយកអភិវឌ្ឍន៍នៅ LifeStreet ដែលប្រើ ClickHouse ។ ដូចគ្នា​នេះ​ដែរ ខ្ញុំ​ជា​អ្នក​បង្កើត​ក្រុមហ៊ុន Altinity។ វាគឺជាដៃគូ Yandex ដែលផ្សព្វផ្សាយ ClickHouse និងជួយ Yandex ធ្វើឱ្យ ClickHouse កាន់តែជោគជ័យ។ ក៏ត្រៀមខ្លួនដើម្បីចែករំលែកចំណេះដឹងអំពី ClickHouse ។

ហើយខ្ញុំមិនមែនជាប្អូនប្រុសរបស់ Petya Zaitsev ទេ។ ខ្ញុំត្រូវបានគេសួរជាញឹកញាប់អំពីរឿងនេះ។ ទេ យើងមិនមែនជាបងប្អូនទេ។

"មនុស្សគ្រប់គ្នាដឹង" ថា ClickHouse:

• លឿន​ណាស់,
• ពិតជា​ស្រួល​មែន
• ប្រើនៅក្នុង Yandex.

តិច​តួច​គេ​ដឹង​ថា​ក្រុមហ៊ុន​ណា​ខ្លះ និង​របៀប​ប្រើ។

ខ្ញុំនឹងប្រាប់អ្នកពីមូលហេតុ កន្លែងណា និងរបៀបប្រើ ClickHouse លើកលែងតែ Yandex ។

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

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

សំណួរទីមួយគឺ "ហេតុអ្វីបានជាយើងត្រូវការ ClickHouse?" វា​ហាក់​ដូចជា​ជា​សំណួរ​ច្បាស់​ណាស់ ប៉ុន្តែ​មាន​ចម្លើយ​ច្រើន​ជាង​មួយ​ទៅ​វា​។

• ចម្លើយដំបូងគឺសម្រាប់ការអនុវត្ត។ ClickHouse គឺលឿនណាស់។ ការវិភាគលើ ClickHouse ក៏លឿនផងដែរ។ ជារឿយៗវាអាចត្រូវបានប្រើនៅកន្លែងដែលអ្វីផ្សេងទៀតយឺត ឬអាក្រក់ខ្លាំង។
• ចម្លើយទីពីរគឺថ្លៃដើម។ ហើយជាដំបូងនៃការទាំងអស់តម្លៃនៃការធ្វើមាត្រដ្ឋាន។ ឧទាហរណ៍ Vertica គឺជាមូលដ្ឋានទិន្នន័យដ៏អស្ចារ្យ។ វាដំណើរការល្អណាស់ប្រសិនបើអ្នកមិនមានទិន្នន័យច្រើន terabytes ។ ប៉ុន្តែនៅពេលដែលវាមកដល់រាប់រយ terabytes ឬ petabytes តម្លៃនៃអាជ្ញាប័ណ្ណ និងការគាំទ្របានចូលទៅក្នុងចំនួនដ៏ច្រើនគួរសម។ ហើយវាថ្លៃណាស់។ ហើយ ClickHouse គឺឥតគិតថ្លៃ។
• ចម្លើយទីបីគឺថ្លៃដើមប្រតិបត្តិការ។ នេះគឺជាវិធីសាស្រ្តខុសគ្នាបន្តិច។ RedShift គឺជាអាណាឡូកដ៏អស្ចារ្យ។ នៅលើ RedShift អ្នកអាចធ្វើការសម្រេចចិត្តបានយ៉ាងឆាប់រហ័ស។ វានឹងដំណើរការល្អ ប៉ុន្តែក្នុងពេលតែមួយ ជារៀងរាល់ម៉ោង ជារៀងរាល់ថ្ងៃ និងជារៀងរាល់ខែ អ្នកនឹងចំណាយប្រាក់ដល់ Amazon យ៉ាងខ្លាំង ព្រោះនេះគឺជាសេវាកម្មដែលមានតម្លៃថ្លៃខ្លាំង។ Google BigQuery ផងដែរ។ ប្រសិនបើមាននរណាម្នាក់បានប្រើវា នោះគាត់ដឹងថានៅទីនោះអ្នកអាចដំណើរការសំណើជាច្រើន ហើយទទួលបានវិក្កយបត្រសម្រាប់រាប់រយដុល្លារភ្លាមៗ។

ClickHouse មិនមានបញ្ហាទាំងនេះទេ។

តើ ClickHouse ប្រើឥឡូវនេះនៅឯណា? បន្ថែមពីលើ Yandex, ClickHouse ត្រូវបានប្រើនៅក្នុងក្រុមនៃអាជីវកម្ម និងក្រុមហ៊ុនផ្សេងៗគ្នា។

• ដំបូងបង្អស់នេះគឺជាការវិភាគកម្មវិធីគេហទំព័រ ពោលគឺនេះជាករណីប្រើប្រាស់ដែលបានមកពី Yandex ។
• ក្រុមហ៊ុន AdTech ជាច្រើនប្រើ ClickHouse ។
• ក្រុមហ៊ុនជាច្រើនដែលត្រូវការវិភាគកំណត់ហេតុប្រតិបត្តិការពីប្រភពផ្សេងៗគ្នា។
• ក្រុមហ៊ុនជាច្រើនប្រើ ClickHouse ដើម្បីត្រួតពិនិត្យកំណត់ហេតុសុវត្ថិភាព។ ពួកគេបង្ហោះវាទៅ ClickHouse ធ្វើរបាយការណ៍ និងទទួលបានលទ្ធផលដែលពួកគេត្រូវការ។
• ក្រុមហ៊ុនកំពុងចាប់ផ្តើមប្រើប្រាស់វាក្នុងការវិភាគហិរញ្ញវត្ថុ ពោលគឺបណ្តើរៗ អាជីវកម្មធំៗក៏កំពុងខិតជិត ClickHouse ផងដែរ។
• ពពក។ ប្រសិនបើនរណាម្នាក់តាមដាន ClickHouse នោះពួកគេប្រហែលជាធ្លាប់បានលឺឈ្មោះរបស់ក្រុមហ៊ុននេះ។ នេះគឺជាអ្នករួមចំណែកដ៏សំខាន់មួយពីសហគមន៍។ ហើយពួកគេមានការដំឡើង ClickHouse ដ៏ធ្ងន់ធ្ងរ។ ឧទាហរណ៍ពួកគេបានបង្កើតម៉ាស៊ីន Kafka សម្រាប់ ClickHouse ។
• ក្រុមហ៊ុនទូរគមនាគមន៍បានចាប់ផ្តើមប្រើប្រាស់។ ក្រុមហ៊ុនជាច្រើនប្រើ ClickHouse ជាភ័ស្តុតាងលើគំនិត ឬកំពុងផលិតរួចហើយ។
• ក្រុមហ៊ុនមួយប្រើប្រាស់ ClickHouse ដើម្បីត្រួតពិនិត្យដំណើរការផលិតកម្ម។ ពួកគេសាកល្បង microcircuits, សរសេរចេញពី bunch នៃប៉ារ៉ាម៉ែត្រ, មានប្រហែល 2 លក្ខណៈ។ ហើយបន្ទាប់មកពួកគេវិភាគថាតើហ្គេមល្អឬអាក្រក់។
• ការវិភាគ Blockchain ។ មានក្រុមហ៊ុនរុស្ស៊ីដូចជា Bloxy.info ។ នេះគឺជាការវិភាគនៃបណ្តាញ ethereum ។ ពួកគេក៏បានធ្វើវានៅលើ ClickHouse ផងដែរ។

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

ហើយប្រសិនបើអ្នកក្រឡេកមើលកំណត់ត្រានោះ៖

• Yandex: ម៉ាស៊ីនមេ 500+ ពួកគេរក្សាទុកកំណត់ត្រា 25 ពាន់លានក្នុងមួយថ្ងៃនៅទីនោះ។
• LifeStreet៖ 60 servers ប្រមាណ 75 billion records ក្នុងមួយថ្ងៃ។ មានម៉ាស៊ីនមេតិចជាង កំណត់ត្រាច្រើនជាងនៅក្នុង Yandex ។
• CloudFlare: ម៉ាស៊ីនមេចំនួន 36 ពួកគេរក្សាទុកកំណត់ត្រា 200 ពាន់លានក្នុងមួយថ្ងៃ។ ពួកគេមានម៉ាស៊ីនមេតិចជាងមុន និងរក្សាទុកទិន្នន័យកាន់តែច្រើន។
• Bloomberg: 102 servers ប្រហែលមួយពាន់ពាន់លានធាតុក្នុងមួយថ្ងៃ។ អ្នកកាន់កំណត់ត្រា។

តាមភូមិសាស្ត្រនេះក៏មានច្រើនដែរ។ ផែនទីនេះនៅទីនេះបង្ហាញពីផែនទីកំដៅនៃកន្លែងដែល ClickHouse កំពុងត្រូវបានប្រើប្រាស់នៅក្នុងពិភពលោក។ រុស្ស៊ី ចិន អាមេរិក លេចធ្លោនៅទីនេះ។ មានប្រទេសនៅអឺរ៉ុបតិចតួច។ ហើយមាន 4 ចង្កោម។

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

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

ទាំងនេះគឺជាឧទាហរណ៍នៃការប្រើប្រាស់ ClickHouse ពិតប្រាកដនៅក្នុងក្រុមហ៊ុនមួយចំនួន។

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

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

ក្រុមហ៊ុនបានមកដល់ផ្លូវវែងឆ្ងាយ និងមានបន្លា។ ហើយខ្ញុំបាននិយាយអំពីវានៅលើ HighLoad ។ ដំបូង LifeStreet បានផ្លាស់ប្តូរពី MySQL (ជាមួយនឹងការឈប់ខ្លីនៅ Oracle) ទៅ Vertica ។ ហើយអ្នកអាចស្វែងរករឿងរ៉ាវអំពីវា។

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

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

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

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

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

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

ហើយភ្លាមៗនៅក្នុងរដូវក្តៅនៃឆ្នាំ 2016 យើងបានចាប់ផ្តើមរកមើលអ្វីដែល ClickHouse ។ ហើយវាបានប្រែក្លាយថាពេលខ្លះវាអាចលឿនជាង Vertica ។ យើងបានសាកល្បងសេណារីយ៉ូផ្សេងៗគ្នាតាមសំណើផ្សេងៗគ្នា។ ហើយប្រសិនបើសំណួរប្រើតែតារាងមួយ នោះគឺដោយគ្មានការចូលរួមណាមួយ (ចូលរួម) នោះ ClickHouse គឺលឿនជាង Vertica ពីរដង។

ខ្ញុំមិនខ្ជិលពេកទេ ហើយមើលការធ្វើតេស្ត Yandex នៅថ្ងៃមុន។ វាដូចគ្នានៅទីនោះ៖ ClickHouse គឺលឿនជាង Vertica ពីរដង ដូច្នេះពួកគេតែងតែនិយាយអំពីវា។

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

ហើយដោយបានទទួលលទ្ធផលតេស្ត ហើយសម្លឹងមើលវាពីមុំផ្សេងៗគ្នា LifeStreet បានទៅ ClickHouse ។

នេះជាឆ្នាំទី 16 ខ្ញុំសូមរំលឹកអ្នក។ វា​ដូចជា​ការ​លេងសើច​របស់​សត្វ​កណ្ដុរ​ដែល​ស្រែក​ទ្រហោយំ ប៉ុន្តែ​បន្ត​ស៊ី​ដើម​ត្រសក់។ ហើយនេះត្រូវបានពណ៌នាយ៉ាងលម្អិត មានវីដេអូអំពីរឿងនេះ។ល។

ដូច្នេះខ្ញុំនឹងមិននិយាយអំពីវាលម្អិតទេ ខ្ញុំនឹងនិយាយតែអំពីលទ្ធផល និងរឿងគួរឱ្យចាប់អារម្មណ៍មួយចំនួនដែលខ្ញុំមិនបាននិយាយនៅពេលនោះ។

លទ្ធផលគឺ៖

• ការធ្វើចំណាកស្រុកដោយជោគជ័យនិងច្រើនជាងមួយឆ្នាំប្រព័ន្ធដំណើរការរួចហើយនៅក្នុងផលិតកម្ម។
• ផលិតភាពនិងភាពបត់បែនបានកើនឡើង។ ក្នុងចំណោមកំណត់ត្រាចំនួន 10 ពាន់លានដែលយើងអាចមានលទ្ធភាពរក្សាទុកក្នុងមួយថ្ងៃហើយបន្ទាប់មកក្នុងរយៈពេលខ្លី LifeStreet ឥឡូវនេះរក្សាទុក 75 ពាន់លានកំណត់ត្រាក្នុងមួយថ្ងៃ ហើយអាចធ្វើវាបានរយៈពេល 3 ខែ ឬច្រើនជាងនេះ។ ប្រសិនបើអ្នករាប់ដល់កំពូល នោះវាមានរហូតដល់មួយលានព្រឹត្តិការណ៍ក្នុងមួយវិនាទី។ សំណួរ SQL ច្រើនជាងមួយលានក្នុងមួយថ្ងៃបានមកដល់ប្រព័ន្ធនេះ ដែលភាគច្រើនមកពីមនុស្សយន្តផ្សេងៗគ្នា។
• ទោះបីជាការពិតដែលថាម៉ាស៊ីនមេកាន់តែច្រើនត្រូវបានប្រើសម្រាប់ ClickHouse ជាង Vertica ពួកគេក៏បានរក្សាទុកនៅលើផ្នែករឹងផងដែរពីព្រោះថាស SAS ថ្លៃជាងត្រូវបានប្រើនៅក្នុង Vertica ។ ClickHouse បានប្រើ SATA ។ ហើយហេតុអ្វី? ដោយសារតែនៅក្នុង Vertica បញ្ចូលគឺសមកាលកម្ម។ ហើយការធ្វើសមកាលកម្មទាមទារថាថាសមិនថយចុះខ្លាំងពេកទេ ហើយបណ្តាញមិនថយចុះខ្លាំងពេក នោះគឺជាប្រតិបត្តិការថ្លៃជាង។ ហើយនៅក្នុង ClickHouse បញ្ចូលគឺអសមកាល។ ជាងនេះទៅទៀត អ្នកតែងតែអាចសរសេរអ្វីៗគ្រប់យ៉ាងនៅក្នុងមូលដ្ឋាន ដោយមិនមានតម្លៃបន្ថែមសម្រាប់វា ដូច្នេះទិន្នន័យអាចត្រូវបានបញ្ចូលទៅក្នុង ClickHouse លឿនជាងចូលទៅក្នុង Vertika សូម្បីតែនៅលើដ្រាយយឺតក៏ដោយ។ ហើយការអានក៏ដូចគ្នាដែរ។ ការអាននៅលើ SATA ប្រសិនបើពួកគេស្ថិតនៅក្នុង RAID នោះវាលឿនគ្រប់គ្រាន់ហើយ។
• មិនកំណត់ដោយអាជ្ញាបណ្ណ ពោលគឺទិន្នន័យ 3 petabytes ក្នុង 60 servers (20 servers គឺមួយ replica) និង 6 trillion records នៅក្នុងការពិត និងការប្រមូលផ្តុំ។ គ្មានអ្វីដូចនេះអាចទិញបាននៅ Vertica ទេ។

ឥឡូវ​នេះ ខ្ញុំ​ងាក​ទៅ​រក​រឿង​ជាក់ស្តែង​ក្នុង​ឧទាហរណ៍​នេះ។

• ទីមួយគឺជាគ្រោងការណ៍ដែលមានប្រសិទ្ធភាព។ ភាគច្រើនអាស្រ័យលើគ្រោងការណ៍។
• ទីពីរគឺការបង្កើត SQL ប្រកបដោយប្រសិទ្ធភាព។

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

ហើយជារឿយៗ នេះត្រូវបានគេយកគំរូតាមទម្រង់ផ្កាយ - គ្រោងការណ៍ នៅពេលដែលមានការពិតកណ្តាល និងលក្ខណៈនៃការពិតនេះនៅតាមបណ្តោយចំហៀង តាមបណ្តោយកាំរស្មី។

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

ប៉ុន្តែវាមិនដំណើរការល្អនៅក្នុង ClickHouse ទេ។ មានហេតុផលពីរយ៉ាង៖

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

ហើយមានផ្លូវចេញពីវានៅក្នុង ClickHouse ។ សូម្បីតែពីរ៖

• ទីមួយគឺការប្រើប្រាស់វចនានុក្រម។ វចនានុក្រម​ខាង​ក្រៅ​គឺ​ជា​អ្វី​ដែល​ជួយ 99% ​ដោះ​ស្រាយ​បញ្ហា​ជាមួយ​នឹង star-schema ជាមួយ​នឹង​ការ​អាប់ដេត​ជាដើម។
• ទីពីរគឺការប្រើប្រាស់អារេ។ អារេក៏ជួយកម្ចាត់ការភ្ជាប់និងបញ្ហាជាមួយនឹងការធ្វើឱ្យធម្មតា។

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

• អ្នកក៏មិនត្រូវការការចូលរួមដែរ។
• នេះ​ជា​តំណាង​ពី 1 ទៅ​ច្រើន។
• ហើយនៅក្នុងគំនិតរបស់ខ្ញុំ អារេត្រូវបានបង្កើតឡើងសម្រាប់ geeks ។ ទាំងនេះគឺជាមុខងារ lambda ហើយដូច្នេះនៅលើ។

នេះមិនមែនសម្រាប់ពាក្យក្រហមទេ។ នេះគឺជាមុខងារដ៏មានឥទ្ធិពលដែលអនុញ្ញាតឱ្យអ្នកធ្វើកិច្ចការជាច្រើនតាមរបៀបសាមញ្ញ និងឆើតឆាយបំផុត។

ឧទាហរណ៍ធម្មតាដែលជួយដោះស្រាយអារេ។ ឧទាហរណ៍ទាំងនេះគឺសាមញ្ញ និងច្បាស់លាស់គ្រប់គ្រាន់៖

• ស្វែងរកតាមស្លាក។ ប្រសិនបើអ្នកមាន hashtags នៅទីនោះ ហើយចង់ស្វែងរកប្រកាសមួយចំនួនដោយ hashtag ។
• ស្វែងរកតាមគូតម្លៃគន្លឹះ។ វាក៏មានគុណលក្ខណៈមួយចំនួនដែលមានតម្លៃផងដែរ។
• ការរក្សាទុកបញ្ជីកូនសោដែលអ្នកត្រូវការបកប្រែទៅជាអ្វីផ្សេងទៀត។

កិច្ចការទាំងអស់នេះអាចត្រូវបានដោះស្រាយដោយគ្មានអារេ។ ស្លាកអាចត្រូវបានដាក់ក្នុងបន្ទាត់មួយចំនួន ហើយជ្រើសរើសដោយកន្សោមធម្មតា ឬក្នុងតារាងដាច់ដោយឡែក ប៉ុន្តែបន្ទាប់មកអ្នកត្រូវធ្វើ Joins ។

ហើយនៅក្នុង ClickHouse អ្នកមិនចាំបាច់ធ្វើអ្វីនោះទេ វាគ្រប់គ្រាន់ក្នុងការពណ៌នាអារេខ្សែអក្សរសម្រាប់ hashtags ឬបង្កើតរចនាសម្ព័ន្ធដាក់សម្រាប់ប្រព័ន្ធតម្លៃគន្លឹះ។

រចនាសម្ព័ន្ធ Nested ប្រហែលជាមិនមែនជាឈ្មោះល្អបំផុតទេ។ ទាំងនេះគឺជាអារេពីរដែលមានផ្នែកទូទៅនៅក្នុងឈ្មោះ និងលក្ខណៈពាក់ព័ន្ធមួយចំនួន។

ហើយវាងាយស្រួលណាស់ក្នុងការស្វែងរកតាមស្លាក។ មានមុខងារ hasដែលពិនិត្យមើលថាអារេមានធាតុ។ អ្នករាល់គ្នាបានរកឃើញធាតុទាំងអស់ដែលទាក់ទងនឹងសន្និសីទរបស់យើង។

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

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

ឧទាហរណ៍មួយទៀត។ អ្នកមានអារេដែលអ្នករក្សាទុកលេខសម្គាល់។ ហើយអ្នកអាចបកប្រែវាទៅជាឈ្មោះ។ មុខងារ arrayMap. នេះគឺជាមុខងារ lambda ធម្មតា។ អ្នកឆ្លងកាត់កន្សោម lambda នៅទីនោះ។ ហើយនាងទាញតម្លៃនៃឈ្មោះសម្រាប់លេខសម្គាល់នីមួយៗចេញពីវចនានុក្រម។

ការស្វែងរកអាចត្រូវបានធ្វើតាមរបៀបដូចគ្នា។ អនុគមន៍​ព្យាករណ៍​ត្រូវ​បាន​ហុច​ដែល​ពិនិត្យ​មើល​ថា​តើ​ធាតុ​ណា​ដែល​ត្រូវ​គ្នា​។

របស់ទាំងនេះជួយសម្រួលសៀគ្វី និងដោះស្រាយបញ្ហាជាច្រើន។

ប៉ុន្តែ​បញ្ហា​បន្ទាប់​ដែល​យើង​កំពុង​ប្រឈម​មុខ ហើយ​ដែល​ខ្ញុំ​ចង់​និយាយ​គឺ​សំណួរ​ដែល​មាន​ប្រសិទ្ធភាព។

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

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

នេះគឺជាឧទាហរណ៍មួយ។ នៅផ្នែកខាងឆ្វេងគឺជាសំណួរដែលបង្ហាញពីប្រទេសកំពូលទាំង 5 ។ ហើយវាត្រូវចំណាយពេល 2,5 វិនាទី តាមគំនិតរបស់ខ្ញុំ។ ហើយនៅផ្នែកខាងស្តាំ សំណួរដូចគ្នា ប៉ុន្តែត្រូវបានសរសេរឡើងវិញបន្តិច។ ជំនួសឱ្យការដាក់ជាក្រុមតាមខ្សែអក្សរ យើងចាប់ផ្តើមដាក់ជាក្រុមតាមគន្លឹះ (int)។ ហើយវាលឿនជាង។ ហើយបន្ទាប់មកយើងបានភ្ជាប់វចនានុក្រមទៅនឹងលទ្ធផល។ ជំនួសឱ្យ 2,5 វិនាទី សំណើត្រូវចំណាយពេល 1,5 វិនាទី។ នេះជាការល្អ។

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

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

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

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

ចូរបន្តទៅឧទាហរណ៍បន្ទាប់។ ក្រុមហ៊ុន X មកពីសហរដ្ឋអាមេរិក។ តើ​នាង​កំពុង​ធ្វើអ្វី?

មានកិច្ចការមួយ៖

• តំណភ្ជាប់ក្រៅបណ្តាញនៃប្រតិបត្តិការផ្សាយពាណិជ្ជកម្ម។
• ការបង្កើតគំរូនៃការចងផ្សេងៗគ្នា។

តើសេណារីយ៉ូជាអ្វី?

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

សំណួរសមហេតុផល៖ "តើអ្នកណាគួរបង់ប្រាក់សម្រាប់ការផ្សាយពាណិជ្ជកម្ម បើចាំបាច់?" និង "តើការផ្សាយពាណិជ្ជកម្មអ្វីមានឥទ្ធិពលលើគាត់ ប្រសិនបើមាន?" ។ នោះ​គឺ​ហេតុ​អ្វី​បាន​ជា​គាត់​ទិញ ហើយ​ធ្វើ​ម៉េច​ឲ្យ​មនុស្ស​ដូច​មនុស្ស​នេះ​ទិញ​ដែរ?

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

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

មានគំរូចងជាច្រើន។

ការពេញនិយមបំផុតគឺ៖

• អន្តរកម្មចុងក្រោយ ដែលអន្តរកម្មគឺជាការចុច ឬចំណាប់អារម្មណ៍។
• អន្តរកម្មដំបូង ពោលគឺជារឿងដំបូងដែលនាំមនុស្សម្នាក់ទៅកាន់គេហទំព័រ។
• ការរួមបញ្ចូលគ្នាលីនេអ៊ែរ - ទាំងអស់ស្មើគ្នា។
• ការកាត់បន្ថយ។
• ល​ល។

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

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

ហើយវាដំណើរការបានយ៉ាងល្អ ដរាបណាការចងគឺដល់ការចុចចុងក្រោយ។ ព្រោះថាមានអ្នកចុច 10 លានដងក្នុងមួយថ្ងៃ 300 លានដងក្នុងមួយខែ បើយើងកំណត់ Window មួយខែ។ ហើយចាប់តាំងពីនៅក្នុង Cassandra វាត្រូវតែមាននៅក្នុងអង្គចងចាំទាំងអស់ ដើម្បីដំណើរការបានលឿន ដោយសារតែ Runtime ត្រូវការឆ្លើយតបយ៉ាងរហ័ស វាត្រូវចំណាយពេលប្រហែល 10-15 servers ។

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

ហើយយើងបានទៅ ClickHouse ។ និងរបៀបធ្វើវានៅលើ ClickHouse? នៅ glance ដំបូង, វាហាក់ដូចជាថានេះគឺជាសំណុំនៃការប្រឆាំងនឹងលំនាំមួយ។

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

នោះគឺជាសំណុំនៃ antipatterns ។

ប៉ុន្តែទោះជាយ៉ាងណា វាបានប្រែក្លាយចេញជាប្រព័ន្ធដែលដំណើរការបានល្អ។

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

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

ប្រសិនបើអ្នកក្រឡេកមើលខាងក្នុង ClickHouse នោះមានតែតុសំខាន់ៗចំនួន 3 ដែលបម្រើទាំងអស់នេះ។

តារាងទីមួយដែលកំណត់ហេតុត្រូវបានផ្ទុកឡើង ហើយកំណត់ហេតុត្រូវបានផ្ទុកឡើងស្ទើរតែគ្មានដំណើរការ។

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

នេះគឺជាអត្ថបទដែលសរសេរក្នុង SQL ។ ខ្ញុំចង់ផ្តល់យោបល់លើចំណុចសំខាន់ៗមួយចំនួននៅក្នុងវា។

រឿងសំខាន់ដំបូងគឺសមត្ថភាពក្នុងការទាញជួរឈរនិងវាលចេញពី json នៅក្នុង ClickHouse ។ នោះគឺ ClickHouse មានវិធីសាស្រ្តមួយចំនួនសម្រាប់ធ្វើការជាមួយ json ។ ពួកវាមានលក្ខណៈដើមខ្លាំងណាស់។

visitParamExtractInt អនុញ្ញាតឱ្យអ្នកទាញយកគុណលក្ខណៈពី json ពោលគឺដំណើរការបុកដំបូង។ ហើយវិធីនេះអ្នកអាចដកលេខសម្គាល់ប្រតិបត្តិការ ឬចូលមើលលេខសម្គាល់។ ពេលនេះ។

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

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

រឿងសំខាន់ទីពីរគឺ index_granularity ។ ប្រសិនបើអ្នកបានឃើញ MergeTree វាជាធម្មតា 8 តាមលំនាំដើម index_granularity ។ តើ​វា​ជា​អ្វី? នេះគឺជាប៉ារ៉ាម៉ែត្រគម្លាតសន្ទស្សន៍។ នៅក្នុង ClickHouse សន្ទស្សន៍គឺតូច វាមិនដែលធ្វើលិបិក្រមរាល់ធាតុទេ។ វាធ្វើបែបនេះរៀងរាល់ 192. ហើយនេះជាការល្អនៅពេលដែលទិន្នន័យជាច្រើនត្រូវបានទាមទារដើម្បីត្រូវបានគណនា ប៉ុន្តែអាក្រក់នៅពេលដែលតិចតួច ដោយសារតែមានលើសធំ។ ហើយប្រសិនបើយើងកាត់បន្ថយសន្ទស្សន៍ granularity នោះយើងកាត់បន្ថយលើស។ វា​មិន​អាច​បន្ថយ​មក​ត្រឹម​មួយ​បាន​ទេ ព្រោះ​ប្រហែល​ជា​មិន​មាន​អង្គ​ចងចាំ​គ្រប់គ្រាន់។ លិបិក្រមត្រូវបានរក្សាទុកក្នុងសតិជានិច្ច។

Snapshot ក៏ប្រើមុខងារ ClickHouse គួរឱ្យចាប់អារម្មណ៍មួយចំនួនផងដែរ។

ទីមួយវាគឺជា AggregatingMergeTree ។ ហើយ AggregatingMergeTree រក្សាទុក argMax ពោលគឺ នេះគឺជាស្ថានភាពនៃប្រតិបត្តិការដែលត្រូវគ្នាទៅនឹងត្រាពេលវេលាចុងក្រោយ។ ប្រតិបត្តិការត្រូវបានបង្កើតគ្រប់ពេលវេលាសម្រាប់អ្នកទស្សនាដែលបានផ្តល់ឱ្យ។ ហើយនៅក្នុងស្ថានភាពចុងក្រោយនៃប្រតិបត្តិការនេះ យើងបានបន្ថែមព្រឹត្តិការណ៍មួយ ហើយយើងមានស្ថានភាពថ្មីមួយ។ វាបានបុក ClickHouse ម្តងទៀត។ ហើយតាមរយៈ argMax នៅក្នុងទិដ្ឋភាពជាក់ស្តែងនេះ យើងតែងតែអាចទទួលបានស្ថានភាពបច្ចុប្បន្ន។

• ការចងគឺ "បំបែក" ពី Runtime ។
• ប្រតិបត្តិការរហូតដល់ 3 ពាន់លានក្នុងមួយខែត្រូវបានរក្សាទុក និងដំណើរការ។ នេះគឺជាលំដាប់នៃទំហំធំជាងនៅ Cassandra ពោលគឺនៅក្នុងប្រព័ន្ធប្រតិបត្តិការធម្មតា។
• ចង្កោមនៃម៉ាស៊ីនមេ ClickHouse 2x5 ។ ម៉ាស៊ីនមេចំនួន 5 និងម៉ាស៊ីនមេនីមួយៗមានការចម្លង។ នេះគឺតិចជាងវានៅក្នុង Cassandra ដើម្បីធ្វើការកំណត់ដោយផ្អែកលើការចុច ហើយនៅទីនេះយើងមានចំណាប់អារម្មណ៍ផ្អែកលើ។ នោះគឺជំនួសឱ្យការបង្កើនចំនួនម៉ាស៊ីនមេ 30 ដង ពួកគេបានគ្រប់គ្រងកាត់បន្ថយពួកគេ។

ហើយឧទាហរណ៍ចុងក្រោយគឺក្រុមហ៊ុនហិរញ្ញវត្ថុ Y ដែលបានវិភាគទំនាក់ទំនងនៃការផ្លាស់ប្តូរតម្លៃភាគហ៊ុន។

ហើយភារកិច្ចគឺ៖

• មានភាគហ៊ុនប្រហែល 5 ។
• សម្រង់រាល់ 100 មិល្លីវិនាទីត្រូវបានគេស្គាល់។
• ទិន្នន័យត្រូវបានប្រមូលក្នុងរយៈពេល 10 ឆ្នាំ។ ជាក់ស្តែង សម្រាប់ក្រុមហ៊ុនមួយចំនួនកាន់តែច្រើន ខ្លះតិចជាង។
• មានជួរសរុបប្រហែល 100 ពាន់លាន។

ហើយវាចាំបាច់ក្នុងការគណនាការជាប់ទាក់ទងនៃការផ្លាស់ប្តូរ។

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

ការវិភាគលើការផ្លាស់ប្តូរទៅវិញទៅមកទាំងនេះ មនុស្សម្នាក់អាចធ្វើការព្យាករណ៍នៅក្នុងទីផ្សារហិរញ្ញវត្ថុ។

ប៉ុន្តែភារកិច្ចគឺពិបាកណាស់។ តើកំពុងធ្វើអ្វីសម្រាប់រឿងនេះ? យើងមានកំណត់ត្រា 100 ពាន់លានដែលមាន៖ ពេលវេលា ភាគហ៊ុន និងតម្លៃ។ យើងត្រូវគណនា 100 ពាន់លានដងដំបូងនៃការរត់ភាពខុសគ្នាពីក្បួនដោះស្រាយតម្លៃ។ RunningDifference គឺជាមុខងារមួយនៅក្នុង ClickHouse ដែលគណនាភាពខុសគ្នារវាងខ្សែអក្សរពីរ។

ហើយបន្ទាប់ពីនោះ អ្នកត្រូវគណនាការជាប់ទាក់ទងគ្នា ហើយការជាប់ទាក់ទងគ្នាត្រូវតែគណនាសម្រាប់គូនីមួយៗ។ សម្រាប់ 5 shares គូគឺ 000 លាន។ ហើយនេះគឺច្រើន ពោលគឺ 12,5 ដង វាចាំបាច់ក្នុងការគណនាមុខងារទំនាក់ទំនងបែបនេះ។

ហើយប្រសិនបើនរណាម្នាក់ភ្លេចនោះ ͞x និង ͞y គឺជាអ្នកត្រួតពិនិត្យ។ ការរំពឹងទុកគំរូ។ នោះគឺវាចាំបាច់មិនត្រឹមតែដើម្បីគណនាឫស និងផលបូកប៉ុណ្ណោះទេ ប៉ុន្តែវាក៏មានផលបូកមួយបន្ថែមទៀតនៅក្នុងផលបូកទាំងនេះផងដែរ។ ការគណនាជាច្រើនត្រូវធ្វើ 12,5 លានដង ហើយថែមទាំងដាក់ជាក្រុមតាមម៉ោង។ យើងក៏មានម៉ោងច្រើនដែរ។ ហើយអ្នកត្រូវធ្វើវាក្នុងរយៈពេល 60 វិនាទី។ វាជារឿងកំប្លែងមួយ។

វាចាំបាច់ណាស់ក្នុងការមានពេលវេលាយ៉ាងហោចណាស់ដោយហេតុថាអ្វីៗទាំងអស់នេះដំណើរការយឺតណាស់មុនពេល ClickHouse មកដល់។

ពួកគេបានព្យាយាមគណនាវានៅលើ Hadoop នៅលើ Spark នៅលើ Greenplum ។ ហើយទាំងអស់នេះយឺត ឬថ្លៃណាស់។ នោះ​គឺ​វា​អាច​ធ្វើ​បាន​ក្នុង​ការ​គណនា​បែប​ណា​មួយ ប៉ុន្តែ​បន្ទាប់​មក​វា​ថ្លៃ។

ហើយបន្ទាប់មក ClickHouse បានមក ហើយអ្វីៗបានប្រសើរឡើង។

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

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

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

បន្ទាប់ពីនោះវាអាចត្រូវបានចម្លង។ អក្សរ "r" មានន័យថាយើងចម្លងទិន្នន័យនេះ។ នោះគឺយើងមានទិន្នន័យដូចគ្នានៅលើម៉ាស៊ីនមេទាំងបី - ទាំងនេះគឺជាអារេ។

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

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

នៅលើភស្តុតាងនៃគំនិត កិច្ចការគឺជាកិច្ចការរង ពោលគឺ ទិន្នន័យតិចជាងត្រូវបានយក។ ហើយមានតែម៉ាស៊ីនមេបីប៉ុណ្ណោះ។

ដំណាក់កាលពីរដំបូង៖ ការគណនា Log_return និងការរុំក្នុងអារេចំណាយពេលប្រហែលមួយម៉ោង។

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

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

• គ្រោងការណ៍ត្រឹមត្រូវគឺពាក់កណ្តាលជោគជ័យ។ ហើយគ្រោងការណ៍ត្រឹមត្រូវគឺការប្រើប្រាស់បច្ចេកវិទ្យា ClickHouse ចាំបាច់ទាំងអស់។
• Summing/AggregatingMergeTrees គឺជាបច្ចេកវិទ្យាដែលអនុញ្ញាតឱ្យអ្នកប្រមូលផ្តុំ ឬពិចារណារូបថតរដ្ឋជាករណីពិសេសមួយ។ ហើយ​វា​ជួយ​សម្រួល​ដល់​រឿង​ជា​ច្រើន។
• Materialized Views អនុញ្ញាតឱ្យអ្នករំលងដែនកំណត់សន្ទស្សន៍មួយ។ ប្រហែលជាខ្ញុំមិនបាននិយាយវាច្បាស់ទេ ប៉ុន្តែនៅពេលដែលយើងផ្ទុកកំណត់ហេតុ កំណត់ហេតុឆៅស្ថិតនៅក្នុងតារាងដែលមានលិបិក្រមតែមួយ ហើយកំណត់ហេតុគុណលក្ខណៈស្ថិតនៅក្នុងតារាង ពោលគឺទិន្នន័យដូចគ្នា មានតែត្រងប៉ុណ្ណោះ ប៉ុន្តែលិបិក្រមគឺទាំងស្រុង។ ផ្សេងទៀត។ វាហាក់ដូចជាទិន្នន័យដូចគ្នា ប៉ុន្តែការតម្រៀបខុសគ្នា។ ហើយ​ទិដ្ឋភាព​សម្ភារៈ​អនុញ្ញាត​ឱ្យ​អ្នក​បើ​អ្នក​ត្រូវ​ការ​វា​ដើម្បី​រំលង​ការ​កំណត់ ClickHouse បែប​នេះ។
• កាត់បន្ថយកម្រិតលម្អិតនៃលិបិក្រមសម្រាប់សំណួរចំណុច។
• ហើយចែកចាយទិន្នន័យដោយឆ្លាតវៃ ព្យាយាមធ្វើមូលដ្ឋានីយកម្មទិន្នន័យនៅក្នុងម៉ាស៊ីនមេតាមដែលអាចធ្វើបាន។ ហើយព្យាយាមធានាថាសំណើក៏ប្រើការធ្វើមូលដ្ឋានីយកម្មនៅកន្លែងដែលអាចធ្វើទៅបានតាមដែលអាចធ្វើទៅបាន។

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

-អរគុណសម្រាប់របាយការណ៍! គួរ​ឱ្យ​ចាប់អារម្មណ៍​ណាស់! តើមានការប្រៀបធៀបជាមួយ Apache Phoenix ទេ?

ទេ ខ្ញុំមិនដែលឮអ្នកណាប្រៀបធៀបទេ។ យើង និង Yandex ព្យាយាមតាមដានរាល់ការប្រៀបធៀប ClickHouse ជាមួយនឹងមូលដ្ឋានទិន្នន័យផ្សេងៗគ្នា។ ដោយសារតែប្រសិនបើភ្លាមៗអ្វីមួយប្រែទៅជាលឿនជាង ClickHouse នោះ Lesha Milovidov មិនអាចដេកនៅពេលយប់បានទេហើយចាប់ផ្តើមបង្កើនល្បឿនវាយ៉ាងឆាប់រហ័ស។ ខ្ញុំ​មិន​បាន​ឮ​ពី​ការ​ប្រៀប​ធៀប​បែប​នេះ​ទេ។

• (Aleksey Milovidov) Apache Phoenix គឺជាម៉ាស៊ីន SQL ដែលដំណើរការដោយ Hbase ។ Hbase ជាចម្បងសម្រាប់សេណារីយ៉ូការងារតម្លៃគន្លឹះ។ នៅទីនោះ ក្នុងជួរនីមួយៗ អាចមានចំនួនជួរឈរដែលមានឈ្មោះតាមអំពើចិត្ត។ នេះអាចត្រូវបាននិយាយអំពីប្រព័ន្ធដូចជា Hbase, Cassandra ។ ហើយវាជាសំណួរវិភាគយ៉ាងជាក់លាក់ដែលនឹងមិនដំណើរការជាធម្មតាសម្រាប់ពួកគេ។ ឬអ្នកប្រហែលជាគិតថាពួកវាដំណើរការល្អប្រសិនបើអ្នកមិនមានបទពិសោធន៍ជាមួយ ClickHouse ។

• ស្ទ្រីម

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

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

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

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

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

បាទ​បាទ។

យល់ព្រម អរគុណច្រើន

វាស្ថិតនៅលើចង្កោមម៉ាស៊ីនមេ 3 ។

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

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

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

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

ស្ទ្រីម។

ប្រភព: www.habr.com