ដំណើរការខ្ពស់ និងការបែងចែកដើម៖ Zabbix ជាមួយនឹងការគាំទ្រ TimescaleDB

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

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

បញ្ហានៃការពន្យាពេលកំឡុងពេលប្រមូល និងការផ្ទុកនៅក្នុង Zabbix ត្រូវបានដោះស្រាយដោយឃ្លាំងសម្ងាត់៖ ប្រភេទជាច្រើននៃឃ្លាំងសម្ងាត់ ឃ្លាំងសម្ងាត់នៅក្នុងមូលដ្ឋានទិន្នន័យ។ ដើម្បីដោះស្រាយបញ្ហាទីបី ឃ្លាំងសម្ងាត់មិនសមរម្យ ដូច្នេះ Zabbix បានប្រើ TimescaleDB ។ គាត់នឹងប្រាប់អ្នកអំពីវា។ Andrey Gushchin - វិស្វករជំនួយបច្ចេកទេស Zabbix SIA. Andrey បាននិងកំពុងគាំទ្រ Zabbix អស់រយៈពេលជាង 6 ឆ្នាំហើយមានបទពិសោធន៍ផ្ទាល់ជាមួយការសម្តែង។

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

បញ្ហាប្រឈមផលិតភាព

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

ការប្រមូលទិន្នន័យ និងដំណើរការលឿន។ ប្រព័ន្ធត្រួតពិនិត្យដ៏ល្អគួរទទួលបានទិន្នន័យទាំងអស់យ៉ាងឆាប់រហ័ស ហើយដំណើរការវាតាមកន្សោមកេះ - យោងតាមលក្ខណៈវិនិច្ឆ័យរបស់វា។ បន្ទាប់ពីដំណើរការរួច ប្រព័ន្ធក៏ត្រូវរក្សាទុកទិន្នន័យនេះយ៉ាងរហ័សក្នុងមូលដ្ឋានទិន្នន័យសម្រាប់ប្រើប្រាស់នៅពេលក្រោយ។

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

ជម្រះប្រវត្តិ។ ពេលខ្លះមានថ្ងៃមួយដែលអ្នកមិនចាំបាច់រក្សាទុកម៉ែត្រ។ ហេតុអ្វីបានជាអ្នកត្រូវការទិន្នន័យដែលត្រូវបានប្រមូលកាលពី 5 ឆ្នាំមុន មួយខែ ឬពីរខែ៖ ថ្នាំងមួយចំនួនត្រូវបានលុប ម៉ាស៊ីន ឬម៉ែត្រមួយចំនួនលែងត្រូវការទៀតហើយ ព្រោះវាហួសសម័យ និងលែងប្រមូលទៀតហើយ។ ប្រព័ន្ធត្រួតពិនិត្យដ៏ល្អគួរតែរក្សាទុកទិន្នន័យប្រវត្តិសាស្រ្ត និងលុបវាពីពេលមួយទៅពេលមួយ ដើម្បីកុំឱ្យមូលដ្ឋានទិន្នន័យរីកចម្រើន។

ការសម្អាតទិន្នន័យជាប់គាំងគឺជាបញ្ហាសំខាន់ដែលជះឥទ្ធិពលយ៉ាងខ្លាំងដល់ដំណើរការមូលដ្ឋានទិន្នន័យ។

ឃ្លាំងសម្ងាត់នៅក្នុង Zabbix

នៅក្នុង Zabbix ការហៅទូរសព្ទទីមួយ និងទីពីរត្រូវបានដោះស្រាយដោយប្រើឃ្លាំងសម្ងាត់។ RAM ត្រូវបានប្រើដើម្បីប្រមូល និងដំណើរការទិន្នន័យ។ សម្រាប់ការផ្ទុក - ប្រវត្តិនៅក្នុងគន្លឹះ ក្រាហ្វិក និងធាតុទិន្នន័យដែលបានគណនា។ នៅលើផ្នែកមូលដ្ឋានទិន្នន័យមានឃ្លាំងសម្ងាត់មួយចំនួនសម្រាប់ការជ្រើសរើសជាមូលដ្ឋាន ឧទាហរណ៍ ក្រាហ្វ។

ឃ្លាំងសម្ងាត់នៅផ្នែកម្ខាងនៃម៉ាស៊ីនមេ Zabbix ខ្លួនវាគឺ៖

• ការកំណត់រចនាសម្ព័ន្ធឃ្លាំងសម្ងាត់;
• ValueCache;
• ឃ្លាំងសម្ងាត់ប្រវត្តិ;
• TrendsCache ។

