ປະສິດທິພາບສູງແລະການແບ່ງສ່ວນພື້ນເມືອງ: Zabbix ສະຫນັບສະຫນູນ TimescaleDB

Zabbix ແມ່ນລະບົບການຕິດຕາມ. ເຊັ່ນດຽວກັນກັບລະບົບອື່ນໆ, ມັນປະເຊີນກັບສາມບັນຫາຕົ້ນຕໍຂອງລະບົບການຕິດຕາມທັງຫມົດ: ການລວບລວມແລະການປຸງແຕ່ງຂໍ້ມູນ, ການເກັບຮັກສາປະຫວັດສາດແລະການທໍາຄວາມສະອາດມັນ.

ຂັ້ນຕອນຂອງການໄດ້ຮັບ, ການປະມວນຜົນແລະການບັນທຶກຂໍ້ມູນໃຊ້ເວລາ. ບໍ່ຫຼາຍປານໃດ, ແຕ່ສໍາລັບລະບົບຂະຫນາດໃຫຍ່ນີ້ສາມາດເຮັດໃຫ້ເກີດຄວາມລ່າຊ້າຂະຫນາດໃຫຍ່. ບັນຫາການເກັບຮັກສາແມ່ນບັນຫາການເຂົ້າເຖິງຂໍ້ມູນ. ພວກມັນຖືກນໍາໃຊ້ສໍາລັບການລາຍງານ, ການກວດສອບແລະການກະຕຸ້ນ. Latencies ໃນການເຂົ້າເຖິງຂໍ້ມູນຍັງມີຜົນກະທົບປະສິດທິພາບ. ເມື່ອຖານຂໍ້ມູນເຕີບໃຫຍ່, ຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງຕ້ອງຖືກລຶບຖິ້ມ. ການເອົາອອກແມ່ນເປັນການດໍາເນີນງານທີ່ຫຍຸ້ງຍາກທີ່ຍັງກິນຊັບພະຍາກອນບາງຢ່າງ.

ບັນຫາຂອງການຊັກຊ້າໃນລະຫວ່າງການລວບລວມແລະການເກັບຮັກສາໃນ Zabbix ຖືກແກ້ໄຂໂດຍການເກັບຂໍ້ມູນ: caches ຫຼາຍປະເພດ, caching ໃນຖານຂໍ້ມູນ. ເພື່ອແກ້ໄຂບັນຫາທີສາມ, caching ແມ່ນບໍ່ເຫມາະສົມ, ດັ່ງນັ້ນ Zabbix ໃຊ້ TimescaleDB. ລາວຈະບອກເຈົ້າກ່ຽວກັບມັນ Andrey Gushchin - ວິສະວະກອນສະຫນັບສະຫນູນດ້ານວິຊາການ Zabbix SIA. Andrey ໄດ້ສະຫນັບສະຫນູນ Zabbix ຫຼາຍກວ່າ 6 ປີແລະມີປະສົບການໂດຍກົງກັບການປະຕິບັດ.

TimescaleDB ເຮັດວຽກແນວໃດ, ມັນສາມາດໃຫ້ປະສິດທິພາບແນວໃດເມື່ອທຽບກັບ PostgreSQL ປົກກະຕິ? Zabbix ມີບົດບາດອັນໃດສໍາລັບຖານຂໍ້ມູນ TimescaleDB? ວິທີການເລີ່ມຕົ້ນຈາກຈຸດເລີ່ມຕົ້ນແລະວິທີການເຄື່ອນຍ້າຍຈາກ PostgreSQL ແລະການຕັ້ງຄ່າໃດທີ່ມີປະສິດທິພາບດີກວ່າ? ກ່ຽວກັບທັງຫມົດນີ້ພາຍໃຕ້ການຕັດ.

ສິ່ງທ້າທາຍດ້ານການຜະລິດ

ທຸກໆລະບົບການຕິດຕາມປະເຊີນກັບສິ່ງທ້າທາຍດ້ານການປະຕິບັດສະເພາະ. ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບສາມຂອງພວກເຂົາ: ການເກັບຂໍ້ມູນແລະການປຸງແຕ່ງ, ການເກັບຮັກສາ, ແລະການເກັບກູ້ປະຫວັດສາດ.

ການ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​ໄວ​ແລະ​ການ​ປຸງ​ແຕ່ງ​. ລະບົບການຕິດຕາມທີ່ດີຄວນໄດ້ຮັບຂໍ້ມູນທັງຫມົດຢ່າງໄວວາແລະດໍາເນີນການຕາມການສະແດງອອກຂອງຜົນກະທົບຕໍ່ - ຕາມເງື່ອນໄຂຂອງມັນ. ຫຼັງ​ຈາກ​ການ​ປຸງ​ແຕ່ງ​, ລະ​ບົບ​ຍັງ​ຕ້ອງ​ໄດ້​ຢ່າງ​ວ່ອງ​ໄວ​ບັນ​ທຶກ​ຂໍ້​ມູນ​ນີ້​ໃນ​ຖານ​ຂໍ້​ມູນ​ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້​ພາຍ​ຫຼັງ​.

ການເກັບຮັກສາປະຫວັດສາດ. ລະບົບການຕິດຕາມທີ່ດີຄວນເກັບຮັກສາປະຫວັດສາດຢູ່ໃນຖານຂໍ້ມູນແລະສະຫນອງການເຂົ້າເຖິງໄດ້ງ່າຍໃນການວັດແທກ. ປະຫວັດແມ່ນຈໍາເປັນເພື່ອຖືກນໍາໃຊ້ໃນບົດລາຍງານ, ກຣາຟ, ຜົນກະທົບຕໍ່, ເກນ, ແລະລາຍການຂໍ້ມູນເຕືອນທີ່ຄິດໄລ່.

