HighLoad++, Andrey Gushchin (Zabbix)៖ ដំណើរការខ្ពស់ និងការបែងចែកដើម

យើងនឹងពិនិត្យមើលពីរបៀបដែល Zabbix ធ្វើការជាមួយមូលដ្ឋានទិន្នន័យ TimescaleDB ជាផ្នែកខាងក្រោយ។ យើងនឹងបង្ហាញអ្នកពីរបៀបចាប់ផ្តើមពីដំបូង និងរបៀបផ្ទេរពី PostgreSQL ។ យើង​ក៏​នឹង​ផ្តល់​ជូន​នូវ​ការ​ធ្វើ​តេស្ត​ប្រៀបធៀប​នៃ​ការ​កំណត់​រចនាសម្ព័ន្ធ​ទាំងពីរ។

HighLoad++ ស៊ីបេរីឆ្នាំ 2019 ។ សាល Tomsk ។ ថ្ងៃទី 24 ខែមិថុនាម៉ោង 16:00 ។ ទាំងនេះ និង បទបង្ហាញ. សន្និសីទ HighLoad++ លើកក្រោយនឹងធ្វើឡើងនៅថ្ងៃទី 6 និង 7 ខែមេសា ឆ្នាំ 2020 នៅ St. ព័ត៌មានលម្អិត និងសំបុត្រ តំណភ្ជាប់.

Andrey Gushchin (តទៅនេះ - AG)៖ - ខ្ញុំជាវិស្វករជំនួយបច្ចេកទេស ZABBIX (ហៅកាត់ថា "Zabbix") ដែលជាគ្រូបណ្តុះបណ្តាល។ ខ្ញុំបានធ្វើការក្នុងផ្នែកជំនួយបច្ចេកទេសជាង 6 ឆ្នាំ ហើយមានបទពិសោធន៍ផ្ទាល់ជាមួយការអនុវត្ត។ ថ្ងៃនេះខ្ញុំនឹងនិយាយអំពីដំណើរការដែល TimescaleDB អាចផ្តល់ឱ្យបានបើប្រៀបធៀបជាមួយ PostgreSQL 10 ធម្មតា។

បញ្ហាប្រឈមផលិតភាពកំពូល៖ ពីការប្រមូលទិន្នន័យ រហូតដល់ការសម្អាតទិន្នន័យ

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

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

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

បញ្ហាប្រឈមនៃការអនុវត្តទីបីគឺការជម្រះប្រវត្តិ ពោលគឺនៅពេលអ្នកទៅដល់ចំណុចដែលអ្នកមិនចាំបាច់រក្សាទុករង្វាស់លម្អិតណាមួយដែលត្រូវបានប្រមូលក្នុងរយៈពេល 5 ឆ្នាំ (សូម្បីតែខែ ឬពីរខែ)។ ថ្នាំងបណ្តាញមួយចំនួនត្រូវបានលុប ឬម៉ាស៊ីនមួយចំនួន រង្វាស់គឺលែងត្រូវការទៀតហើយ ព្រោះវាហួសសម័យហើយ លែងប្រមូលទៀតហើយ។ ទាំងអស់នេះចាំបាច់ត្រូវសម្អាត ដើម្បីកុំឱ្យឃ្លាំងទិន្នន័យរបស់អ្នកធំពេក។ ជាទូទៅ ការជម្រះប្រវត្តិគឺជាការធ្វើតេស្តដ៏ធ្ងន់ធ្ងរបំផុតសម្រាប់ការផ្ទុក - ជារឿយៗវាមានឥទ្ធិពលយ៉ាងខ្លាំងទៅលើដំណើរការ។

តើធ្វើដូចម្តេចដើម្បីដោះស្រាយបញ្ហាឃ្លាំងសម្ងាត់?

ឥឡូវនេះខ្ញុំនឹងនិយាយជាពិសេសអំពី Zabbix ។ នៅក្នុង Zabbix ការហៅទូរសព្ទទីមួយ និងទីពីរត្រូវបានដោះស្រាយដោយប្រើឃ្លាំងសម្ងាត់។

ការប្រមូល និងដំណើរការទិន្នន័យ - យើងប្រើ RAM ដើម្បីរក្សាទុកទិន្នន័យទាំងអស់នេះ។ ឥឡូវនេះទិន្នន័យទាំងនេះនឹងត្រូវបានពិភាក្សាលម្អិតបន្ថែមទៀត។

ផងដែរនៅលើផ្នែកមូលដ្ឋានទិន្នន័យមានឃ្លាំងសម្ងាត់មួយចំនួនសម្រាប់ជម្រើសសំខាន់ៗ - សម្រាប់ក្រាហ្វ និងរបស់ផ្សេងទៀត។

ឃ្លាំងសម្ងាត់នៅផ្នែកម្ខាងនៃម៉ាស៊ីនមេ Zabbix ខ្លួនវាផ្ទាល់៖ យើងមាន ConfigurationCache, ValueCache, HistoryCache, TrendsCache ។ តើ​វា​ជា​អ្វី?