ចូរយើងពិចារណាលម្អិតបន្ថែមទៀត។

ការកំណត់រចនាសម្ព័ន្ធឃ្លាំងសម្ងាត់

នេះគឺជាឃ្លាំងសម្ងាត់សំខាន់ដែលយើងរក្សាទុកម៉ែត្រ ម៉ាស៊ីន ធាតុទិន្នន័យ គន្លឹះ - អ្វីគ្រប់យ៉ាងដែលយើងត្រូវការសម្រាប់ការដំណើរការមុន និងសម្រាប់ការប្រមូលទិន្នន័យ។

ទាំងអស់នេះត្រូវបានរក្សាទុកក្នុង ConfigurationCache ដើម្បីកុំឱ្យបង្កើតសំណួរដែលមិនចាំបាច់នៅក្នុងមូលដ្ឋានទិន្នន័យ។ បន្ទាប់ពីម៉ាស៊ីនមេចាប់ផ្តើម យើងធ្វើបច្ចុប្បន្នភាពឃ្លាំងសម្ងាត់នេះ បង្កើត និងធ្វើបច្ចុប្បន្នភាពការកំណត់រចនាសម្ព័ន្ធជាប្រចាំ។

ការ​ប្រមូល​ទិន្នន័យ

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

អ្នកប្រមូលត្រូវបានគូសបញ្ជាក់ជាពណ៌ទឹកក្រូច។

Zabbix បានគណនាធាតុសរុបដែលចាំបាច់ដើម្បីប្រមូលមូលប្បទានប័ត្រ។ ប្រសិនបើយើងមានពួកវា យើងទៅយកទិន្នន័យសម្រាប់ពួកវាដោយផ្ទាល់ពី ValueCache ។

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

អ្នកប្រមូលទាំងអស់ប្រើ ConfigurationCache ដើម្បីទទួលបានការងារ។ បន្ទាប់មកពួកគេផ្ទេរពួកវាទៅ PreProcessing ។

PreProcessing ប្រើ ConfigurationCache ដើម្បីទទួលបានជំហាន PreProcessing។ វាដំណើរការទិន្នន័យនេះតាមវិធីផ្សេងៗ។

បន្ទាប់ពីដំណើរការទិន្នន័យដោយប្រើ PreProcessing យើងរក្សាទុកវានៅក្នុង HistoryCache សម្រាប់ដំណើរការ។ វាបញ្ចប់ការប្រមូលទិន្នន័យ ហើយយើងបន្តទៅដំណើរការចម្បងនៅក្នុង Zabbix - ឧបករណ៍ធ្វើសមកាលកម្មប្រវត្តិចាប់តាំងពីវាជាស្ថាបត្យកម្ម monolithic ។

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

ឃ្លាំងសម្ងាត់ ValueCache ប្រវត្តិ និងនិន្នាការ

កម្មវិធីធ្វើសមកាលកម្មប្រវត្តិគឺជាដំណើរការចម្បងដែលដំណើរការដោយអាតូមិកធាតុទិន្នន័យនីមួយៗ ពោលគឺតម្លៃនីមួយៗ។

កម្មវិធីធ្វើសមកាលកម្មប្រវត្តិយកតម្លៃពី HistoryCache ហើយពិនិត្យការកំណត់រចនាសម្ព័ន្ធសម្រាប់វត្តមាននៃគន្លឹះសម្រាប់ការគណនា។ ប្រសិនបើពួកគេមានវាគណនា។

កម្មវិធីធ្វើសមកាលកម្មប្រវត្តិបង្កើតព្រឹត្តិការណ៍ ការកើនឡើង ដើម្បីបង្កើតការជូនដំណឹង ប្រសិនបើទាមទារដោយការកំណត់រចនាសម្ព័ន្ធ និងកំណត់ត្រា។ ប្រសិនបើមានកេះសម្រាប់ដំណើរការជាបន្តបន្ទាប់ នោះវារក្សាទុកតម្លៃនេះនៅក្នុង ValueCache ដើម្បីកុំឱ្យចូលទៅកាន់តារាងប្រវត្តិ។ នេះជារបៀបដែល ValueCache ត្រូវបានបំពេញដោយទិន្នន័យដែលចាំបាច់ក្នុងការគណនាគន្លឹះ និងធាតុដែលបានគណនា។