ລຶບລ້າງປະຫວັດ. ບາງຄັ້ງມີມື້ຫນຶ່ງທີ່ທ່ານບໍ່ຈໍາເປັນຕ້ອງເກັບຮັກສາ metrics. ເປັນຫຍັງທ່ານຕ້ອງການຂໍ້ມູນທີ່ເກັບກໍາເມື່ອ 5 ປີທີ່ຜ່ານມາ, ເດືອນຫຼືສອງເດືອນ: ບາງ nodes ໄດ້ຖືກລຶບຖິ້ມ, ບາງ hosts ຫຼື metrics ແມ່ນບໍ່ຈໍາເປັນເພາະວ່າມັນລ້າສະໄຫມແລະບໍ່ໄດ້ເກັບກໍາອີກຕໍ່ໄປ. ລະບົບການຕິດຕາມທີ່ດີຄວນເກັບຮັກສາຂໍ້ມູນປະຫວັດສາດແລະລຶບມັນອອກເປັນແຕ່ລະຄັ້ງເພື່ອບໍ່ໃຫ້ຖານຂໍ້ມູນເຕີບໂຕ.

ການເຮັດຄວາມສະອາດຂໍ້ມູນ stale ແມ່ນບັນຫາທີ່ສໍາຄັນທີ່ມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ການປະຕິບັດຖານຂໍ້ມູນ.

ການເກັບຂໍ້ມູນໃນ Zabbix

ໃນ Zabbix, ການໂທທໍາອິດແລະທີສອງຖືກແກ້ໄຂໂດຍໃຊ້ຖານຄວາມຈໍາ. RAM ຖືກນໍາໃຊ້ເພື່ອເກັບກໍາແລະປະມວນຜົນຂໍ້ມູນ. ສໍາລັບການເກັບຮັກສາ - ປະຫວັດໃນ triggers, graphs ແລະອົງປະກອບຂໍ້ມູນການຄິດໄລ່. ໃນດ້ານຖານຂໍ້ມູນມີບາງຖານຄວາມຈໍາສໍາລັບການຄັດເລືອກພື້ນຖານ, ສໍາລັບການຍົກຕົວຢ່າງ, ກຣາຟ.

Caching ຢູ່ຂ້າງຂອງເຄື່ອງແມ່ຂ່າຍ Zabbix ຕົວຂອງມັນເອງແມ່ນ:

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

ໃຫ້ພິຈາລະນາໃຫ້ເຂົາເຈົ້າໃນລາຍລະອຽດເພີ່ມເຕີມ.

ConfigurationCache

ນີ້ແມ່ນ cache ຕົ້ນຕໍທີ່ພວກເຮົາເກັບຮັກສາ metrics, hosts, ລາຍການຂໍ້ມູນ, triggers - ທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາຕ້ອງການສໍາລັບການ PreProcessing ແລະສໍາລັບການລວບລວມຂໍ້ມູນ.

ທັງຫມົດນີ້ຖືກເກັບໄວ້ໃນ ConfigurationCache ເພື່ອບໍ່ໃຫ້ສ້າງຄໍາຖາມທີ່ບໍ່ຈໍາເປັນໃນຖານຂໍ້ມູນ. ຫຼັງຈາກເຄື່ອງແມ່ຂ່າຍເລີ່ມຕົ້ນ, ພວກເຮົາປັບປຸງ cache ນີ້, ສ້າງແລະປັບປຸງການຕັ້ງຄ່າເປັນໄລຍະ.

ການ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​

ແຜນວາດແມ່ນຂ້ອນຂ້າງໃຫຍ່, ແຕ່ສິ່ງທີ່ສໍາຄັນໃນມັນແມ່ນ ນັກສະສົມ. ເຫຼົ່ານີ້ແມ່ນ "ຜູ້ລົງຄະແນນ" ຕ່າງໆ - ຂະບວນການປະກອບ. ພວກເຂົາຮັບຜິດຊອບສໍາລັບການປະກອບປະເພດຕ່າງໆ: ພວກເຂົາເກັບກໍາຂໍ້ມູນຜ່ານ SNMP, IPMI, ແລະໂອນມັນທັງຫມົດໄປຫາ PreProcessing.

ຜູ້ສະສົມແມ່ນໄດ້ລະບຸໄວ້ເປັນສີສົ້ມ.

Zabbix ໄດ້ຄິດໄລ່ລາຍການລວມທີ່ຈໍາເປັນເພື່ອລວບລວມການກວດສອບ. ຖ້າພວກເຮົາມີພວກມັນ, ພວກເຮົາເອົາຂໍ້ມູນໃຫ້ພວກເຂົາໂດຍກົງຈາກ ValueCache.

PreProcessing HistoryCache

ຜູ້ສະສົມທັງໝົດໃຊ້ ConfigurationCache ເພື່ອຮັບວຽກ. ຫຼັງຈາກນັ້ນ, ພວກເຂົາເຈົ້າໂອນໃຫ້ເຂົາເຈົ້າກັບ PreProcessing.

PreProcessing ໃຊ້ ConfigurationCache ເພື່ອຮັບຂັ້ນຕອນ PreProcessing. ມັນປະມວນຜົນຂໍ້ມູນນີ້ດ້ວຍວິທີຕ່າງໆ.

ຫຼັງຈາກການປະມວນຜົນຂໍ້ມູນໂດຍໃຊ້ PreProcessing, ພວກເຮົາບັນທຶກມັນໄວ້ໃນ HistoryCache ສໍາລັບການປະມວນຜົນ. ນີ້ສິ້ນສຸດການເກັບກໍາຂໍ້ມູນແລະພວກເຮົາກ້າວໄປສູ່ຂະບວນການຕົ້ນຕໍໃນ Zabbix - syncer ປະ​ຫວັດ​ສາດ​, ເນື່ອງຈາກວ່າມັນເປັນຖາປັດຕະຍະ monolithic.

ຫມາຍເຫດ: PreProcessing ແມ່ນຂ້ອນຂ້າງເປັນການດໍາເນີນງານທີ່ຍາກ. ດ້ວຍ v 4.2 ມັນໄດ້ຖືກຍ້າຍໄປທີ່ຕົວແທນ. ຖ້າທ່ານມີ Zabbix ຂະຫນາດໃຫຍ່ທີ່ມີຈໍານວນຂະຫນາດໃຫຍ່ຂອງອົງປະກອບຂໍ້ມູນແລະຄວາມຖີ່ຂອງການລວບລວມ, ນີ້ເຮັດໃຫ້ການເຮັດວຽກງ່າຍຂຶ້ນຫຼາຍ.