ConfigurationCache គឺជាឃ្លាំងសម្ងាត់ចម្បងដែលយើងរក្សាទុក metrics, hosts, data items, triggers; អ្វីគ្រប់យ៉ាងដែលអ្នកត្រូវការដើម្បីដំណើរការដំណើរការមុន ប្រមូលទិន្នន័យ ពីម៉ាស៊ីនណាដែលត្រូវប្រមូល ជាមួយនឹងប្រេកង់អ្វី។ ទាំងអស់នេះត្រូវបានរក្សាទុកក្នុង ConfigurationCache ដើម្បីកុំឱ្យចូលទៅកាន់មូលដ្ឋានទិន្នន័យ និងបង្កើតសំណួរដែលមិនចាំបាច់។ បន្ទាប់ពីម៉ាស៊ីនមេចាប់ផ្តើម យើងធ្វើបច្ចុប្បន្នភាពឃ្លាំងសម្ងាត់នេះ (បង្កើតវា) និងធ្វើបច្ចុប្បន្នភាពវាជាទៀងទាត់ (អាស្រ័យលើការកំណត់រចនាសម្ព័ន្ធ)។

ឃ្លាំងសម្ងាត់នៅក្នុង Zabbix ។ ការ​ប្រមូល​ទិន្នន័យ

ដ្យាក្រាមនេះមានទំហំធំណាស់៖

អ្នកដែលសំខាន់នៅក្នុងគ្រោងការណ៍គឺអ្នកប្រមូលទាំងនេះ:

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

ការដំណើរការប្រវត្តិឃ្លាំងសម្ងាត់

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

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

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

ការងាររបស់អ្នកធ្វើសមកាលកម្មប្រវត្តិ

ដំណើរការសំខាន់នៅក្នុង Zabbix (ចាប់តាំងពីវាជាស្ថាបត្យកម្ម monolithic) គឺ History syncer ។ នេះគឺជាដំណើរការចម្បងដែលទាក់ទងនឹងដំណើរការអាតូមិកនៃធាតុទិន្នន័យនីមួយៗ ពោលគឺតម្លៃនីមួយៗ៖

• តម្លៃមក (វាយកវាពី HistoryCache);
• ពិនិត្យនៅក្នុងឧបករណ៍ធ្វើសមកាលកម្មការកំណត់រចនាសម្ព័ន្ធ៖ ថាតើមានគន្លឹះសម្រាប់ការគណនាដែរឬទេ - គណនាពួកវា។
  ប្រសិនបើមាន - បង្កើតព្រឹត្តិការណ៍ បង្កើតការកើនឡើង ដើម្បីបង្កើតការដាស់តឿន ប្រសិនបើចាំបាច់យោងទៅតាមការកំណត់។
• កំណត់ត្រាកេះសម្រាប់ដំណើរការជាបន្តបន្ទាប់ ការប្រមូលផ្តុំ; ប្រសិនបើអ្នកបូកសរុបម៉ោងចុងក្រោយ និងបន្តបន្ទាប់ តម្លៃនេះត្រូវបានចងចាំដោយ ValueCache ដើម្បីកុំឱ្យចូលទៅកាន់តារាងប្រវត្តិ។ ដូចនេះ ValueCache ត្រូវបានបំពេញដោយទិន្នន័យចាំបាច់ ដែលចាំបាច់សម្រាប់គណនាគន្លឹះ ធាតុដែលបានគណនា។ល។
• បន្ទាប់មក History syncer សរសេរទិន្នន័យទាំងអស់ទៅមូលដ្ឋានទិន្នន័យ។
• មូលដ្ឋានទិន្នន័យសរសេរពួកវាទៅថាស - នេះគឺជាកន្លែងដែលដំណើរការដំណើរការបញ្ចប់។

មូលដ្ឋានទិន្នន័យ។ ឃ្លាំងសម្ងាត់

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

សម្រាប់ MySQL មាន Innodb_buffer_pool និង bunch នៃឃ្លាំងសម្ងាត់ផ្សេងៗគ្នា ដែលអាចកំណត់រចនាសម្ព័ន្ធបានផងដែរ។
ប៉ុន្តែទាំងនេះគឺជារឿងសំខាន់:

• shared_buffers;
• effective_cache_size;
• shared_pool ។

សម្រាប់មូលដ្ឋានទិន្នន័យទាំងអស់ ខ្ញុំបាននិយាយថាមានឃ្លាំងសម្ងាត់ជាក់លាក់ដែលអនុញ្ញាតឱ្យអ្នករក្សាទុកក្នុង RAM នូវទិន្នន័យដែលជារឿយៗត្រូវការសម្រាប់សំណួរ។ ពួកគេមានបច្ចេកវិទ្យាផ្ទាល់ខ្លួនសម្រាប់រឿងនេះ។

អំពីការអនុវត្តមូលដ្ឋានទិន្នន័យ

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

ដំណោះស្រាយការមើលឃើញដ៏ពេញនិយមមួយផងដែរគឺ Grafana ដែលអ្នកប្រើប្រាស់របស់យើងប្រើ។ អាចចូលដោយផ្ទាល់ទាំងតាមរយៈ Zabbix API និងតាមរយៈមូលដ្ឋានទិន្នន័យ។ វាក៏បង្កើតការប្រកួតប្រជែងជាក់លាក់មួយសម្រាប់ការទទួលបានទិន្នន័យផងដែរ៖ ការកែសម្រួលមូលដ្ឋានទិន្នន័យល្អជាងនេះ គឺចាំបាច់ដើម្បីអនុវត្តតាមការផ្តល់លទ្ធផល និងការធ្វើតេស្តយ៉ាងឆាប់រហ័ស។

ជម្រះប្រវត្តិ។ Zabbix មានមេផ្ទះ

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