កម្មវិធីធ្វើសមកាលកម្មប្រវត្តិសរសេរទិន្នន័យទាំងអស់ទៅមូលដ្ឋានទិន្នន័យ ហើយវាសរសេរទៅថាស។ ដំណើរការដំណើរការបញ្ចប់នៅទីនេះ។

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

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

• Innodb_buffer_pool នៅលើផ្នែក MySQL;
• shared_buffers នៅផ្នែក PostgreSQL;
• effective_cache_size នៅផ្នែកខាង Oracle;
• shared_pool នៅផ្នែកខាង DB2 ។

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

ដំណើរការមូលដ្ឋានទិន្នន័យមានសារៈសំខាន់ណាស់។

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

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

ផ្ទះ

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

យើងគណនា TrendsCache ភ្លាមៗ។ នៅពេលដែលទិន្នន័យមកដល់ យើងប្រមូលផ្តុំវារយៈពេលមួយម៉ោង ហើយកត់ត្រាវានៅក្នុងតារាងសម្រាប់ឌីណាមិកនៃការផ្លាស់ប្តូរនិន្នាការ។

ម្ចាស់ផ្ទះចាប់ផ្តើម និងលុបព័ត៌មានចេញពីមូលដ្ឋានទិន្នន័យដោយប្រើ "ជ្រើសរើស" ធម្មតា។ នេះមិនតែងតែមានប្រសិទ្ធភាពទេ ដូចដែលអាចមើលឃើញពីក្រាហ្វនៃដំណើរការផ្ទៃក្នុង។

ក្រាហ្វក្រហមបង្ហាញថាកម្មវិធីធ្វើសមកាលកម្មប្រវត្តិជាប់រវល់ជានិច្ច។ ក្រាហ្វពណ៌ទឹកក្រូចនៅផ្នែកខាងលើគឺ Housekeeper ដែលដំណើរការឥតឈប់ឈរ។ គាត់រង់ចាំមូលដ្ឋានទិន្នន័យដើម្បីលុបជួរទាំងអស់ដែលគាត់បានបញ្ជាក់។

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

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

ស្ត្រីមេផ្ទះត្រូវបានបិទ ក្រាហ្វបានថយចុះ - តើមានបញ្ហាអ្វីខ្លះក្នុងករណីនេះ និងអ្វីដែលអាចជួយដោះស្រាយបញ្ហាប្រឈមនៃការអនុវត្តទីបី?

ការបែងចែក - ការបែងចែកឬការបែងចែក

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

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

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

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

តើការបែងចែកផ្តល់អ្វី?

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

ការដកយកចេញរហ័ស - DELETE. ឯកសារ/តារាងរងមួយត្រូវបានជ្រើសរើស ជាជាងការជ្រើសរើសជួរសម្រាប់ការលុប។

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

ជាញឹកញាប់មូលដ្ឋានទិន្នន័យជាច្រើនក៏ត្រូវបានពន្លឿនផងដែរ។ INSERT - ការបញ្ចូលទៅក្នុងតារាងកុមារ។

កាលវិភាគឌីប៊ី

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

TimescaleDB មានគំនិតមួយ។ តុខ្ពស់ (hypertable) ដែលអ្នកបង្កើត។ វា​មាន កំណាត់ - ភាគថាស។ Chunks គឺត្រូវបានគ្រប់គ្រងដោយស្វ័យប្រវត្តិនូវបំណែក hypertable ដែលមិនប៉ះពាល់ដល់បំណែកផ្សេងទៀត។ កំណាត់នីមួយៗមានចន្លោះពេលរបស់វា។

TimescaleDB ទល់នឹង PostgreSQL

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

បន្ទាប់ពី 200 លានជួរ ជាធម្មតា PostgreSQL ចាប់ផ្តើមធ្លាក់ចុះយ៉ាងខ្លាំង ហើយបាត់បង់ដំណើរការទៅ 0។ TimescaleDB អនុញ្ញាតឱ្យអ្នកបញ្ចូល "បញ្ចូល" ប្រកបដោយប្រសិទ្ធភាពសម្រាប់ចំនួនទិន្នន័យណាមួយ។

ការកំណត់

ការដំឡើង TimescaleDB គឺមានភាពងាយស្រួលសម្រាប់កញ្ចប់ណាមួយ។ IN ឯកសារ អ្វីគ្រប់យ៉ាងត្រូវបានពិពណ៌នាលម្អិត - វាអាស្រ័យលើកញ្ចប់ PostgreSQL ផ្លូវការ។ TimescaleDB ក៏អាចត្រូវបានសាងសង់ និងចងក្រងដោយដៃផងដែរ។