ValueCache, ປະຫວັດ ແລະທ່າອ່ຽງ cache

History syncer ແມ່ນຂະບວນການຕົ້ນຕໍທີ່ປະລໍາມະນູປະມວນຜົນແຕ່ລະອົງປະກອບຂໍ້ມູນ, ນັ້ນແມ່ນ, ແຕ່ລະມູນຄ່າ.

History syncer ເອົາຄ່າຈາກ HistoryCache ແລະກວດສອບການຕັ້ງຄ່າສໍາລັບການປະກົດຕົວຂອງ triggers ສໍາລັບການຄິດໄລ່. ຖ້າພວກເຂົາມີ, ມັນຄິດໄລ່.

ຕົວຊິ້ງປະຫວັດສາດສ້າງເຫດການ, ການຂະຫຍາຍເພື່ອສ້າງການແຈ້ງເຕືອນຖ້າຕ້ອງການໂດຍການຕັ້ງຄ່າ, ແລະບັນທຶກ. ຖ້າມີ triggers ສໍາລັບການປຸງແຕ່ງຕໍ່ມາ, ຫຼັງຈາກນັ້ນມັນເກັບຮັກສາຄ່ານີ້ໄວ້ໃນ ValueCache ເພື່ອບໍ່ໃຫ້ເຂົ້າເຖິງຕາຕະລາງປະຫວັດສາດ. ນີ້ແມ່ນວິທີທີ່ ValueCache ເຕັມໄປດ້ວຍຂໍ້ມູນທີ່ມີຄວາມຈໍາເປັນໃນການຄິດໄລ່ triggers ແລະອົງປະກອບທີ່ຄິດໄລ່.

History syncer ຂຽນຂໍ້ມູນທັງຫມົດໃສ່ຖານຂໍ້ມູນ, ແລະມັນຂຽນໃສ່ແຜ່ນ. ຂະບວນການປຸງແຕ່ງສິ້ນສຸດລົງຢູ່ທີ່ນີ້.

ການເກັບຂໍ້ມູນໃນຖານຂໍ້ມູນ

ໃນດ້ານຖານຂໍ້ມູນມີຖານຄວາມຈໍາຕ່າງໆໃນເວລາທີ່ທ່ານຕ້ອງການເບິ່ງກາຟຫຼືບົດລາຍງານກ່ຽວກັບເຫດການ:

• Innodb_buffer_pool ໃນດ້ານ MySQL;
• shared_buffers ໃນດ້ານ PostgreSQL;
• effective_cache_size ຂ້າງ Oracle;
• shared_pool ໃນດ້ານ DB2.

ມີຫຼາຍຖານຄວາມຈໍາອື່ນໆ, ແຕ່ເຫຼົ່ານີ້ແມ່ນຕົ້ນຕໍສໍາລັບຖານຂໍ້ມູນທັງຫມົດ. ພວກເຂົາອະນຸຍາດໃຫ້ທ່ານເກັບຂໍ້ມູນໃນ RAM ທີ່ມັກຈະຕ້ອງການສໍາລັບການສອບຖາມ. ພວກເຂົາມີເຕັກໂນໂລຢີຂອງຕົນເອງສໍາລັບການນີ້.

ການປະຕິບັດຖານຂໍ້ມູນແມ່ນສໍາຄັນ

ເຊີບເວີ Zabbix ເກັບກໍາຂໍ້ມູນຢ່າງຕໍ່ເນື່ອງແລະຂຽນມັນ. ເມື່ອຣີສະຕາດ, ມັນຍັງອ່ານຈາກປະຫວັດການຕື່ມໃສ່ ValueCache. ໃຊ້ສະຄຣິບ ແລະບົດລາຍງານ Zabbix API, ເຊິ່ງຖືກສ້າງຂຶ້ນໃນການໂຕ້ຕອບເວັບ. Zabbix API ເຂົ້າເຖິງຖານຂໍ້ມູນແລະດຶງຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບກາຟ, ບົດລາຍງານ, ລາຍຊື່ເຫດການແລະບັນຫາຫຼ້າສຸດ.

ສໍາລັບການເບິ່ງເຫັນ - ກຣາຟານາ. ນີ້ແມ່ນການແກ້ໄຂທີ່ນິຍົມໃນບັນດາຜູ້ໃຊ້ຂອງພວກເຮົາ. ມັນສາມາດສົ່ງຄໍາຮ້ອງຂໍໂດຍກົງຜ່ານ Zabbix API ແລະໄປຫາຖານຂໍ້ມູນ, ແລະສ້າງການແຂ່ງຂັນທີ່ແນ່ນອນສໍາລັບການຮັບຂໍ້ມູນ. ດັ່ງນັ້ນ, ການປັບລະອຽດແລະດີຂື້ນຂອງຖານຂໍ້ມູນແມ່ນຈໍາເປັນເພື່ອໃຫ້ກົງກັບຜົນໄດ້ຮັບແລະການທົດສອບທີ່ໄວ.

Housekeeper

ສິ່ງທ້າທາຍການປະຕິບັດທີສາມໃນ Zabbix ແມ່ນການເກັບກູ້ປະຫວັດສາດໂດຍໃຊ້ Housekeeper. ມັນປະຕິບັດຕາມການຕັ້ງຄ່າທັງຫມົດ - ອົງປະກອບຂໍ້ມູນຊີ້ບອກໄລຍະເວລາທີ່ຈະເກັບຮັກສາການປ່ຽນແປງຂອງການປ່ຽນແປງ (ແນວໂນ້ມ) ໃນມື້.

ພວກເຮົາຄິດໄລ່ TrendsCache ໃນທັນທີ. ເມື່ອຂໍ້ມູນມາຮອດ, ພວກເຮົາລວບລວມມັນເປັນເວລາຫນຶ່ງຊົ່ວໂມງແລະບັນທຶກມັນຢູ່ໃນຕາຕະລາງສໍາລັບການປ່ຽນແປງຂອງແນວໂນ້ມ.