ខ្ញុំមិនបាននិយាយអំពី TrendCache ដែលយើងគណនាភ្លាមៗទេ៖ ទិន្នន័យមកដល់ យើងបូកសរុបវារយៈពេលមួយម៉ោង (ភាគច្រើនទាំងនេះគឺជាលេខសម្រាប់ម៉ោងចុងក្រោយ) ចំនួនទឹកប្រាក់គឺជាមធ្យម/អប្បបរមា ហើយយើងកត់ត្រាវាម្តងក្នុងមួយម៉ោងក្នុង តារាងនៃសក្ដានុពលនៃការផ្លាស់ប្តូរ ("និន្នាការ") ។ "Housekeeper" ចាប់ផ្តើម និងលុបទិន្នន័យចេញពីមូលដ្ឋានទិន្នន័យដោយប្រើជម្រើសធម្មតា ដែលមិនតែងតែមានប្រសិទ្ធភាព។

តើធ្វើដូចម្តេចដើម្បីយល់ថាវាមិនមានប្រសិទ្ធភាព? អ្នកអាចឃើញរូបភាពខាងក្រោមនៅលើក្រាហ្វនៃដំណើរការផ្ទៃក្នុង៖

កម្មវិធីធ្វើសមកាលកម្មប្រវត្តិរបស់អ្នកជាប់រវល់ជានិច្ច (ក្រាហ្វក្រហម)។ ហើយក្រាហ្វ "ក្រហម" ដែលនៅខាងលើ។ នេះគឺជា "Housekeeper" ដែលចាប់ផ្តើម និងរង់ចាំមូលដ្ឋានទិន្នន័យដើម្បីលុបជួរទាំងអស់ដែលវាបានបញ្ជាក់។

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

អ្នកអាចបិទ Housekeeper តាមវិធីសាមញ្ញមួយ - យើងមានចំណុចប្រទាក់គេហទំព័រដែលធ្លាប់ស្គាល់។ ការកំណត់នៅក្នុងរដ្ឋបាលទូទៅ (ការកំណត់សម្រាប់ "អ្នកថែរក្សាផ្ទះ") យើងបិទការរក្សាផ្ទៃក្នុងសម្រាប់ប្រវត្តិផ្ទៃក្នុង និងនិន្នាការ។ ដូច្នោះហើយ មេផ្ទះលែងគ្រប់គ្រងរឿងនេះទៀតហើយ៖

តើអ្នកអាចធ្វើអ្វីបន្ទាប់ទៀត? អ្នក​បាន​បិទ​វា ក្រាហ្វិក​របស់​អ្នក​បាន​ឡើង​កម្រិត... តើ​មាន​បញ្ហា​អ្វី​ទៀត​អាច​កើត​ឡើង​ក្នុង​ករណី​នេះ? តើអ្វីអាចជួយបាន?

ការបែងចែក (ការបែងចែក)

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

អាស្រ័យលើការដំឡើងរបស់អ្នក (ចំនួនទិន្នន័យដែលអ្នកបង្កើតក្នុងមួយថ្ងៃ) ពួកគេជាធម្មតាកំណត់អប្បបរមា - នេះគឺ 1 ថ្ងៃ / បាច់ ហើយសម្រាប់ "និន្នាការ" ថាមវន្តនៃការផ្លាស់ប្តូរ - 1 ខែ / បាច់ថ្មី។ វាអាចផ្លាស់ប្តូរប្រសិនបើអ្នកមានការដំឡើងធំណាស់។

ចូរនិយាយភ្លាមៗអំពីទំហំនៃការដំឡើង: រហូតដល់ 5 ពាន់តម្លៃថ្មីក្នុងមួយវិនាទី (គេហៅថា nvps) - នេះនឹងត្រូវបានចាត់ទុកថាជា "ការដំឡើង" តូចមួយ។ ជាមធ្យម - ពី 5 ទៅ 25 ពាន់តម្លៃក្នុងមួយវិនាទី។ ទាំងអស់ខាងលើគឺជាការដំឡើងធំ និងធំខ្លាំងណាស់ ដែលទាមទារការកំណត់រចនាសម្ព័ន្ធយ៉ាងប្រុងប្រយ័ត្ននៃមូលដ្ឋានទិន្នន័យ។

នៅលើការដំឡើងដ៏ធំបំផុត 1 ថ្ងៃប្រហែលជាមិនល្អបំផុតទេ។ ខ្ញុំផ្ទាល់បានឃើញភាគថាសនៅលើ MySQL ចំនួន 40 ជីហ្គាបៃក្នុងមួយថ្ងៃ (ហើយអាចមានច្រើនទៀត)។ នេះគឺជាចំនួនទិន្នន័យដ៏ច្រើន ដែលអាចនាំឱ្យមានបញ្ហាមួយចំនួន។ វាចាំបាច់ត្រូវកាត់បន្ថយ។

ហេតុអ្វីបានជាអ្នកត្រូវការការបែងចែក?

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

សម្រាប់ Zabbix ជា​ពិសេស វា​ត្រូវ​បាន​ប្រើ​តាម​ជួរ ដោយ​ជួរ ពោល​គឺ​យើង​ប្រើ​ត្រា​ពេល​វេលា (លេខ​ធម្មតា ពេលវេលា​ចាប់​តាំង​ពី​ដើម​សម័យ)។ អ្នកបញ្ជាក់ការចាប់ផ្តើមនៃថ្ងៃ/ចុងបញ្ចប់នៃថ្ងៃ ហើយនេះគឺជាភាគថាស។ ដូច្នោះហើយ ប្រសិនបើអ្នកកំពុងស្នើសុំទិន្នន័យដែលមានអាយុកាលពីរថ្ងៃ អ្វីៗទាំងអស់ត្រូវបានទាញយកពីមូលដ្ឋានទិន្នន័យលឿនជាងមុន ព្រោះអ្នកគ្រាន់តែត្រូវផ្ទុកឯកសារមួយទៅក្នុងឃ្លាំងសម្ងាត់ ហើយបញ្ជូនវាមកវិញ (ជាជាងតារាងធំ)។