សម្រាប់មូលដ្ឋានទិន្នន័យ Zabbix យើងគ្រាន់តែធ្វើឱ្យផ្នែកបន្ថែមសកម្ម៖

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

អ្នកធ្វើឱ្យសកម្ម extension ហើយបង្កើតវាសម្រាប់មូលដ្ឋានទិន្នន័យ Zabbix ។ ជំហានចុងក្រោយគឺបង្កើត hypertable ។

ការផ្ទេរតារាងប្រវត្តិសាស្រ្តទៅ TimescaleDB

មានមុខងារពិសេសសម្រាប់រឿងនេះ create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

មុខងារមានបីប៉ារ៉ាម៉ែត្រ។ ដំបូង - តារាងក្នុងមូលដ្ឋានទិន្នន័យដែលអ្នកត្រូវបង្កើត hypertable ។ ទីពីរ - វាលនេះបើយោងតាមដែលអ្នកត្រូវការដើម្បីបង្កើត chunk_time_interval - ចន្លោះពេលនៃភាគថាសដែលត្រូវប្រើ។ ក្នុងករណីរបស់ខ្ញុំចន្លោះពេលគឺមួយថ្ងៃ - 86 ។

ប៉ារ៉ាម៉ែត្រទីបី - migrate_data. ប្រសិនបើអ្នកកំណត់ trueបន្ទាប់មកទិន្នន័យបច្ចុប្បន្នទាំងអស់ត្រូវបានផ្ទេរទៅផ្នែកដែលបានបង្កើតជាមុន។ ខ្ញុំបានប្រើវាដោយខ្លួនឯង។ migrate_data. ខ្ញុំមានប្រហែល 1 TB ដែលចំណាយពេលជាងមួយម៉ោង។ ទោះបីជាក្នុងករណីខ្លះ ក្នុងអំឡុងពេលសាកល្បង ខ្ញុំបានលុបទិន្នន័យប្រវត្តិសាស្ត្រនៃប្រភេទតួអក្សរដែលមិនត្រូវការសម្រាប់ការផ្ទុក ដើម្បីកុំឱ្យផ្ទេរពួកវា។

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

ការកំណត់រចនាសម្ព័ន្ធផ្នែករឹង

ខ្ញុំបានប្រើម៉ាស៊ីនមេពីរ។ ដំបូង - ម៉ាស៊ីន VMware. វាតូចណាស់៖ 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz processors, RAM 16 GB និង SSD 200 GB ។

ខ្ញុំបានដំឡើង PostgreSQL 10.8 នៅលើវាជាមួយនឹង Debian 10.8-1.pgdg90+1 OS និង xfs file system។ ខ្ញុំបានកំណត់រចនាសម្ព័ន្ធអ្វីគ្រប់យ៉ាងតិចតួចបំផុតដើម្បីប្រើមូលដ្ឋានទិន្នន័យពិសេសនេះ ដកអ្វីដែល Zabbix ខ្លួនវានឹងប្រើ។

នៅលើម៉ាស៊ីនដូចគ្នាមានម៉ាស៊ីនមេ Zabbix, PostgreSQL និង ភ្នាក់ងារផ្ទុក. ខ្ញុំមានភ្នាក់ងារសកម្មចំនួន 50 ដែលកំពុងប្រើប្រាស់ LoadableModuleដើម្បីបង្កើតលទ្ធផលខុសគ្នាយ៉ាងឆាប់រហ័ស៖ លេខ ខ្សែអក្សរ។ ខ្ញុំបានបំពេញមូលដ្ឋានទិន្នន័យជាមួយនឹងទិន្នន័យជាច្រើន។

ដំបូងការកំណត់រចនាសម្ព័ន្ធមាន ធាតុ 5 ទិន្នន័យក្នុងមួយម៉ាស៊ីន។ ស្ទើរតែគ្រប់ធាតុទាំងអស់មានគន្លឹះដើម្បីធ្វើឱ្យវាស្រដៀងទៅនឹងការដំឡើងពិតប្រាកដ។ ក្នុងករណីខ្លះមានកេះច្រើនជាងមួយ។ សម្រាប់ថ្នាំងបណ្តាញមួយមាន 3-000 កេះ.

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

PostgreSQL ។ 35 nvps

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

នេះគឺជាផ្ទាំងគ្រប់គ្រងដំណើរការម៉ាស៊ីនមេ Zabbix ស្តង់ដារ។

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

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