ແມ່ບ້ານເລີ່ມຕົ້ນແລະລຶບຂໍ້ມູນຈາກຖານຂໍ້ມູນໂດຍໃຊ້ "ເລືອກ" ປົກກະຕິ. ນີ້ບໍ່ແມ່ນປະສິດຕິຜົນສະ ເໝີ ໄປ, ດັ່ງທີ່ເຫັນໄດ້ຈາກຕາຕະລາງການປະຕິບັດຂອງຂະບວນການພາຍໃນ.

ເສັ້ນສະແດງສີແດງສະແດງໃຫ້ເຫັນວ່າຕົວ syncer ປະຫວັດສາດແມ່ນຄ່ອຍມີເວລາຢ່າງຕໍ່ເນື່ອງ. ເສັ້ນສະແດງສີສົ້ມຢູ່ເທິງສຸດແມ່ນ Housekeeper, ເຊິ່ງເຮັດວຽກຢ່າງຕໍ່ເນື່ອງ. ລາວລໍຖ້າຖານຂໍ້ມູນທີ່ຈະລຶບແຖວທັງຫມົດທີ່ລາວລະບຸໄວ້.

ເຈົ້າຄວນປິດການໃຊ້ງານຜູ້ຮັກສາເຮືອນຕອນໃດ? ຕົວຢ່າງ, ມີ "ID ລາຍການ" ແລະທ່ານຕ້ອງການລຶບ 5 ພັນແຖວສຸດທ້າຍພາຍໃນເວລາທີ່ແນ່ນອນ. ແນ່ນອນ, ນີ້ເກີດຂື້ນໂດຍດັດສະນີ. ແຕ່ປົກກະຕິແລ້ວຊຸດຂໍ້ມູນມີຂະຫນາດໃຫຍ່ຫຼາຍ, ແລະຖານຂໍ້ມູນຍັງອ່ານຈາກແຜ່ນແລະໃສ່ມັນເຂົ້າໄປໃນ cache. ນີ້ແມ່ນສະເຫມີໄປເປັນການດໍາເນີນງານລາຄາແພງຫຼາຍສໍາລັບຖານຂໍ້ມູນແລະ, ອີງຕາມຂະຫນາດຂອງຖານຂໍ້ມູນ, ສາມາດນໍາໄປສູ່ບັນຫາການປະຕິບັດ.

ແມ່ບ້ານແມ່ນງ່າຍທີ່ຈະປິດການໃຊ້ງານ. ໃນການໂຕ້ຕອບຂອງເວັບມີການຕັ້ງຄ່າໃນ "ການບໍລິຫານທົ່ວໄປ" ສໍາລັບຜູ້ຮັກສາເຮືອນ. ພວກເຮົາປິດການທໍາງານພາຍໃນເຮືອນສໍາລັບປະຫວັດແນວໂນ້ມພາຍໃນ ແລະມັນຈະບໍ່ຄຸ້ມຄອງມັນອີກຕໍ່ໄປ.

ຜູ້ຮັກສາເຮືອນຖືກປິດ, ເສັ້ນສະແດງໄດ້ຫຼຸດລົງ - ບັນຫາໃດທີ່ສາມາດມີໃນກໍລະນີນີ້ແລະສິ່ງທີ່ສາມາດຊ່ວຍແກ້ໄຂສິ່ງທ້າທາຍດ້ານການປະຕິບັດທີສາມ?

Partitioning — ການ​ແບ່ງ​ປັນ​ຫຼື​ການ​ແບ່ງ​ປັນ​

ໂດຍປົກກະຕິ, ການແບ່ງສ່ວນແມ່ນຖືກຕັ້ງຄ່າໃນທາງທີ່ແຕກຕ່າງກັນໃນແຕ່ລະຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງທີ່ຂ້ອຍໄດ້ລະບຸໄວ້. ແຕ່ລະຄົນມີເຕັກໂນໂລຢີຂອງຕົນເອງ, ແຕ່ມັນຄ້າຍຄືກັນໂດຍທົ່ວໄປ. ການສ້າງພາທິຊັນໃຫມ່ມັກຈະເຮັດໃຫ້ເກີດບັນຫາບາງຢ່າງ.

ໂດຍປົກກະຕິ, ການແບ່ງພາທິຊັນຖືກຕັ້ງຄ່າຂຶ້ນຢູ່ກັບ "ການຕັ້ງຄ່າ" - ຈໍານວນຂໍ້ມູນທີ່ຖືກສ້າງຂື້ນໃນມື້ຫນຶ່ງ. ຕາມກົດລະບຽບ, ການແບ່ງສ່ວນແມ່ນອອກໃນມື້ຫນຶ່ງ, ນີ້ແມ່ນຕໍາ່ສຸດທີ່. ສໍາລັບແນວໂນ້ມຂອງຊຸດໃຫມ່ - 1 ເດືອນ.

ຄ່າອາດຈະປ່ຽນແປງຖ້າ "ຕັ້ງຄ່າ" ຂະຫນາດໃຫຍ່ຫຼາຍ. ຖ້າ "ການຕັ້ງຄ່າ" ຂະຫນາດນ້ອຍແມ່ນສູງເຖິງ 5 nvps (ຄ່າໃຫມ່ຕໍ່ວິນາທີ), ຂະຫນາດກາງແມ່ນຈາກ 000 ຫາ 5, ຫຼັງຈາກນັ້ນຂະຫນາດໃຫຍ່ແມ່ນສູງກວ່າ 000 nvps. ເຫຼົ່ານີ້ແມ່ນການຕິດຕັ້ງຂະຫນາດໃຫຍ່ແລະຂະຫນາດໃຫຍ່ຫຼາຍທີ່ຕ້ອງການການຕັ້ງຄ່າຢ່າງລະມັດລະວັງຂອງຖານຂໍ້ມູນ.

ໃນການຕິດຕັ້ງຂະຫນາດໃຫຍ່ຫຼາຍ, ໄລຍະເວລາຂອງມື້ຫນຶ່ງອາດຈະບໍ່ເຫມາະສົມທີ່ສຸດ. ຂ້ອຍໄດ້ເຫັນການແບ່ງປັນ MySQL ຂອງ 40 GB ຫຼືຫຼາຍກວ່ານັ້ນຕໍ່ມື້. ນີ້ແມ່ນຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍທີ່ສາມາດເຮັດໃຫ້ເກີດບັນຫາແລະຕ້ອງການຫຼຸດລົງ.