មូលដ្ឋានទិន្នន័យជាច្រើនក៏បង្កើនល្បឿនការបញ្ចូល (ការបញ្ចូលទៅក្នុងតារាងកូនតែមួយ)។ ខ្ញុំកំពុងនិយាយអរូបីសម្រាប់ពេលនេះ ប៉ុន្តែនេះក៏អាចទៅរួចដែរ។ ការបែងចែកជាញឹកញាប់ជួយ។

Elasticsearch សម្រាប់ NoSQL

ថ្មីៗនេះនៅក្នុង 3.4 យើងបានអនុវត្តដំណោះស្រាយ NoSQL ។ បានបន្ថែមសមត្ថភាពក្នុងការសរសេរនៅក្នុង Elasticsearch ។ អ្នកអាចសរសេរប្រភេទមួយចំនួន៖ អ្នកជ្រើសរើស - សរសេរលេខ ឬសញ្ញាមួយចំនួន។ យើងមានអក្សរអក្សរ អ្នកអាចសរសេរកំណត់ហេតុទៅកាន់ Elasticsearch... ដូច្នេះហើយ ចំណុចប្រទាក់គេហទំព័រក៏នឹងចូលប្រើ Elasticsearch ផងដែរ។ វាដំណើរការល្អក្នុងករណីខ្លះ ប៉ុន្តែនៅពេលនេះវាអាចប្រើបាន។

TimescaleDB ។ តារាងលើស

សម្រាប់ 4.4.2 យើងបានយកចិត្តទុកដាក់លើរឿងមួយដូចជា TimescaleDB ។ តើ​វា​ជា​អ្វី? នេះគឺជាផ្នែកបន្ថែមសម្រាប់ PostgreSQL ពោលគឺវាមានចំណុចប្រទាក់ PostgreSQL ដើម។ លើសពីនេះ កម្មវិធីបន្ថែមនេះអនុញ្ញាតឱ្យអ្នកធ្វើការកាន់តែមានប្រសិទ្ធភាពជាមួយនឹងទិន្នន័យដង និងមានការបែងចែកដោយស្វ័យប្រវត្តិ។ តើវាមើលទៅដូចអ្វី៖

នេះគឺជា Hypertable - មានគំនិតបែបនេះនៅក្នុង Timescale ។ នេះគឺជា Hypertable ដែលអ្នកបង្កើត ហើយវាមានកំណាត់។ កំណាត់គឺជាភាគថាស ទាំងនេះគឺជាតារាងកុមារ ប្រសិនបើខ្ញុំមិនច្រឡំទេ។ វាពិតជាមានប្រសិទ្ធភាព។

TimescaleDB និង PostgreSQL

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

របៀបដំឡើង TimescaleDB? វាសាមញ្ញ!

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

នៅលើ Zabbix យើងគ្រាន់តែបើកដំណើរការ Extention ។ ខ្ញុំគិតថាអ្នកដែលបានប្រើ Extention នៅក្នុង Postgres... អ្នកគ្រាន់តែបើកដំណើរការ Extention បង្កើតវាសម្រាប់មូលដ្ឋានទិន្នន័យ Zabbix ដែលអ្នកកំពុងប្រើ។

ហើយជំហានចុងក្រោយ ...

TimescaleDB ។ ការធ្វើចំណាកស្រុកនៃតារាងប្រវត្តិសាស្រ្ត

អ្នកត្រូវបង្កើត hypertable ។ មានមុខងារពិសេសសម្រាប់វា - បង្កើត hypertable ។ នៅក្នុងវា ប៉ារ៉ាម៉ែត្រទីមួយគឺជាតារាងដែលត្រូវការនៅក្នុងមូលដ្ឋានទិន្នន័យនេះ (ដែលអ្នកត្រូវបង្កើត hypertable) ។

វាល​ដែល​ត្រូវ​បង្កើត និង chunk_time_interval (នេះ​គឺ​ជា​ចន្លោះ​ពេល​នៃ​កំណាត់ (ភាគ​ដែល​ត្រូវ​ប្រើ)) 86 គឺ​ក្នុង​មួយ​ថ្ងៃ។

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

ខ្ញុំបានប្រើ migrate_data ដោយខ្លួនឯង - វាត្រូវការពេលវេលាគ្រប់គ្រាន់ អាស្រ័យលើទំហំមូលដ្ឋានទិន្នន័យរបស់អ្នក។ ខ្ញុំមានជាងមួយ terabyte - វាចំណាយពេលជាងមួយម៉ោងដើម្បីបង្កើត។ ក្នុងករណីខ្លះ ក្នុងអំឡុងពេលធ្វើតេស្ត ខ្ញុំបានលុបទិន្នន័យប្រវត្តិសាស្ត្រសម្រាប់អត្ថបទ (history_text) និងខ្សែអក្សរ (history_str) ដើម្បីកុំឱ្យផ្ទេរពួកវា - ពួកគេពិតជាមិនចាប់អារម្មណ៍ចំពោះខ្ញុំទេ។