PostgreSQL ។ 50 nvps

បន្ទាប់មកខ្ញុំបានបង្កើនបន្ទុកដល់ 50 ពាន់តម្លៃក្នុងមួយវិនាទីនៅលើផ្នែករឹងដូចគ្នា។

នៅពេលផ្ទុកពី Housekeeper ការបញ្ចូលតម្លៃ 10 ពាន់ត្រូវចំណាយពេល 2-3 វិនាទី។

មេផ្ទះកំពុងចាប់ផ្តើមជ្រៀតជ្រែកការងាររួចហើយ។

ក្រាហ្វទីបីបង្ហាញថាជាទូទៅការផ្ទុកនៅលើឧបករណ៍ចាប់អន្ទាក់និងឧបករណ៍ធ្វើសមកាលកម្មប្រវត្តិសាស្រ្តនៅតែមាន 60% ។ នៅក្នុងក្រាហ្វទី 20 HistoryCache កំពុងចាប់ផ្តើមបំពេញយ៉ាងសកម្មក្នុងអំឡុងពេលប្រតិបត្តិការ Housekeeper ។ វាពេញ 0,5% ដែលមានប្រហែល XNUMX GB។

PostgreSQL ។ 80 nvps

បន្ទាប់មកខ្ញុំបានបង្កើនបន្ទុកដល់ 80 ពាន់តម្លៃក្នុងមួយវិនាទី។ នេះគឺប្រហែល 400 ពាន់ធាតុទិន្នន័យ និង 280 ពាន់កេះ។

តម្លៃនៃការផ្ទុកឧបករណ៍ធ្វើសមកាលកម្មប្រវត្តិសាមសិបគឺខ្ពស់រួចទៅហើយ។

ខ្ញុំក៏បានបង្កើនប៉ារ៉ាម៉ែត្រផ្សេងៗផងដែរ៖ ឧបករណ៍ធ្វើសមកាលកម្មប្រវត្តិ ឃ្លាំងសម្ងាត់។

នៅលើផ្នែករឹងរបស់ខ្ញុំ ការផ្ទុកឧបករណ៍ធ្វើសមកាលកម្មប្រវត្តិបានកើនឡើងដល់អតិបរមា។ HistoryCache បានបំពេញយ៉ាងលឿនដោយទិន្នន័យ - ទិន្នន័យសម្រាប់ដំណើរការបានប្រមូលផ្តុំនៅក្នុងសតិបណ្ដោះអាសន្ន។

គ្រប់ពេលវេលានេះ ខ្ញុំបានសង្កេតមើលពីរបៀបដែល processor, RAM និងប៉ារ៉ាម៉ែត្រប្រព័ន្ធផ្សេងទៀតត្រូវបានប្រើប្រាស់ ហើយបានរកឃើញថាការប្រើប្រាស់ថាសគឺនៅអតិបរមារបស់វា។

ខ្ញុំបានសម្រេចការប្រើប្រាស់ សមត្ថភាពឌីសអតិបរមា នៅលើផ្នែករឹងនេះ និងនៅលើម៉ាស៊ីននិម្មិតនេះ។ ជាមួយនឹងអាំងតង់ស៊ីតេបែបនេះ PostgreSQL ចាប់ផ្តើមបញ្ចេញទិន្នន័យយ៉ាងសកម្ម ហើយថាសលែងមានពេលសរសេរ និងអានទៀតហើយ។

ម៉ាស៊ីនមេទីពីរ

ខ្ញុំបានយកម៉ាស៊ីនមេមួយផ្សេងទៀតដែលមានប្រព័ន្ធដំណើរការ 48 រួចហើយនិង RAM 128 GB ។ ខ្ញុំបានលៃតម្រូវវា - កំណត់វាទៅជា 60 history syncer ហើយសម្រេចបាននូវដំណើរការដែលអាចទទួលយកបាន។

តាមពិត នេះ​គឺជា​កម្រិត​នៃ​ផលិតភាព​ដែល​ត្រូវ​ធ្វើ​អ្វីមួយ​រួចហើយ។

TimescaleDB ។ 80 nvps

ភារកិច្ចចម្បងរបស់ខ្ញុំគឺដើម្បីសាកល្បងសមត្ថភាពរបស់ TimescaleDB ប្រឆាំងនឹងការផ្ទុក Zabbix ។ តម្លៃ 80 ពាន់ក្នុងមួយវិនាទីគឺច្រើន, ភាពញឹកញាប់នៃការប្រមូលម៉ែត្រ (ជាការពិតណាស់, លើកលែងតែ Yandex) និង "ការរៀបចំ" ដ៏ធំមួយ។