Partitioning ໃຫ້ຫຍັງ?

ຕາຕະລາງແບ່ງສ່ວນ. ເລື້ອຍໆເຫຼົ່ານີ້ແມ່ນໄຟລ໌ແຍກຕ່າງຫາກຢູ່ໃນແຜ່ນ. ແຜນ​ການ​ສອບ​ຖາມ​ເລືອກ​ເອົາ​ການ​ແບ່ງ​ປັນ​ຫນຶ່ງ​ທີ່​ດີ​ທີ່​ສຸດ​. ປົກກະຕິແລ້ວການແບ່ງສ່ວນແມ່ນຖືກນໍາໃຊ້ໂດຍຂອບເຂດ - ນີ້ແມ່ນຄວາມຈິງສໍາລັບ Zabbix. ພວກເຮົາໃຊ້ "ເວລາ" ຢູ່ທີ່ນັ້ນ - ເວລານັບຕັ້ງແຕ່ການເລີ່ມຕົ້ນຂອງຍຸກ. ນີ້ແມ່ນຕົວເລກ ທຳ ມະດາ ສຳ ລັບພວກເຮົາ. ທ່ານກໍານົດຈຸດເລີ່ມຕົ້ນແລະຈຸດສິ້ນສຸດຂອງມື້ - ນີ້ແມ່ນການແບ່ງປັນ.

ການໂຍກຍ້າຍໄວ - DELETE. ນຶ່ງໄຟລ໌/subtable ຖືກເລືອກ, ແທນທີ່ຈະເລືອກແຖວສຳລັບການລຶບ.

ເລັ່ງການດຶງຂໍ້ມູນຢ່າງໄວວາ SELECT - ໃຊ້ຫນຶ່ງຫຼືຫຼາຍພາທິຊັນ, ແທນທີ່ຈະເປັນຕາຕະລາງທັງຫມົດ. ຖ້າທ່ານກໍາລັງເຂົ້າເຖິງຂໍ້ມູນທີ່ມີອາຍຸສອງມື້, ມັນຖືກດຶງອອກຈາກຖານຂໍ້ມູນໄວຂຶ້ນເພາະວ່າທ່ານພຽງແຕ່ຕ້ອງການໂຫລດໄຟລ໌ຫນຶ່ງເຂົ້າໄປໃນ cache ແລະສົ່ງຄືນ, ບໍ່ແມ່ນຕາຕະລາງຂະຫນາດໃຫຍ່.

ເລື້ອຍໆຖານຂໍ້ມູນຈໍານວນຫຼາຍຍັງເລັ່ງ INSERT — ແຊກໃສ່ຕາຕະລາງເດັກນ້ອຍ.

TimescaleDB

ສໍາລັບ v 4.2, ພວກເຮົາໄດ້ຫັນຄວາມສົນໃຈຂອງພວກເຮົາໄປຫາ TimescaleDB. ນີ້ແມ່ນສ່ວນຂະຫຍາຍສໍາລັບ PostgreSQL ທີ່ມີການໂຕ້ຕອບພື້ນເມືອງ. ການຂະຫຍາຍເຮັດວຽກຢ່າງມີປະສິດທິພາບກັບຂໍ້ມູນຊຸດເວລາ, ໂດຍບໍ່ມີການສູນເສຍຜົນປະໂຫຍດຂອງຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ. TimescaleDB ຍັງແບ່ງສ່ວນອັດຕະໂນມັດ.

TimescaleDB ມີແນວຄວາມຄິດ ຕາຕະລາງ hypertable (hypertable) ທີ່ທ່ານສ້າງ. ມັນປະກອບດ້ວຍ ຕ່ອນ - ການແບ່ງສ່ວນ. Chunks ແມ່ນຖືກຈັດການໂດຍອັດຕະໂນມັດ ຊິ້ນສ່ວນ hypertable ທີ່ບໍ່ມີຜົນກະທົບຕໍ່ຊິ້ນອື່ນໆ. ແຕ່ລະ chunk ມີຊ່ວງເວລາຂອງຕົນເອງ.

TimescaleDB ທຽບກັບ PostgreSQL

TimescaleDB ເຮັດວຽກຢ່າງມີປະສິດທິພາບແທ້ໆ. ຜູ້ຜະລິດຂອງສ່ວນຂະຫຍາຍອ້າງວ່າພວກເຂົາໃຊ້ວິທີການປະມວນຜົນແບບສອບຖາມທີ່ຖືກຕ້ອງກວ່າ, ໂດຍສະເພາະ inserts . ເມື່ອຂະຫນາດຂອງຊຸດຂໍ້ມູນເພີ່ມຂຶ້ນ, algorithm ຮັກສາປະສິດທິພາບຄົງທີ່.

ຫຼັງຈາກ 200 ລ້ານແຖວ, PostgreSQL ປົກກະຕິແລ້ວເລີ່ມຫຼຸດລົງຢ່າງຫຼວງຫຼາຍແລະສູນເສຍການປະຕິບັດເປັນ 0. TimescaleDB ຊ່ວຍໃຫ້ທ່ານສາມາດໃສ່ "inserts" ໄດ້ຢ່າງມີປະສິດທິພາບສໍາລັບຂໍ້ມູນໃດໆ.

ການຕັ້ງຄ່າ

ການຕິດຕັ້ງ 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 — ໄລ​ຍະ​ຫ່າງ​ຂອງ chunks ການ​ແບ່ງ​ປັນ​ທີ່​ຈະ​ນໍາ​ໃຊ້​. ໃນກໍລະນີຂອງຂ້ອຍ, ໄລຍະຫ່າງແມ່ນມື້ຫນຶ່ງ - 86.