ហើយយើងធ្វើបច្ចុប្បន្នភាពចុងក្រោយនៅក្នុង db_extention របស់យើង៖ យើងដំឡើង timescaledb ដើម្បីឱ្យមូលដ្ឋានទិន្នន័យ ហើយជាពិសេស Zabbix របស់យើងយល់ថាមាន db_extention ។ គាត់ធ្វើឱ្យសកម្មវា ហើយប្រើវាក្យសម្ព័ន្ធ និងសំណួរត្រឹមត្រូវទៅកាន់មូលដ្ឋានទិន្នន័យ ដោយប្រើ "លក្ខណៈពិសេស" ទាំងនោះដែលចាំបាច់សម្រាប់ TimescaleDB ។

ការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ

ខ្ញុំបានប្រើម៉ាស៊ីនមេពីរ។ ម៉ាស៊ីនមេដំបូងគឺម៉ាស៊ីននិម្មិតតូចល្មម, ដំណើរការ 20, RAM 16 ជីហ្គាបៃ។ ខ្ញុំបានកំណត់រចនាសម្ព័ន្ធ Postgres 10.8 នៅលើវា៖

ប្រព័ន្ធប្រតិបត្តិការគឺ Debian ប្រព័ន្ធឯកសារគឺ xfs ។ ខ្ញុំបានកំណត់តិចតួចបំផុតដើម្បីប្រើមូលដ្ឋានទិន្នន័យពិសេសនេះ ដកអ្វីដែល Zabbix ខ្លួនវានឹងប្រើ។ នៅលើម៉ាស៊ីនដូចគ្នាមានម៉ាស៊ីនមេ Zabbix, PostgreSQL និងភ្នាក់ងារផ្ទុក។

ខ្ញុំបានប្រើភ្នាក់ងារសកម្មចំនួន 50 ដែលប្រើ LoadableModule ដើម្បីបង្កើតលទ្ធផលផ្សេងគ្នាយ៉ាងឆាប់រហ័ស។ ពួកគេជាអ្នកបង្កើតខ្សែអក្សរ លេខ និងអ្វីៗផ្សេងទៀត។ ខ្ញុំបានបំពេញមូលដ្ឋានទិន្នន័យជាមួយនឹងទិន្នន័យជាច្រើន។ ដំបូង ការកំណត់រចនាសម្ព័ន្ធមានធាតុទិន្នន័យចំនួន 5 ពាន់ក្នុងមួយម៉ាស៊ីន ហើយប្រហែលធាតុទិន្នន័យនីមួយៗមានគន្លឹះ - ដើម្បីឱ្យវាក្លាយជាការរៀបចំពិតប្រាកដ។ ពេលខ្លះអ្នកថែមទាំងត្រូវការកេះច្រើនជាងមួយដើម្បីប្រើ។

ខ្ញុំបានគ្រប់គ្រងចន្លោះពេលអាប់ដេត និងការផ្ទុកដោយខ្លួនឯង ដោយមិនត្រឹមតែប្រើ 50 ភ្នាក់ងារ (បន្ថែមបន្ថែមទៀត) ប៉ុន្តែថែមទាំងប្រើធាតុទិន្នន័យថាមវន្ត និងកាត់បន្ថយចន្លោះពេលធ្វើបច្ចុប្បន្នភាពមកត្រឹម 4 វិនាទី។

ការធ្វើតេស្តការអនុវត្ត។ PostgreSQL: 36 ពាន់ NVPs

ការចាប់ផ្តើមដំបូង ការរៀបចំដំបូងដែលខ្ញុំមានគឺនៅលើ PostreSQL 10 សុទ្ធនៅលើផ្នែករឹងនេះ (តម្លៃ 35 ពាន់ក្នុងមួយវិនាទី) ។ ជាទូទៅ ដូចដែលអ្នកអាចមើលឃើញនៅលើអេក្រង់ ការបញ្ចូលទិន្នន័យចំណាយពេលប្រភាគនៃវិនាទី - អ្វីគ្រប់យ៉ាងគឺល្អ និងលឿន ដ្រាយ SSD (200 ជីហ្គាបៃ) ។ រឿងតែមួយគត់គឺថា 20 GB បំពេញបានយ៉ាងលឿន។

វានឹងមានក្រាហ្វបែបនេះច្រើនណាស់នាពេលអនាគត។ នេះគឺជាផ្ទាំងគ្រប់គ្រងដំណើរការម៉ាស៊ីនមេ Zabbix ស្តង់ដារ។

ក្រាហ្វទីមួយគឺជាចំនួនតម្លៃក្នុងមួយវិនាទី (ពណ៌ខៀវផ្នែកខាងលើខាងឆ្វេង) តម្លៃ 35 ពាន់នៅក្នុងករណីនេះ។ នេះ (មជ្ឈមណ្ឌលខាងលើ) គឺជាការផ្ទុកដំណើរការសាងសង់ ហើយនេះ (ខាងស្តាំខាងលើ) គឺជាការផ្ទុកដំណើរការខាងក្នុង៖ អ្នកធ្វើសមកាលកម្មប្រវត្តិ និងអ្នកថែរក្សាផ្ទះ ដែលនៅទីនេះ (មជ្ឈមណ្ឌលខាងក្រោម) បានដំណើរការអស់មួយរយៈហើយ។

ក្រាហ្វនេះ (កណ្តាលខាងក្រោម) បង្ហាញពីការប្រើប្រាស់ ValueCache - តើចំនួន ValueCache បុកសម្រាប់កេះ (តម្លៃរាប់ពាន់ក្នុងមួយវិនាទី)។ ក្រាហ្វដ៏សំខាន់មួយទៀតគឺលេខទី XNUMX (ខាងឆ្វេងខាងក្រោម) ដែលបង្ហាញពីការប្រើប្រាស់ HistoryCache ដែលខ្ញុំបាននិយាយអំពី ដែលជាសតិបណ្ដោះអាសន្នមុនពេលបញ្ចូលទៅក្នុងមូលដ្ឋានទិន្នន័យ។