មានការធ្លាក់ចុះនៅក្នុងក្រាហ្វនីមួយៗ - នេះគឺជាការផ្ទេរទិន្នន័យយ៉ាងជាក់លាក់។ បន្ទាប់ពីការបរាជ័យនៅក្នុងម៉ាស៊ីនមេ Zabbix ទម្រង់ផ្ទុកនៃកម្មវិធីធ្វើសមកាលកម្មប្រវត្តិបានផ្លាស់ប្តូរច្រើន - វាបានធ្លាក់ចុះបីដង។

TimescaleDB អនុញ្ញាតឱ្យអ្នកបញ្ចូលទិន្នន័យលឿនជាង 3 ដង និងប្រើ HistoryCache តិច។

ដូច្នោះហើយ អ្នកនឹងទទួលបានទិន្នន័យទាន់ពេល។

TimescaleDB ។ 120 nvps

បន្ទាប់មកខ្ញុំបានបង្កើនចំនួនធាតុទិន្នន័យដល់ 500 ពាន់ ភារកិច្ចចម្បងគឺដើម្បីសាកល្បងសមត្ថភាពរបស់ TimescaleDB - ខ្ញុំបានទទួលតម្លៃគណនា 125 ពាន់តម្លៃក្នុងមួយវិនាទី។

នេះគឺជា "ការរៀបចំ" ដែលកំពុងដំណើរការដែលអាចដំណើរការបានយូរ។ ប៉ុន្តែដោយសារថាសរបស់ខ្ញុំមានត្រឹមតែ 1,5 TB ខ្ញុំបានបំពេញវាក្នុងរយៈពេលពីរបីថ្ងៃ។

អ្វីដែលសំខាន់បំផុតនោះគឺថានៅពេលជាមួយគ្នានោះភាគថាស TimescaleDB ថ្មីត្រូវបានបង្កើត។

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

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

ការរកឃើញ

TimescaleDB គឺជាដំណោះស្រាយដ៏ល្អសម្រាប់ "ការដំឡើង" តូចដែលប៉ះពាល់ដល់ដំណើរការឌីស។ វា​នឹង​អនុញ្ញាត​ឱ្យ​អ្នក​បន្ត​ធ្វើ​ការ​បាន​ល្អ​រហូត​ដល់​មូលដ្ឋាន​ទិន្នន័យ​ត្រូវ​បាន​ផ្លាស់​ប្តូរ​ទៅ​ផ្នែក​រឹង​ឱ្យ​បាន​លឿន​តាម​ដែល​អាច​ធ្វើ​ទៅ​បាន​។

TimescaleDB មានភាពងាយស្រួលក្នុងការកំណត់ ផ្តល់នូវការបង្កើនប្រសិទ្ធភាព ដំណើរការល្អជាមួយ Zabbix និង មានគុណសម្បត្តិជាង PostgreSQL.

ប្រសិនបើអ្នកប្រើ PostgreSQL ហើយមិនមានគម្រោងផ្លាស់ប្តូរវា ខ្ញុំសូមណែនាំ ប្រើ PostgreSQL ជាមួយផ្នែកបន្ថែម TimescaleDB ដោយភ្ជាប់ជាមួយ Zabbix. ដំណោះស្រាយនេះមានប្រសិទ្ធភាពរហូតដល់ "ការរៀបចំ" មធ្យម។

នៅពេលដែលយើងនិយាយថា "ប្រសិទ្ធភាពខ្ពស់" យើងមានន័យថា ការផ្ទុកខ្ពស់ ++. អ្នក​នឹង​មិន​ចាំ​យូរ​ទេ​ដើម្បី​ស្វែងយល់​អំពី​បច្ចេកវិទ្យា និង​ការអនុវត្ត​ដែល​អាច​ឱ្យ​សេវាកម្ម​បម្រើ​អ្នកប្រើប្រាស់​រាប់លាន​នាក់​បាន។ បញ្ជី របាយការណ៍ សម្រាប់ថ្ងៃទី 7 និង 8 ខែវិច្ឆិកា យើងបានចងក្រងរួចហើយ ប៉ុន្តែនៅទីនេះ ជំនួប ច្រើនទៀតអាចត្រូវបានណែនាំ។

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

ប្រភព: www.habr.com