ຕົວ​ກໍາ​ນົດ​ການ​ທີ​ສາມ - migrate_data. ຖ້າເຈົ້າຕັ້ງ true, ຫຼັງຈາກນັ້ນ, ຂໍ້ມູນປະຈຸບັນທັງຫມົດຈະຖືກໂອນໄປຫາ chunks ທີ່ສ້າງຂຶ້ນກ່ອນ. ຂ້ອຍໃຊ້ມັນເອງ migrate_data. ຂ້ອຍມີປະມານ 1 TB, ເຊິ່ງໃຊ້ເວລາຫຼາຍກວ່າຫນຶ່ງຊົ່ວໂມງ. ເຖິງແມ່ນວ່າໃນບາງກໍລະນີ, ໃນລະຫວ່າງການທົດສອບ, ຂ້າພະເຈົ້າໄດ້ລຶບຂໍ້ມູນປະຫວັດສາດຂອງປະເພດຕົວອັກສອນທີ່ບໍ່ຈໍາເປັນສໍາລັບການເກັບຮັກສາ, ເພື່ອບໍ່ໃຫ້ໂອນພວກມັນ.

ຂັ້ນ​ຕອນ​ສຸດ​ທ້າຍ - UPDATE: ໃນ db_extension ໃສ່ timescaledbເພື່ອໃຫ້ຖານຂໍ້ມູນເຂົ້າໃຈວ່າສ່ວນຂະຫຍາຍນີ້ມີຢູ່. Zabbix ເປີດໃຊ້ມັນແລະໃຊ້ syntax ແລະການສອບຖາມຢ່າງຖືກຕ້ອງກັບຖານຂໍ້ມູນ - ລັກສະນະເຫຼົ່ານັ້ນທີ່ຈໍາເປັນສໍາລັບ TimescaleDB.

ການຕັ້ງຄ່າຮາດແວ

ຂ້ອຍໃຊ້ສອງເຄື່ອງແມ່ຂ່າຍ. ຫນ້າທໍາອິດ - ເຄື່ອງ VMware. ມັນຂ້ອນຂ້າງນ້ອຍ: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz processors, 16 GB ຂອງ RAM ແລະ 200 GB SSD.

ຂ້ອຍຕິດຕັ້ງ PostgreSQL 10.8 ໃສ່ມັນດ້ວຍ Debian 10.8-1.pgdg90+1 OS ແລະລະບົບໄຟລ໌ xfs. ຂ້ອຍຕັ້ງຄ່າທຸກຢ່າງໃຫ້ໜ້ອຍທີ່ສຸດເພື່ອໃຊ້ຖານຂໍ້ມູນສະເພາະນີ້, ລົບສິ່ງທີ່ Zabbix ຕົວມັນເອງຈະໃຊ້.

ໃນເຄື່ອງດຽວກັນມີເຄື່ອງແມ່ຂ່າຍ Zabbix, PostgreSQL ແລະ ຕົວແທນການໂຫຼດ. ຂ້ອຍມີ 50 ຕົວແທນທີ່ໃຊ້ວຽກທີ່ກໍາລັງໃຊ້ LoadableModuleເພື່ອສ້າງຜົນໄດ້ຮັບທີ່ແຕກຕ່າງກັນຢ່າງໄວວາ: ຕົວເລກ, ສະຕຣິງ. ຂ້າພະເຈົ້າໄດ້ຕື່ມຂໍ້ມູນໃສ່ຖານຂໍ້ມູນຫຼາຍ.

ໃນເບື້ອງຕົ້ນ, ການຕັ້ງຄ່າປະກອບດ້ວຍ 5 ອົງ​ປະ​ກອບ​ ຂໍ້ມູນຕໍ່ເຈົ້າພາບ. ເກືອບທຸກອົງປະກອບມີຕົວກະຕຸ້ນເພື່ອເຮັດໃຫ້ມັນຄ້າຍຄືກັບການຕິດຕັ້ງທີ່ແທ້ຈິງ. ໃນບາງກໍລະນີມີຫຼາຍກ່ວາຫນຶ່ງຜົນກະທົບຕໍ່. ສໍາລັບຫນຶ່ງ node ເຄືອຂ່າຍມີ 3-000 ບາດ.

ໄລຍະຫ່າງການປັບປຸງລາຍການຂໍ້ມູນ − 4-7 ວິນາທີ. ຂ້າພະເຈົ້າໄດ້ຄວບຄຸມການໂຫຼດຂອງມັນເອງໂດຍການນໍາໃຊ້ບໍ່ພຽງແຕ່ 50 ຕົວແທນ, ແຕ່ຍັງເພີ່ມຕື່ມອີກ. ນອກຈາກນັ້ນ, ການນໍາໃຊ້ອົງປະກອບຂໍ້ມູນ, ຂ້າພະເຈົ້າໄດ້ປັບການໂຫຼດແບບໄດນາມິກແລະຫຼຸດລົງໄລຍະການປັບປຸງເປັນ 4 s.

PostgreSQL. 35 nvps

ຄັ້ງທໍາອິດຂອງຂ້ອຍໃນຮາດແວນີ້ແມ່ນຢູ່ໃນ PostgreSQL ບໍລິສຸດ - 35 ພັນຄ່າຕໍ່ວິນາທີ. ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ການໃສ່ຂໍ້ມູນໃຊ້ເວລາສ່ວນຫນຶ່ງຂອງວິນາທີ - ທຸກສິ່ງທຸກຢ່າງແມ່ນດີແລະໄວ. ສິ່ງດຽວແມ່ນວ່າແຜ່ນ SSD 200 GB ເຕັມໄວ.

ນີ້ແມ່ນແຜງໜ້າປັດປະສິດທິພາບຂອງເຊີບເວີ Zabbix ມາດຕະຖານ.

ເສັ້ນສະແດງສີຟ້າທໍາອິດແມ່ນຈໍານວນຄ່າຕໍ່ວິນາທີ. ເສັ້ນສະແດງທີສອງຢູ່ເບື້ອງຂວາແມ່ນການໂຫຼດຂະບວນການກໍ່ສ້າງ. ອັນທີສາມແມ່ນການໂຫຼດຂະບວນການສ້າງພາຍໃນ: syncers ປະຫວັດສາດແລະ Housekeeper, ເຊິ່ງໄດ້ແລ່ນຢູ່ທີ່ນີ້ສໍາລັບເວລາໃດຫນຶ່ງ.