ការធ្វើតេស្តការអនុវត្ត។ PostgreSQL: 50 ពាន់ NVPs

បន្ទាប់ខ្ញុំបានបង្កើនបន្ទុកដល់ 50 ពាន់តម្លៃក្នុងមួយវិនាទីនៅលើផ្នែករឹងដូចគ្នា។ នៅពេលផ្ទុកដោយ Housekeeper តម្លៃ 10 ពាន់ត្រូវបានកត់ត្រាក្នុងរយៈពេល 2-3 វិនាទីជាមួយនឹងការគណនា។ តាមពិតអ្វីដែលត្រូវបានបង្ហាញនៅក្នុងរូបថតអេក្រង់ខាងក្រោម៖

"ស្ត្រីមេផ្ទះ" កំពុងចាប់ផ្តើមជ្រៀតជ្រែកការងាររួចហើយ ប៉ុន្តែជាទូទៅ បន្ទុកលើអ្នកជាប់អន្ទាក់ប្រវត្តិសាស្ត្រនៅតែស្ថិតក្នុងកម្រិត 60% (ក្រាហ្វទីបី ខាងស្តាំខាងលើ)។ HistoryCache ចាប់ផ្តើមបំពេញយ៉ាងសកម្មរួចហើយ ខណៈពេលដែលអ្នកថែរក្សាផ្ទះកំពុងដំណើរការ (ខាងឆ្វេងខាងក្រោម)។ វាគឺប្រហែលកន្លះជីហ្គាបៃ 20% ពេញ។

ការធ្វើតេស្តការអនុវត្ត។ PostgreSQL: 80 ពាន់ NVPs

បន្ទាប់មកខ្ញុំបានបង្កើនវាដល់ 80 ពាន់តម្លៃក្នុងមួយវិនាទី:

វាមានប្រហែល 400 ពាន់ធាតុទិន្នន័យ 280 ពាន់កេះ។ ការបញ្ចូលដូចដែលអ្នកអាចឃើញនៅក្នុងលក្ខខណ្ឌនៃបន្ទុកនៃអ្នកលិចប្រវត្តិសាស្រ្ត (មាន 30 ក្នុងចំណោមពួកគេ) គឺខ្ពស់រួចទៅហើយ។ បន្ទាប់មកខ្ញុំបានបង្កើនប៉ារ៉ាម៉ែត្រផ្សេងៗ៖ ប្រវត្តិ sinkers, cache... នៅលើ hardware នេះ ការផ្ទុកនៅលើ history sinkers ចាប់ផ្តើមកើនឡើងដល់អតិបរមា ស្ទើរតែ "នៅលើ shelf" - អាស្រ័យហេតុនេះ HistoryCache បានចូលទៅក្នុងបន្ទុកខ្ពស់ណាស់៖

គ្រប់ពេលវេលានេះ ខ្ញុំបានត្រួតពិនិត្យប៉ារ៉ាម៉ែត្រប្រព័ន្ធទាំងអស់ (របៀបដែលខួរក្បាលត្រូវបានប្រើប្រាស់ RAM) ហើយបានរកឃើញថាការប្រើប្រាស់ថាសគឺអតិបរមា - ខ្ញុំសម្រេចបានសមត្ថភាពអតិបរមានៃថាសនេះនៅលើផ្នែករឹងនេះ នៅលើម៉ាស៊ីននិម្មិតនេះ។ "Postgres" បានចាប់ផ្តើមបោះចោលទិន្នន័យយ៉ាងសកម្មក្នុងកម្រិតខ្លាំងបែបនេះ ហើយថាសលែងមានពេលសរសេរ អាន...

ខ្ញុំបានយកម៉ាស៊ីនមេមួយទៀតដែលមាន 48 processors និង RAM 128 ជីហ្គាបៃរួចហើយ៖

ខ្ញុំក៏បាន "លៃតម្រូវ" វាផងដែរ - បានដំឡើងកម្មវិធីធ្វើសមកាលកម្មប្រវត្តិ (60 បំណែក) និងសម្រេចបាននូវការអនុវត្តដែលអាចទទួលយកបាន។ តាមការពិត យើងមិនមែន "នៅលើធ្នើ" ទេ ប៉ុន្តែនេះប្រហែលជាដែនកំណត់នៃផលិតភាព ដែលវាចាំបាច់រួចហើយដើម្បីធ្វើអ្វីមួយអំពីវា។

ការធ្វើតេស្តការអនុវត្ត។ TimescaleDB: 80 ពាន់ NVPs

ភារកិច្ចចម្បងរបស់ខ្ញុំគឺប្រើ TimescaleDB ។ ក្រាហ្វនីមួយៗបង្ហាញពីការធ្លាក់ចុះ៖

ការបរាជ័យទាំងនេះគឺជាការផ្ទេរទិន្នន័យយ៉ាងជាក់លាក់។ បន្ទាប់ពីនោះ នៅក្នុងម៉ាស៊ីនមេ Zabbix ទម្រង់នៃការផ្ទុកនៃអ្នកលិចប្រវត្តិសាស្ត្រ ដូចដែលអ្នកបានឃើញបានផ្លាស់ប្តូរច្រើន។ វាអនុញ្ញាតឱ្យអ្នកបញ្ចូលទិន្នន័យលឿនជាងជិត 3 ដង និងប្រើ HistoryCache តិច - អាស្រ័យហេតុនេះ អ្នកនឹងមានការបញ្ជូនទិន្នន័យទាន់ពេលវេលា។ ជាថ្មីម្តងទៀត 80 ពាន់តម្លៃក្នុងមួយវិនាទីគឺជាអត្រាខ្ពស់ដោយយុត្តិធម៌ (ជាការពិតមិនមែនសម្រាប់ Yandex) ។ សរុបមក នេះគឺជាការដំឡើងធំគួរសម ជាមួយនឹងម៉ាស៊ីនមេតែមួយ។

ការធ្វើតេស្តការអនុវត្ត PostgreSQL: 120 ពាន់ NVPs

បន្ទាប់មកខ្ញុំបានបង្កើនតម្លៃនៃចំនួនធាតុទិន្នន័យដល់កន្លះលានហើយទទួលបានតម្លៃគណនា 125 ពាន់ក្នុងមួយវិនាទី:

ហើយខ្ញុំទទួលបានក្រាហ្វទាំងនេះ៖

ជាគោលការណ៍នេះគឺជាការរៀបចំការងារវាអាចដំណើរការបានក្នុងរយៈពេលយូរ។ ប៉ុន្តែដោយសារខ្ញុំមានថាស 1,5 terabyte ខ្ញុំបានប្រើវាក្នុងរយៈពេលពីរបីថ្ងៃ។ អ្វីដែលសំខាន់បំផុតនោះគឺថានៅពេលជាមួយគ្នានោះភាគថាសថ្មីត្រូវបានបង្កើតឡើងនៅលើ TimescaleDB ហើយនេះមិនត្រូវបានកត់សម្គាល់ទាំងស្រុងសម្រាប់ការអនុវត្តដែលមិនអាចនិយាយអំពី MySQL បានទេ។

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

មានឧទាហរណ៍ក្នុងសហគមន៍ផងដែរ៖

មនុស្សម្នាក់ក៏បានបើក TimescaleDB ហើយបន្ទុកលើការប្រើប្រាស់ io.weight បានធ្លាក់ចុះនៅលើខួរក្បាល។ ហើយការប្រើប្រាស់ធាតុដំណើរការខាងក្នុងក៏ថយចុះផងដែរ ដោយសារតែការរួមបញ្ចូល TimescaleDB ។ លើសពីនេះទៅទៀត ទាំងនេះគឺជាថាស pancake ធម្មតា នោះគឺជាម៉ាស៊ីននិម្មិតធម្មតានៅលើថាសធម្មតា (មិនមែន SSDs)!

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

ខ្ញុំសូមអញ្ជើញអ្នកទាំងអស់គ្នាឱ្យចូលរួមក្នុងព្រឹត្តិការណ៍របស់យើង៖ សន្និសីទនៅទីក្រុងមូស្គូ កិច្ចប្រជុំកំពូលនៅរីហ្គា។ ប្រើបណ្តាញរបស់យើង - Telegram, វេទិកា, IRC ។ ប្រសិនបើអ្នកមានចម្ងល់ សូមមកកាន់តុរបស់យើង យើងអាចនិយាយបានគ្រប់រឿង។

សំណួររបស់ទស្សនិកជន

សំណួរពីទស្សនិកជន (តទៅនេះ - ក)៖ - ប្រសិនបើ TimescaleDB មានភាពងាយស្រួលក្នុងការកំណត់ ហើយវាផ្តល់នូវការជំរុញការអនុវត្ត នោះប្រហែលជាវាគួរត្រូវបានប្រើជាការអនុវត្តល្អបំផុតសម្រាប់កំណត់រចនាសម្ព័ន្ធ Zabbix ជាមួយ Postgres? ហើយតើមានកំហុស និងគុណវិបត្តិនៃដំណោះស្រាយនេះឬយ៉ាងណា ប្រសិនបើខ្ញុំសម្រេចចិត្តបង្កើត Zabbix សម្រាប់ខ្លួនខ្ញុំ ខ្ញុំអាចយក Postgres បានយ៉ាងងាយស្រួល ដំឡើង Timescale នៅទីនោះភ្លាមៗ ប្រើវា ហើយមិនគិតពីបញ្ហាអ្វីទេ?

AG៖ - បាទ/ចាស ខ្ញុំចង់និយាយថា នេះជាការណែនាំដ៏ល្អមួយ៖ ប្រើ Postgres ភ្លាមៗជាមួយនឹងផ្នែកបន្ថែម TimescaleDB។ ដូចដែលខ្ញុំបាននិយាយរួចមកហើយ ការពិនិត្យល្អជាច្រើន ទោះបីជាការពិតដែលថា "លក្ខណៈពិសេស" នេះគឺជាការពិសោធន៍ក៏ដោយ។ ប៉ុន្តែតាមពិតការធ្វើតេស្តបង្ហាញថានេះគឺជាដំណោះស្រាយដ៏ល្អមួយ (ជាមួយ TimescaleDB) ហើយខ្ញុំគិតថាវានឹងវិវត្តន៍! យើងកំពុងតាមដានពីរបៀបដែលកម្មវិធីបន្ថែមនេះអភិវឌ្ឍ ហើយនឹងធ្វើការផ្លាស់ប្តូរតាមតម្រូវការ។

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

ចម្លើយ៖ - នៅលើក្រាហ្វចុងក្រោយពីសហគមន៍ មានក្រាហ្វជាមួយ "មេផ្ទះ"៖

គាត់បានបន្តធ្វើការ។ តើ Housekeeper ធ្វើអ្វីជាមួយ TimescaleDB?

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