ເສັ້ນສະແດງທີສີ່ສະແດງໃຫ້ເຫັນການນໍາໃຊ້ HistoryCache. ນີ້ແມ່ນປະເພດຂອງ buffer ກ່ອນທີ່ຈະໃສ່ເຂົ້າໄປໃນຖານຂໍ້ມູນ. ເສັ້ນສະແດງທີຫ້າສີຂຽວສະແດງໃຫ້ເຫັນການນໍາໃຊ້ ValueCache, ນັ້ນແມ່ນ, ຈໍານວນ ValueCache hits ສໍາລັບ triggers - ນີ້ແມ່ນຫຼາຍພັນຄ່າຕໍ່ວິນາທີ.

PostgreSQL. 50 nvps

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເພີ່ມການໂຫຼດເຖິງ 50 ພັນຄ່າຕໍ່ວິນາທີໃນຮາດແວດຽວກັນ.

ເມື່ອໂຫລດຈາກ Housekeeper, ໃສ່ 10 ພັນຄ່າໃຊ້ເວລາ 2-3 ວິນາທີ.

ແມ່ບ້ານເລີ່ມແຊກແຊງວຽກແລ້ວ.

ຕາຕະລາງທີສາມສະແດງໃຫ້ເຫັນວ່າ, ໂດຍທົ່ວໄປ, ການໂຫຼດຂອງ trappers ແລະ synchers ປະຫວັດສາດແມ່ນຍັງຢູ່ທີ່ 60%. ໃນເສັ້ນສະແດງທີສີ່, HistoryCache ກໍາລັງເລີ່ມຕົ້ນທີ່ຈະຕື່ມຂໍ້ມູນຢ່າງຈິງຈັງໃນລະຫວ່າງການປະຕິບັດງານຂອງ Housekeeper. ມັນແມ່ນ 20% ເຕັມ, ເຊິ່ງປະມານ 0,5 GB.

PostgreSQL. 80 nvps

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເພີ່ມການໂຫຼດເຖິງ 80 ພັນຄ່າຕໍ່ວິນາທີ. ນີ້ແມ່ນປະມານ 400 ພັນອົງປະກອບຂໍ້ມູນແລະ 280 ພັນ triggers.

ຄ່າໃຊ້ຈ່າຍໃນການໂຫຼດຂອງສາມສິບ synchers ປະຫວັດສາດແມ່ນຂ້ອນຂ້າງສູງແລ້ວ.

ຂ້ອຍຍັງໄດ້ເພີ່ມຕົວກໍານົດການຕ່າງໆ: syncers ປະຫວັດສາດ, cache.

ໃນຮາດແວຂອງຂ້ອຍ, ການໂຫຼດຂອງ syncers ປະຫວັດສາດເພີ່ມຂຶ້ນເຖິງສູງສຸດ. HistoryCache ເຕັມໄປດ້ວຍຂໍ້ມູນຢ່າງໄວວາ - ຂໍ້ມູນສໍາລັບການປຸງແຕ່ງໄດ້ສະສົມຢູ່ໃນ buffer.

ຕະຫຼອດເວລານີ້ຂ້າພະເຈົ້າໄດ້ສັງເກດເຫັນວິທີການໃຊ້ໂປເຊດເຊີ, RAM ແລະຕົວກໍານົດການລະບົບອື່ນໆ, ແລະພົບວ່າການນໍາໃຊ້ແຜ່ນແມ່ນສູງສຸດ.

ຂ້າພະເຈົ້າໄດ້ບັນລຸການນໍາໃຊ້ ຄວາມສາມາດຂອງແຜ່ນສູງສຸດ ໃນຮາດແວນີ້ແລະໃນເຄື່ອງ virtual ນີ້. ດ້ວຍຄວາມເຂັ້ມຂົ້ນດັ່ງກ່າວ, PostgreSQL ໄດ້ເລີ່ມຕົ້ນທີ່ຈະລ້າງຂໍ້ມູນຢ່າງຫ້າວຫັນ, ແລະແຜ່ນບໍ່ມີເວລາຂຽນແລະອ່ານອີກຕໍ່ໄປ.

ເຄື່ອງແມ່ຂ່າຍທີສອງ

ຂ້ອຍເອົາເຄື່ອງແມ່ຂ່າຍອື່ນ, ເຊິ່ງມີໂປເຊດເຊີ 48 ແລະ 128 GB ຂອງ RAM ແລ້ວ. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ປັບ​ມັນ - ຕັ້ງ​ມັນ​ເປັນ 60 syncer ປະ​ຫວັດ​ສາດ​, ແລະ​ບັນ​ລຸ​ການ​ປະ​ຕິ​ບັດ​ທີ່​ຍອມ​ຮັບ​ໄດ້​.

ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນຂອບເຂດຈໍາກັດຂອງຜົນຜະລິດທີ່ບາງສິ່ງບາງຢ່າງຕ້ອງເຮັດ.

TimescaleDB. 80 nvps

ຫນ້າທີ່ຕົ້ນຕໍຂອງຂ້ອຍແມ່ນການທົດສອບຄວາມສາມາດຂອງ TimescaleDB ຕໍ່ກັບການໂຫຼດ Zabbix. 80 ພັນມູນຄ່າຕໍ່ວິນາທີແມ່ນຫຼາຍ, ຄວາມຖີ່ຂອງການເກັບກໍາ metrics (ຍົກເວັ້ນ Yandex, ແນ່ນອນ) ແລະ "ການຕັ້ງຄ່າ" ຂະຫນາດໃຫຍ່ພໍສົມຄວນ.

ມີການຫຼຸດລົງໃນທຸກໆເສັ້ນສະແດງ - ນີ້ແມ່ນການເຄື່ອນຍ້າຍຂໍ້ມູນຢ່າງແນ່ນອນ. ຫຼັງຈາກຄວາມລົ້ມເຫລວໃນເຄື່ອງແມ່ຂ່າຍ Zabbix, ຂໍ້ມູນການໂຫຼດຂອງ syncer ປະຫວັດສາດໄດ້ປ່ຽນແປງຫຼາຍ - ມັນຫຼຸດລົງສາມຄັ້ງ.