ចម្លើយ៖ - ខ្ញុំមានសំណួរស្រដៀងគ្នា - អំពីដំណើរការនៃប្រតិបត្តិការលុបនៅក្នុង Timescale ។
ក (ចម្លើយពីទស្សនិកជន)៖ - នៅពេលអ្នកលុបទិន្នន័យចេញពីតារាង ប្រសិនបើអ្នកធ្វើវាតាមរយៈការលុប នោះអ្នកត្រូវឆ្លងកាត់តារាង - លុប សម្អាត សម្គាល់អ្វីៗគ្រប់យ៉ាងសម្រាប់ការខ្វះចន្លោះនាពេលអនាគត។ នៅក្នុង Timescale ចាប់តាំងពីអ្នកមានកំណាត់ អ្នកអាចទម្លាក់បាន។ និយាយដោយសាមញ្ញ អ្នកគ្រាន់តែប្រាប់ឯកសារដែលមានទិន្នន័យធំ៖ “លុប!”

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

ចម្លើយ៖ - យើងបានប៉ះលើប្រធានបទនៃមិនមែន SQL រួចហើយ។ តាមដែលខ្ញុំយល់ Zabbix ពិតជាមិនចាំបាច់កែប្រែទិន្នន័យនោះទេ ហើយអ្វីៗទាំងអស់នេះគឺដូចជាកំណត់ហេតុ។ តើវាអាចទៅរួចទេក្នុងការប្រើមូលដ្ឋានទិន្នន័យឯកទេសដែលមិនអាចផ្លាស់ប្តូរទិន្នន័យរបស់ពួកគេបាន ប៉ុន្តែក្នុងពេលតែមួយរក្សាទុក ប្រមូលផ្តុំ និងចែកចាយលឿនជាងមុន - Clickhouse ឧទាហរណ៍ អ្វីមួយដែលដូច Kafka?... Kafka ក៏ជាកំណត់ហេតុមួយដែរ! តើវាអាចទៅរួចក្នុងការរួមបញ្ចូលពួកវាដោយរបៀបណា?

AG៖ - ការដោះចេញអាចធ្វើទៅបាន។ យើងមាន "លក្ខណៈពិសេស" ជាក់លាក់មួយចាប់តាំងពីកំណែ 3.4: អ្នកអាចសរសេរឯកសារប្រវត្តិសាស្រ្តទាំងអស់ ព្រឹត្តិការណ៍ និងអ្វីៗផ្សេងទៀតទៅជាឯកសារ។ ហើយបន្ទាប់មកផ្ញើវាទៅមូលដ្ឋានទិន្នន័យផ្សេងទៀតដោយប្រើឧបករណ៍ដោះស្រាយមួយចំនួន។ ជាការពិត មនុស្សជាច្រើនធ្វើការឡើងវិញ ហើយសរសេរដោយផ្ទាល់ទៅមូលដ្ឋានទិន្នន័យ។ ភ្លាមៗនោះ អ្នកបង្កើតប្រវត្តិសាស្ត្រសរសេរអ្វីៗទាំងអស់នេះទៅក្នុងឯកសារ បង្វិលឯកសារទាំងនេះ និងអ្វីៗផ្សេងទៀត ហើយអ្នកអាចផ្ទេរវាទៅ Clickhouse ។ ខ្ញុំមិនអាចនិយាយអំពីផែនការបានទេ ប៉ុន្តែប្រហែលជាមានការគាំទ្របន្ថែមទៀតសម្រាប់ដំណោះស្រាយ NoSQL (ដូចជា Clickhouse) នឹងបន្ត។

ចម្លើយ៖ - ជាទូទៅវាប្រែថាអ្នកអាចកម្ចាត់ postgres ទាំងស្រុង?

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

ចម្លើយ៖ - តើអ្នកអាចប៉ាន់ប្រមាណថាតើអ្វីៗនឹងដំណើរការលឿនប៉ុណ្ណាប្រសិនបើអ្នកប្តូរទៅ Clickhouse ឧទាហរណ៍?

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

ចម្លើយ៖ - ដូច្នេះយើងកំពុងនិយាយអំពីការប្រយុទ្ធស្មើគ្នា ហើយមិនមែនអំពីអត្ថប្រយោជន៍ដ៏អស្ចារ្យនៃមូលដ្ឋានទិន្នន័យលឿនទាំងនេះទេ?

AG៖ - ខ្ញុំគិតថានៅពេលដែលយើងធ្វើសមាហរណកម្ម នឹងមានការធ្វើតេស្តត្រឹមត្រូវបន្ថែមទៀត។

ចម្លើយ៖ - តើ RRD ចាស់ទៅណា? តើអ្វីបានធ្វើឱ្យអ្នកប្តូរទៅមូលដ្ឋានទិន្នន័យ SQL? ដំបូង រង្វាស់ទាំងអស់ត្រូវបានប្រមូលនៅលើ RRD ។

AG៖ - Zabbix មាន RRD ប្រហែលជានៅក្នុងកំណែបុរាណណាស់។ វាតែងតែមានមូលដ្ឋានទិន្នន័យ SQL - វិធីសាស្រ្តបុរាណ។ វិធីសាស្រ្តបុរាណគឺ MySQL, PostgreSQL (ពួកវាមានតាំងពីយូរយារណាស់មកហើយ) ។ យើងស្ទើរតែមិនដែលប្រើចំណុចប្រទាក់ទូទៅសម្រាប់មូលដ្ឋានទិន្នន័យ SQL និង RRD ទេ។

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

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, 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