TimescaleDB ຊ່ວຍໃຫ້ທ່ານສາມາດໃສ່ຂໍ້ມູນໄດ້ໄວຂຶ້ນເກືອບ 3 ເທົ່າ ແລະໃຊ້ HistoryCache ໜ້ອຍລົງ.

ດັ່ງນັ້ນ, ທ່ານຈະໄດ້ຮັບຂໍ້ມູນຢ່າງທັນເວລາ.

TimescaleDB. 120 nvps

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເພີ່ມຈໍານວນອົງປະກອບຂໍ້ມູນເປັນ 500 ພັນ. ວຽກງານຕົ້ນຕໍແມ່ນການທົດສອບຄວາມສາມາດຂອງ TimescaleDB - ຂ້ອຍໄດ້ຮັບມູນຄ່າການຄິດໄລ່ຂອງ 125 ພັນມູນຄ່າຕໍ່ວິນາທີ.

ນີ້ແມ່ນ "ການຕັ້ງຄ່າ" ທີ່ເຮັດວຽກທີ່ສາມາດເຮັດວຽກໄດ້ເປັນເວລາດົນນານ. ແຕ່ເນື່ອງຈາກແຜ່ນຂອງຂ້ອຍມີພຽງແຕ່ 1,5 TB, ຂ້ອຍໄດ້ເຕີມເຕັມມັນໃນສອງສາມມື້.

ສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນວ່າໃນເວລາດຽວກັນ TimescaleDB partitions ໃຫມ່ໄດ້ຖືກສ້າງຂື້ນ.

ນີ້ແມ່ນ unnoticeable ຢ່າງສົມບູນສໍາລັບການປະຕິບັດ. ເມື່ອການແບ່ງສ່ວນຖືກສ້າງຂື້ນໃນ MySQL, ຕົວຢ່າງ, ທຸກສິ່ງທຸກຢ່າງແມ່ນແຕກຕ່າງກັນ. ນີ້ມັກຈະເກີດຂຶ້ນໃນຕອນກາງຄືນເນື່ອງຈາກວ່າມັນສະກັດກັ້ນການແຊກທົ່ວໄປ, ເຮັດວຽກກັບຕາຕະລາງແລະສາມາດສ້າງຄວາມເສື່ອມເສຍຂອງການບໍລິການ. ນີ້ບໍ່ແມ່ນກໍລະນີກັບ TimescaleDB.

ເປັນຕົວຢ່າງ, ຂ້ອຍຈະສະແດງເສັ້ນສະແດງຫນຶ່ງຈາກຫຼາຍໆຄົນໃນຊຸມຊົນ. ໃນຮູບ, TimescaleDB ຖືກເປີດໃຊ້, ຍ້ອນການໂຫຼດທີ່ໃຊ້ io.weight ໃນໂປເຊດເຊີໄດ້ຫຼຸດລົງ. ການນໍາໃຊ້ອົງປະກອບຂະບວນການພາຍໃນຍັງຫຼຸດລົງ. ຍິ່ງໄປກວ່ານັ້ນ, ນີ້ແມ່ນເຄື່ອງ virtual ທໍາມະດາໃນແຜ່ນ pancake ທໍາມະດາ, ບໍ່ແມ່ນ SSD.

ການຄົ້ນພົບ

TimescaleDB ເປັນການແກ້ໄຂທີ່ດີສໍາລັບ "ການຕິດຕັ້ງ" ຂະຫນາດນ້ອຍ., ເຊິ່ງມີຜົນກະທົບປະສິດທິພາບຂອງແຜ່ນ. ມັນຈະຊ່ວຍໃຫ້ທ່ານສາມາດສືບຕໍ່ເຮັດວຽກໄດ້ດີຈົນກ່ວາຖານຂໍ້ມູນຈະຖືກໂອນໄປຫາຮາດແວໄວເທົ່າທີ່ຈະໄວໄດ້.

TimescaleDB ແມ່ນງ່າຍທີ່ຈະກໍາຫນົດຄ່າ, ເຮັດໃຫ້ປະສິດທິພາບປະສິດທິພາບ, ເຮັດວຽກໄດ້ດີກັບ Zabbix ແລະ ມີຂໍ້ດີຫຼາຍກວ່າ PostgreSQL.

ຖ້າທ່ານໃຊ້ PostgreSQL ແລະບໍ່ໄດ້ວາງແຜນທີ່ຈະປ່ຽນມັນ, ຂ້ອຍຂໍແນະນໍາ ໃຊ້ PostgreSQL ດ້ວຍການຂະຫຍາຍ TimescaleDB ໂດຍສົມທົບກັບ Zabbix. ການ​ແກ້​ໄຂ​ນີ້​ເຮັດ​ວຽກ​ໄດ້​ປະ​ສິດ​ທິ​ຜົນ​ເຖິງ​ຂະ​ຫນາດ​ກາງ "ການ​ຕັ້ງ​ຄ່າ​"​.

ເມື່ອພວກເຮົາເວົ້າວ່າ "ປະສິດທິພາບສູງ" ພວກເຮົາຫມາຍຄວາມວ່າ ໂຫຼດສູງ ++. ທ່ານຈະບໍ່ຕ້ອງລໍຖ້າດົນເພື່ອຮຽນຮູ້ກ່ຽວກັບເທັກໂນໂລຍີ ແລະການປະຕິບັດທີ່ຊ່ວຍໃຫ້ການບໍລິການຮັບໃຊ້ຜູ້ໃຊ້ຫຼາຍລ້ານຄົນ. ລາຍການ ບົດລາຍງານ ສໍາລັບເດືອນພະຈິກ 7 ແລະ 8 ພວກເຮົາໄດ້ລວບລວມແລ້ວ, ແຕ່ຢູ່ທີ່ນີ້ ການ​ພົບ​ປະ​ ເພີ່ມເຕີມສາມາດແນະນໍາ.

ຈອງຂອງພວກເຮົາ ассылку и telegram, ໃນທີ່ພວກເຮົາເປີດເຜີຍລັກສະນະຂອງກອງປະຊຸມທີ່ຈະມາເຖິງ, ແລະຊອກຫາວິທີທີ່ຈະໄດ້ຮັບຜົນປະໂຫຍດສູງສຸດຈາກມັນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com