HighLoad++, Andrey Gushchin (Zabbix): ປະສິດທິພາບສູງ ແລະການແບ່ງປັນພື້ນເມືອງ

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

HighLoad++ Siberia 2019. Tomsk Hall. ວັນທີ 24 ມິຖຸນາ, 16:00 ໂມງ. ເຫຼົ່າ​ນີ້​ແລະ​ ການ ນຳ ສະ ເໜີ. ກອງປະຊຸມ HighLoad++ ຕໍ່ໄປຈະຈັດຂຶ້ນໃນວັນທີ 6 ແລະ 7 ເມສາ 2020 ທີ່ St. ລາຍລະອຽດ ແລະປີ້ ການເຊື່ອມຕໍ່.

Andrey Gushchin (ຕໍ່​ໄປ​ນີ້ – AG): – ຂ້າ​ພະ​ເຈົ້າ​ເປັນ​ວິ​ສະ​ວະ​ກອນ​ສະ​ຫນັບ​ສະ​ຫນູນ​ດ້ານ​ວິ​ຊາ​ການ ZABBIX (ຕໍ່​ໄປ​ນີ້​ເອີ້ນ​ວ່າ “Zabbix”), ຄູ​ຝຶກ. ຂ້າພະເຈົ້າໄດ້ເຮັດວຽກໃນການສະຫນັບສະຫນູນດ້ານວິຊາການຫຼາຍກວ່າ 6 ປີແລະມີປະສົບການໂດຍກົງກັບການປະຕິບັດ. ມື້ນີ້ຂ້ອຍຈະເວົ້າກ່ຽວກັບການປະຕິບັດທີ່ TimescaleDB ສາມາດສະຫນອງໄດ້ເມື່ອປຽບທຽບກັບ PostgreSQL 10 ປົກກະຕິ. ນອກຈາກນັ້ນ, ບາງສ່ວນແນະນໍາກ່ຽວກັບວິທີເຮັດວຽກໂດຍທົ່ວໄປ.

ສິ່ງທ້າທາຍດ້ານການຜະລິດສູງສຸດ: ຈາກການລວບລວມຂໍ້ມູນຈົນເຖິງການເຮັດຄວາມສະອາດຂໍ້ມູນ

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

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

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

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

ວິ​ທີ​ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ຖານ​ຄວາມ​ຈໍາ​?

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

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

ນອກຈາກນີ້ໃນດ້ານຖານຂໍ້ມູນມີບາງຖານຄວາມຈໍາສໍາລັບການຄັດເລືອກຕົ້ນຕໍ - ສໍາລັບກາຟແລະສິ່ງອື່ນໆ.

Caching ຢູ່ຂ້າງຂອງເຄື່ອງແມ່ຂ່າຍ Zabbix ຕົວຂອງມັນເອງ: ພວກເຮົາມີ ConfigurationCache, ValueCache, HistoryCache, TrendsCache. ມັນ​ແມ່ນ​ຫຍັງ?

ConfigurationCache ແມ່ນ cache ຕົ້ນຕໍທີ່ພວກເຮົາເກັບຮັກສາ metrics, hosts, data items, triggers; ທຸກຢ່າງທີ່ທ່ານຕ້ອງການເພື່ອປະມວນຜົນການປະມວນຜົນກ່ອນ, ເກັບກໍາຂໍ້ມູນ, ຈາກເຈົ້າພາບທີ່ຈະເກັບກໍາ, ມີຄວາມຖີ່ອັນໃດ. ທັງຫມົດນີ້ຖືກເກັບໄວ້ໃນ ConfigurationCache ເພື່ອບໍ່ໃຫ້ໄປຫາຖານຂໍ້ມູນແລະສ້າງຄໍາຖາມທີ່ບໍ່ຈໍາເປັນ. ຫຼັງຈາກເຄື່ອງແມ່ຂ່າຍເລີ່ມຕົ້ນ, ພວກເຮົາປັບປຸງ cache ນີ້ (ສ້າງມັນ) ແລະປັບປຸງມັນແຕ່ລະໄລຍະ (ຂຶ້ນກັບການຕັ້ງຄ່າການຕັ້ງຄ່າ).

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

ທີ່ນີ້ແຜນວາດແມ່ນຂ້ອນຂ້າງໃຫຍ່:

ຕົ້ນຕໍໃນໂຄງການແມ່ນຜູ້ເກັບເຫຼົ່ານີ້:

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

PreProcessing HistoryCache

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

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

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

ການເຮັດວຽກຂອງ syncer ປະຫວັດສາດ

ຂະບວນການຕົ້ນຕໍໃນ Zabbix (ນັບຕັ້ງແຕ່ມັນເປັນສະຖາປັດຕະຍະກໍາ monolithic) ແມ່ນ syncer ປະຫວັດສາດ. ນີ້ແມ່ນຂະບວນການຕົ້ນຕໍທີ່ປະຕິບັດໂດຍສະເພາະກັບການປະມວນຜົນປະລໍາມະນູຂອງແຕ່ລະອົງປະກອບຂໍ້ມູນ, ນັ້ນແມ່ນ, ແຕ່ລະມູນຄ່າ:

• ມູນຄ່າມາ (ມັນໃຊ້ເວລາຈາກ HistoryCache);
• ກວດເບິ່ງໃນ Configuration syncer: ບໍ່ວ່າຈະມີ triggers ສໍາລັບການຄິດໄລ່ - ຄິດໄລ່ໃຫ້ເຂົາເຈົ້າ;
  ຖ້າມີ - ສ້າງເຫດການ, ສ້າງ escalation ເພື່ອສ້າງການແຈ້ງເຕືອນ, ຖ້າຈໍາເປັນຕາມການຕັ້ງຄ່າ;
• ບັນທຶກຜົນກະທົບຕໍ່ການປຸງແຕ່ງຕໍ່ມາ, ການລວບລວມ; ຖ້າທ່ານລວບລວມໃນຊົ່ວໂມງທີ່ຜ່ານມາແລະອື່ນໆ, ຄ່ານີ້ຈະຖືກຈົດຈໍາໂດຍ ValueCache ເພື່ອບໍ່ໃຫ້ໄປຫາຕາຕະລາງປະຫວັດສາດ; ດັ່ງນັ້ນ, ValueCache ເຕັມໄປດ້ວຍຂໍ້ມູນທີ່ຈໍາເປັນທີ່ຈໍາເປັນເພື່ອຄິດໄລ່ triggers, ອົງປະກອບທີ່ຄິດໄລ່, ແລະອື່ນໆ;
• ຫຼັງຈາກນັ້ນ, History syncer ຂຽນຂໍ້ມູນທັງຫມົດໃສ່ຖານຂໍ້ມູນ;
• ຖານຂໍ້ມູນຂຽນພວກມັນໃສ່ແຜ່ນ - ນີ້ແມ່ນບ່ອນທີ່ຂະບວນການປຸງແຕ່ງສິ້ນສຸດລົງ.

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

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

ສໍາລັບ MySQL ມີ Innodb_buffer_pool, ແລະຊໍ່ຂອງຖານຄວາມຈໍາທີ່ແຕກຕ່າງກັນທີ່ສາມາດກໍາຫນົດຄ່າໄດ້.
ແຕ່ເຫຼົ່ານີ້ແມ່ນຕົ້ນຕໍ:

• shared_buffers;
• effective_cache_size;
• shared_pool.

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

ກ່ຽວກັບການປະຕິບັດຖານຂໍ້ມູນ

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

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

ລຶບລ້າງປະຫວັດ. Zabbix ມີ Housekeeper

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

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

ວິທີການເຂົ້າໃຈວ່າມັນບໍ່ມີປະສິດທິພາບ? ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ຮູບ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ໃນ​ເສັ້ນ​ສະ​ແດງ​ການ​ປະ​ຕິ​ບັດ​ຂອງ​ຂະ​ບວນ​ການ​ພາຍ​ໃນ​:

ຕົວຊິ້ງປະຫວັດຂອງທ່ານບໍ່ຫວ່າງຢູ່ສະເໝີ (ເສັ້ນສະແດງສີແດງ). ແລະເສັ້ນສະແດງ "ສີແດງ" ທີ່ຢູ່ເທິງສຸດ. ນີ້ແມ່ນ "ຜູ້ຮັກສາເຮືອນ" ທີ່ເລີ່ມຕົ້ນແລະລໍຖ້າຖານຂໍ້ມູນທີ່ຈະລຶບແຖວທັງຫມົດທີ່ມັນໄດ້ລະບຸໄວ້.

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

ທ່ານສາມາດປິດການທໍາງານ Housekeeper ໃນວິທີທີ່ງ່າຍດາຍ - ພວກເຮົາມີການໂຕ້ຕອບເວັບໄຊຕ໌ທີ່ຄຸ້ນເຄີຍ. ການຕັ້ງຄ່າໃນການບໍລິຫານທົ່ວໄປ (ການຕັ້ງຄ່າສໍາລັບ "ຜູ້ຮັກສາເຮືອນ") ພວກເຮົາປິດການທໍາຄວາມສະອາດພາຍໃນສໍາລັບປະຫວັດສາດພາຍໃນແລະແນວໂນ້ມ. ຕາມ​ນັ້ນ​ແລ້ວ, Housekeeper ບໍ່​ໄດ້​ຄວບ​ຄຸມ​ສິ່ງ​ນີ້​ອີກ​ຕໍ່​ໄປ:

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

ການແບ່ງສ່ວນ (ການແບ່ງສ່ວນ)

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

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

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

ໃນການຕິດຕັ້ງຂະຫນາດໃຫຍ່ຫຼາຍ, 1 ມື້ອາດຈະບໍ່ດີທີ່ສຸດ. ຂ້າພະເຈົ້າສ່ວນບຸກຄົນໄດ້ເຫັນການແບ່ງສ່ວນໃນ MySQL ຂອງ 40 gigabytes ຕໍ່ມື້ (ແລະອາດຈະມີຫຼາຍກວ່ານັ້ນ). ນີ້ແມ່ນຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍ, ເຊິ່ງສາມາດນໍາໄປສູ່ບັນຫາບາງຢ່າງ. ມັນຈໍາເປັນຕ້ອງໄດ້ຫຼຸດລົງ.

ເປັນຫຍັງທ່ານຕ້ອງການແບ່ງສ່ວນ?

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

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

ຖານຂໍ້ມູນຈໍານວນຫຼາຍຍັງເລັ່ງການໃສ່ (ແຊກເຂົ້າໃນຕາຕະລາງເດັກນ້ອຍຫນຶ່ງ). ຕອນນີ້ຂ້ອຍເວົ້າແບບບໍ່ມີຕົວຕົນ, ແຕ່ນີ້ກໍ່ເປັນໄປໄດ້. ການແບ່ງສ່ວນມັກຈະຊ່ວຍໄດ້.

Elasticsearch ສໍາລັບ NoSQL

ບໍ່ດົນມານີ້, ໃນ 3.4, ພວກເຮົາໄດ້ປະຕິບັດການແກ້ໄຂ NoSQL. ເພີ່ມຄວາມສາມາດໃນການຂຽນໃນ Elasticsearch. ທ່ານສາມາດຂຽນບາງປະເພດ: ທ່ານເລືອກ - ບໍ່ວ່າຈະຂຽນຕົວເລກຫຼືບາງເຄື່ອງຫມາຍ; ພວກ​ເຮົາ​ມີ​ຂໍ້​ຄວາມ​ສະ​ຕ​ຣິງ​, ທ່ານ​ສາ​ມາດ​ຂຽນ​ບັນ​ທຶກ​ການ Elasticsearch ... ດັ່ງ​ນັ້ນ​, ການ​ໂຕ້​ຕອບ​ຂອງ​ເວັບ​ໄຊ​ຕ​໌​ຍັງ​ຈະ​ເຂົ້າ​ເຖິງ Elasticsearch​. ນີ້ເຮັດວຽກໄດ້ດີໃນບາງກໍລະນີ, ແຕ່ໃນເວລານີ້ມັນສາມາດນໍາໃຊ້ໄດ້.

TimescaleDB. Hypertables

ສໍາລັບ 4.4.2 ພວກເຮົາໄດ້ເອົາໃຈໃສ່ກັບສິ່ງຫນຶ່ງເຊັ່ນ TimescaleDB. ມັນ​ແມ່ນ​ຫຍັງ? ນີ້ແມ່ນສ່ວນຂະຫຍາຍສໍາລັບ PostgreSQL, ນັ້ນແມ່ນ, ມັນມີການໂຕ້ຕອບ PostgreSQL ພື້ນເມືອງ. ນອກຈາກນັ້ນ, ການຂະຫຍາຍນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດເຮັດວຽກໄດ້ຫຼາຍປະສິດທິພາບກັບຂໍ້ມູນ timeeries ແລະມີການແບ່ງປັນອັດຕະໂນມັດ. ມັນເບິ່ງຄືວ່າ:

ນີ້ແມ່ນ hypertable - ມີແນວຄວາມຄິດດັ່ງກ່າວໃນ Timescale. ນີ້ແມ່ນ hypertable ທີ່ທ່ານສ້າງ, ແລະມັນມີ chunks. Chunks ແມ່ນ partitions, ເຫຼົ່ານີ້ແມ່ນຕາຕະລາງເດັກນ້ອຍ, ຖ້າຂ້ອຍບໍ່ຜິດ. ມັນມີປະສິດທິພາບແທ້ໆ.

TimescaleDB ແລະ PostgreSQL

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

ວິທີການຕິດຕັ້ງ TimescaleDB? ມັນງ່າຍດາຍ!

ມັນຢູ່ໃນເອກະສານ, ມັນຖືກອະທິບາຍ - ທ່ານສາມາດຕິດຕັ້ງມັນໄດ້ຈາກແພັກເກັດຕ່າງໆ ... ມັນຂຶ້ນກັບແພັກເກດ Postgres ຢ່າງເປັນທາງການ. ສາມາດລວບລວມດ້ວຍຕົນເອງ. ມັນເກີດຂຶ້ນດັ່ງນັ້ນຂ້າພະເຈົ້າຕ້ອງລວບລວມສໍາລັບຖານຂໍ້ມູນ.

ໃນ Zabbix ພວກເຮົາພຽງແຕ່ເປີດໃຊ້ Extention. ຂ້າພະເຈົ້າຄິດວ່າຜູ້ທີ່ໃຊ້ Extention ໃນ Postgres ... ທ່ານພຽງແຕ່ເປີດໃຊ້ Extention, ສ້າງມັນສໍາລັບຖານຂໍ້ມູນ Zabbix ທີ່ທ່ານກໍາລັງໃຊ້.

ແລະຂັ້ນຕອນສຸດທ້າຍ ...

TimescaleDB. ການເຄື່ອນຍ້າຍຂອງຕາຕະລາງປະຫວັດສາດ

ທ່ານຈໍາເປັນຕ້ອງສ້າງ hypertable. ມີຫນ້າທີ່ພິເສດສໍາລັບການນີ້ - ສ້າງ hypertable. ໃນມັນ, ຕົວກໍານົດການທໍາອິດແມ່ນຕາຕະລາງທີ່ຈໍາເປັນໃນຖານຂໍ້ມູນນີ້ (ສໍາລັບການທີ່ທ່ານຈໍາເປັນຕ້ອງສ້າງ hypertable).

ຊ່ອງຂໍ້ມູນທີ່ຈະສ້າງ, ແລະ chunk_time_interval (ນີ້ແມ່ນໄລຍະຫ່າງຂອງ chunks (ສ່ວນທີ່ຈໍາເປັນຕ້ອງໃຊ້). 86 ແມ່ນມື້ຫນຶ່ງ.

ພາຣາມິເຕີ migrate_data: ຖ້າທ່ານວາງເປັນ true, ນີ້ຈະໂອນຂໍ້ມູນປັດຈຸບັນທັງໝົດໄປໃສ່ຊຸດທີ່ສ້າງຂຶ້ນກ່ອນ.

ຂ້ອຍໄດ້ໃຊ້ migrate_data ຕົວເອງ - ມັນໃຊ້ເວລາພໍສົມຄວນ, ຂຶ້ນກັບວ່າຖານຂໍ້ມູນຂອງເຈົ້າໃຫຍ່ເທົ່າໃດ. ຂ້ອຍມີຫຼາຍກວ່າ terabyte - ມັນໃຊ້ເວລາຫຼາຍກວ່າຫນຶ່ງຊົ່ວໂມງເພື່ອສ້າງ. ໃນບາງກໍລະນີ, ໃນລະຫວ່າງການທົດສອບ, ຂ້າພະເຈົ້າໄດ້ລຶບຂໍ້ມູນປະຫວັດສາດສໍາລັບຂໍ້ຄວາມ (history_text) ແລະ string (history_str) ເພື່ອບໍ່ໃຫ້ໂອນພວກມັນ - ພວກມັນບໍ່ຫນ້າສົນໃຈກັບຂ້ອຍແທ້ໆ.

ແລະພວກເຮົາເຮັດການປັບປຸງຫຼ້າສຸດໃນ db_extention ຂອງພວກເຮົາ: ພວກເຮົາຕິດຕັ້ງ timescaledb ເພື່ອໃຫ້ຖານຂໍ້ມູນແລະ, ໂດຍສະເພາະ, Zabbix ຂອງພວກເຮົາເຂົ້າໃຈວ່າມີ db_extention. ລາວເປີດໃຊ້ມັນແລະໃຊ້ syntax ແລະຄໍາຖາມທີ່ຖືກຕ້ອງກັບຖານຂໍ້ມູນ, ໂດຍໃຊ້ "ຄຸນສົມບັດ" ເຫຼົ່ານັ້ນທີ່ຈໍາເປັນສໍາລັບ TimescaleDB.

ການຕັ້ງຄ່າເຊີບເວີ

ຂ້ອຍໃຊ້ສອງເຄື່ອງແມ່ຂ່າຍ. ເຄື່ອງແມ່ຂ່າຍທໍາອິດແມ່ນເຄື່ອງ virtual ຂະຫນາດນ້ອຍພໍສົມຄວນ, 20 ໂປເຊດເຊີ, 16 gigabyte ຂອງ RAM. ຂ້ອຍຕັ້ງຄ່າ Postgres 10.8 ໃນມັນ:

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

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

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

ການທົດສອບປະສິດທິພາບ. PostgreSQL: 36 ພັນ NVPs

ການເປີດຕົວຄັ້ງທໍາອິດ, ການຕິດຕັ້ງທໍາອິດທີ່ຂ້ອຍມີຢູ່ໃນ PostreSQL 10 ອັນບໍລິສຸດໃນຮາດແວນີ້ (35 ພັນຄ່າຕໍ່ວິນາທີ). ໂດຍທົ່ວໄປ, ຕາມທີ່ທ່ານສາມາດເບິ່ງໃນຫນ້າຈໍ, ການໃສ່ຂໍ້ມູນໃຊ້ເວລາສ່ວນຫນຶ່ງຂອງວິນາທີ - ທຸກສິ່ງທຸກຢ່າງແມ່ນດີແລະໄວ, SSD drives (200 gigabyte). ສິ່ງດຽວແມ່ນວ່າ 20 GB ເຕັມໄວ.

ຈະມີກາຟດັ່ງກ່າວຫຼາຍພໍສົມຄວນໃນອະນາຄົດ. ນີ້ແມ່ນແຜງໜ້າປັດປະສິດທິພາບຂອງເຊີບເວີ Zabbix ມາດຕະຖານ.

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

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

ການທົດສອບປະສິດທິພາບ. PostgreSQL: 50 ພັນ NVPs

ຕໍ່ໄປ, ຂ້າພະເຈົ້າໄດ້ເພີ່ມການໂຫຼດເຖິງ 50 ພັນຄ່າຕໍ່ວິນາທີໃນຮາດແວດຽວກັນ. ໃນເວລາທີ່ການໂຫຼດໂດຍ Housekeeper, 10 ພັນມູນຄ່າຖືກບັນທຶກໄວ້ໃນ 2-3 ວິນາທີດ້ວຍການຄິດໄລ່. ໃນຄວາມເປັນຈິງ, ສິ່ງທີ່ສະແດງຢູ່ໃນຫນ້າຈໍຕໍ່ໄປນີ້:

"ຜູ້ຮັກສາເຮືອນ" ກໍາລັງເລີ່ມຕົ້ນທີ່ຈະແຊກແຊງວຽກງານ, ແຕ່ໂດຍທົ່ວໄປແລ້ວ, ການໂຫຼດຂອງຜູ້ຫລົ້ມຈົມປະຫວັດສາດແມ່ນຍັງຢູ່ໃນລະດັບ 60% (ເສັ້ນສະແດງທີສາມ, ຂວາເທິງ). HistoryCache ແລ້ວເລີ່ມຕື່ມຂໍ້ມູນຢ່າງຫ້າວຫັນໃນຂະນະທີ່ຜູ້ຮັກສາເຮືອນກໍາລັງແລ່ນ (ຊ້າຍລຸ່ມ). ມັນແມ່ນປະມານເຄິ່ງຫນຶ່ງ gigabyte, 20% ເຕັມ.

ການທົດສອບປະສິດທິພາບ. PostgreSQL: 80 ພັນ NVPs

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເພີ່ມຂຶ້ນເປັນ 80 ພັນຄ່າຕໍ່ວິນາທີ:

ມັນແມ່ນປະມານ 400 ພັນອົງປະກອບຂໍ້ມູນ, 280 ພັນ triggers. ໃສ່, ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ໃນແງ່ຂອງການໂຫຼດຂອງ sinkers ປະຫວັດສາດ (ມີ 30 ຂອງພວກເຂົາ) ແມ່ນຂ້ອນຂ້າງສູງ. ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເພີ່ມຕົວກໍານົດການຕ່າງໆ: sinkers ປະຫວັດສາດ, cache ... ໃນຮາດແວນີ້, ການໂຫຼດຂອງ sinkers ປະຫວັດສາດເລີ່ມເພີ່ມຂຶ້ນເຖິງສູງສຸດ, ເກືອບ "ຢູ່ໃນ shelf" - ຕາມນັ້ນ, HistoryCache ໄດ້ເຂົ້າໄປໃນການໂຫຼດສູງຫຼາຍ:

ຕະຫຼອດເວລານີ້ຂ້ອຍໄດ້ຕິດຕາມຕົວກໍານົດການຂອງລະບົບທັງຫມົດ (ວິທີການໃຊ້ໂປເຊດເຊີ, RAM) ແລະຄົ້ນພົບວ່າການນໍາໃຊ້ແຜ່ນແມ່ນສູງສຸດ - ຂ້ອຍໄດ້ບັນລຸຄວາມສາມາດສູງສຸດຂອງແຜ່ນນີ້ໃນຮາດແວນີ້, ໃນເຄື່ອງ virtual ນີ້. "Postgres" ໄດ້ເລີ່ມຕົ້ນທີ່ຈະ dump ຂໍ້ມູນຢ່າງຈິງຈັງຢູ່ໃນຄວາມເຂັ້ມຂົ້ນດັ່ງກ່າວ, ແລະແຜ່ນບໍ່ມີເວລາທີ່ຈະຂຽນ, ອ່ານ ...

ຂ້ອຍເອົາເຄື່ອງແມ່ຂ່າຍອື່ນທີ່ມີ 48 ໂປເຊດເຊີແລະ RAM 128 gigabytes ແລ້ວ:

ຂ້ອຍຍັງ "ປັບ" ມັນ - ຕິດຕັ້ງ History syncer (60 ຊິ້ນ) ແລະບັນລຸການປະຕິບັດທີ່ຍອມຮັບ. ໃນຄວາມເປັນຈິງ, ພວກເຮົາບໍ່ໄດ້ "ຢູ່ໃນຊັ້ນວາງ," ແຕ່ນີ້ອາດຈະເປັນຂອບເຂດຈໍາກັດຂອງຜົນຜະລິດ, ບ່ອນທີ່ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະເຮັດບາງສິ່ງບາງຢ່າງກ່ຽວກັບມັນ.

ການທົດສອບປະສິດທິພາບ. TimescaleDB: 80 ພັນ NVPs

ຫນ້າທີ່ຕົ້ນຕໍຂອງຂ້ອຍແມ່ນການໃຊ້ TimescaleDB. ແຕ່ລະເສັ້ນສະແດງການຖອກລົງ:

ຄວາມລົ້ມເຫລວເຫຼົ່ານີ້ແມ່ນການໂອນຂໍ້ມູນຢ່າງແນ່ນອນ. ຫຼັງຈາກນັ້ນ, ໃນເຊີບເວີ Zabbix, ຂໍ້ມູນການໂຫຼດຂອງ sinkers ປະຫວັດສາດ, ຕາມທີ່ເຈົ້າເຫັນ, ມີການປ່ຽນແປງຫຼາຍ. ມັນຊ່ວຍໃຫ້ທ່ານສາມາດໃສ່ຂໍ້ມູນໄດ້ໄວຂຶ້ນເກືອບ 3 ເທົ່າແລະໃຊ້ HistoryCache ຫນ້ອຍລົງ - ຕາມນັ້ນ, ທ່ານຈະມີຂໍ້ມູນສົ່ງຕາມເວລາ. ອີກເທື່ອຫນຶ່ງ, 80 ພັນຄ່າຕໍ່ວິນາທີແມ່ນອັດຕາທີ່ສູງພໍສົມຄວນ (ແນ່ນອນ, ບໍ່ແມ່ນສໍາລັບ Yandex). ໂດຍລວມແລ້ວນີ້ແມ່ນການຕິດຕັ້ງຂະຫນາດໃຫຍ່ພໍສົມຄວນ, ມີເຄື່ອງແມ່ຂ່າຍດຽວ.

ການທົດສອບການປະຕິບັດ PostgreSQL: 120 ພັນ NVPs

ຕໍ່ໄປ, ຂ້າພະເຈົ້າໄດ້ເພີ່ມມູນຄ່າຂອງຈໍານວນຂອງອົງປະກອບຂໍ້ມູນເປັນເຄິ່ງຫນຶ່ງລ້ານແລະໄດ້ຮັບມູນຄ່າການຄິດໄລ່ຂອງ 125 ພັນຕໍ່ວິນາທີ:

ແລະຂ້ອຍໄດ້ຮັບກາຟເຫຼົ່ານີ້:

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

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

ຍັງມີຕົວຢ່າງໃນຊຸມຊົນ:

ບຸກຄົນດັ່ງກ່າວຍັງເປີດ TimescaleDB ແລະການໂຫຼດໃນການນໍາໃຊ້ io.weight ຫຼຸດລົງໃນໂຮງງານຜະລິດ; ແລະການນໍາໃຊ້ອົງປະກອບຂະບວນການພາຍໃນຍັງຫຼຸດລົງຍ້ອນການລວມເອົາ TimescaleDB. ຍິ່ງໄປກວ່ານັ້ນ, ເຫຼົ່ານີ້ແມ່ນແຜ່ນ pancake ທໍາມະດາ, ນັ້ນແມ່ນ, ເຄື່ອງ virtual ທໍາມະດາໃນແຜ່ນທໍາມະດາ (ບໍ່ແມ່ນ SSDs)!

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

ຂ້າພະເຈົ້າຂໍເຊີນທ່ານເຂົ້າຮ່ວມກິດຈະກໍາຂອງພວກເຮົາ: ກອງປະຊຸມໃນ Moscow, ກອງປະຊຸມສຸດຍອດໃນ Riga. ໃຊ້ຊ່ອງທາງຂອງພວກເຮົາ - Telegram, forum, IRC. ຖ້າຫາກວ່າທ່ານມີຄໍາຖາມໃດໆ, ມາ desk ຂອງພວກເຮົາ, ພວກເຮົາສາມາດສົນທະນາກ່ຽວກັບທຸກສິ່ງທຸກຢ່າງ.

ຄໍາຖາມຂອງຜູ້ຊົມ

ຄໍາຖາມຈາກຜູ້ຊົມ (ຕໍ່ໄປນີ້ - A): - ຖ້າ TimescaleDB ງ່າຍຕໍ່ການຕັ້ງຄ່າ, ແລະມັນເຮັດໃຫ້ປະສິດທິພາບດັ່ງກ່າວ, ບາງທີນີ້ຄວນຈະຖືກນໍາໃຊ້ເປັນການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການຕັ້ງຄ່າ Zabbix ກັບ Postgres? ແລະມີຂໍ້ບົກຜ່ອງແລະຂໍ້ເສຍຂອງການແກ້ໄຂນີ້, ຫຼືຫຼັງຈາກທັງຫມົດ, ຖ້າຂ້ອຍຕັດສິນໃຈເຮັດ Zabbix ສໍາລັບຕົວເອງ, ຂ້ອຍສາມາດເອົາ Postgres ໄດ້ຢ່າງງ່າຍດາຍ, ຕິດຕັ້ງ Timescale ທັນທີ, ໃຊ້ມັນແລະບໍ່ຄິດກ່ຽວກັບບັນຫາໃດໆ?

AG: - ແມ່ນແລ້ວ, ຂ້າພະເຈົ້າຈະເວົ້າວ່ານີ້ແມ່ນຄໍາແນະນໍາທີ່ດີ: ໃຊ້ Postgres ທັນທີດ້ວຍການຂະຫຍາຍ TimescaleDB. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວ, ການທົບທວນຄືນທີ່ດີຫຼາຍ, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າ "ຄຸນສົມບັດ" ນີ້ແມ່ນການທົດລອງ. ແຕ່ຕົວຈິງແລ້ວການທົດສອບສະແດງໃຫ້ເຫັນວ່ານີ້ແມ່ນການແກ້ໄຂທີ່ດີ (ກັບ TimescaleDB) ແລະຂ້ອຍຄິດວ່າມັນຈະພັດທະນາ! ພວກເຮົາກຳລັງຕິດຕາມເບິ່ງວ່າສ່ວນຂະຫຍາຍນີ້ພັດທະນາແນວໃດ ແລະຈະປ່ຽນແປງຕາມຄວາມຕ້ອງການ.

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

A: - ໃນກາຟສຸດທ້າຍຈາກຊຸມຊົນ, ມີເສັ້ນສະແດງທີ່ມີ "ຜູ້ຮັກສາເຮືອນ":

ລາວສືບຕໍ່ເຮັດວຽກ. ເຈົ້າຂອງເຮືອນເຮັດຫຍັງກັບ TimescaleDB?

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

A: - ຂ້ອຍມີຄໍາຖາມທີ່ຄ້າຍຄືກັນ - ກ່ຽວກັບການປະຕິບັດການລຶບໃນ Timescale.
A (ຄໍາຕອບຈາກຜູ້ຊົມ): - ເມື່ອທ່ານລຶບຂໍ້ມູນຈາກຕາຕະລາງ, ຖ້າທ່ານເຮັດມັນຜ່ານທາງລົບ, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງຜ່ານຕາຕະລາງ - ລຶບ, ເຮັດຄວາມສະອາດ, ຫມາຍທຸກສິ່ງທຸກຢ່າງສໍາລັບການສູນຍາກາດໃນອະນາຄົດ. ໃນ Timescale, ນັບຕັ້ງແຕ່ທ່ານມີ chunks, ທ່ານສາມາດຫຼຸດລົງ. ເວົ້າປະມານ, ທ່ານພຽງແຕ່ບອກໄຟລ໌ທີ່ຢູ່ໃນຂໍ້ມູນໃຫຍ່: "ລຶບ!"

Timescale ພຽງແຕ່ເຂົ້າໃຈວ່າ chunk ດັ່ງກ່າວບໍ່ມີແລ້ວ. ແລະນັບຕັ້ງແຕ່ມັນຖືກປະສົມປະສານເຂົ້າໃນການວາງແຜນການສອບຖາມ, ມັນໃຊ້ hooks ເພື່ອຈັບເງື່ອນໄຂຂອງທ່ານໃນການດໍາເນີນງານທີ່ເລືອກຫຼືອື່ນໆແລະເຂົ້າໃຈທັນທີວ່າ chunk ນີ້ບໍ່ມີແລ້ວ - "ຂ້ອຍຈະບໍ່ໄປບ່ອນນັ້ນອີກຕໍ່ໄປ!" (ບໍ່ມີຂໍ້ມູນ). ຫມົດ​ເທົ່າ​ນີ້! ນັ້ນແມ່ນ, ການສະແກນຕາຕະລາງຖືກແທນທີ່ດ້ວຍການລຶບໄຟລ໌ສອງ, ສະນັ້ນມັນໄວ.

A: - ພວກເຮົາໄດ້ສໍາຜັດແລ້ວກ່ຽວກັບຫົວຂໍ້ທີ່ບໍ່ແມ່ນ SQL. ເທົ່າທີ່ຂ້ອຍເຂົ້າໃຈ, Zabbix ບໍ່ຈໍາເປັນຕ້ອງດັດແປງຂໍ້ມູນ, ແລະທັງຫມົດນີ້ແມ່ນບາງສິ່ງບາງຢ່າງເຊັ່ນ: ບັນທຶກ. ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ຖານຂໍ້ມູນພິເສດທີ່ບໍ່ສາມາດປ່ຽນແປງຂໍ້ມູນຂອງເຂົາເຈົ້າ, ແຕ່ໃນເວລາດຽວກັນຊ່ວຍປະຢັດ, ສະສົມ, ແລະແຈກຢາຍໄວຂຶ້ນຫຼາຍ - Clickhouse, ຕົວຢ່າງເຊັ່ນ, ບາງສິ່ງບາງຢ່າງຄ້າຍຄື Kafka?.. Kafka ຍັງເປັນບັນທຶກ! ມັນເປັນໄປໄດ້ somehow ປະສົມປະສານໃຫ້ເຂົາເຈົ້າ?

AG: - Unloading ສາມາດເຮັດໄດ້. ພວກ​ເຮົາ​ມີ "ຄຸນ​ນະ​ສົມ​ບັດ​" ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​ນັບ​ຕັ້ງ​ແຕ່​ສະ​ບັບ 3.4​: ທ່ານ​ສາ​ມາດ​ຂຽນ​ໄຟລ​໌​ປະ​ຫວັດ​ສາດ​ທັງ​ຫມົດ​, ກິດ​ຈະ​ກໍາ​, ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ເພື່ອ​ໄຟລ​໌​; ແລະຫຼັງຈາກນັ້ນສົ່ງມັນໄປຫາຖານຂໍ້ມູນອື່ນໂດຍໃຊ້ຕົວຈັດການບາງຢ່າງ. ໃນຄວາມເປັນຈິງ, ປະຊາຊົນຈໍານວນຫຼາຍ rework ແລະຂຽນໂດຍກົງໃສ່ຖານຂໍ້ມູນ. ໃນການບິນ, sinkers ປະຫວັດສາດຂຽນທັງຫມົດນີ້ເຂົ້າໄປໃນໄຟລ໌, rotate ໄຟລ໌ເຫຼົ່ານີ້, ແລະອື່ນໆ, ແລະທ່ານສາມາດໂອນມັນໄປ Clickhouse. ຂ້ອຍບໍ່ສາມາດເວົ້າກ່ຽວກັບແຜນການ, ແຕ່ບາງທີການສະຫນັບສະຫນູນເພີ່ມເຕີມສໍາລັບການແກ້ໄຂ NoSQL (ເຊັ່ນ Clickhouse) ຈະສືບຕໍ່.

A: – ໂດຍ​ທົ່ວ​ໄປ​, ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ທ່ານ​ຫມົດ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ກໍາ​ຈັດ​ຂອງ postgres​?

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

A: – ທ່ານສາມາດຄາດຄະເນວ່າທຸກສິ່ງທຸກຢ່າງຈະເຮັດວຽກໄດ້ໄວເທົ່າໃດຖ້າທ່ານປ່ຽນໄປ Clickhouse, ຕົວຢ່າງ?

AG: - ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ໄດ້​ທົດ​ສອບ​ມັນ​. ຂ້າພະເຈົ້າຄິດວ່າຢ່າງຫນ້ອຍຕົວເລກດຽວກັນສາມາດບັນລຸໄດ້ຢ່າງງ່າຍດາຍ, ເນື່ອງຈາກວ່າ Clickhouse ມີການໂຕ້ຕອບຂອງຕົນເອງ, ແຕ່ຂ້າພະເຈົ້າບໍ່ສາມາດເວົ້າໄດ້ແນ່ນອນ. ມັນດີກວ່າທີ່ຈະທົດສອບ. ມັນທັງຫມົດແມ່ນຂຶ້ນກັບການຕັ້ງຄ່າ: ທ່ານມີເຈົ້າພາບຫຼາຍປານໃດ, ແລະອື່ນໆ. ການໃສ່ແມ່ນສິ່ງຫນຶ່ງ, ແຕ່ທ່ານຍັງຕ້ອງການດຶງຂໍ້ມູນນີ້ - Grafana ຫຼືສິ່ງອື່ນ.

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

AG: – ຂ້າພະເຈົ້າຄິດວ່າເມື່ອພວກເຮົາປະສົມປະສານ, ຈະມີການທົດສອບທີ່ຖືກຕ້ອງຫຼາຍຂຶ້ນ.

A: - RRD ເກົ່າດີໄປໃສ? ແມ່ນຫຍັງເຮັດໃຫ້ທ່ານປ່ຽນໄປຫາຖານຂໍ້ມູນ SQL? ໃນເບື້ອງຕົ້ນ, ການວັດແທກທັງຫມົດໄດ້ຖືກເກັບກໍາຢູ່ໃນ RRD.

AG: – Zabbix ມີ RRD, ບາງທີອາດຢູ່ໃນສະບັບເກົ່າແກ່ຫຼາຍ. ມີຖານຂໍ້ມູນ SQL ສະເຫມີ - ວິທີການຄລາສສິກ. ວິທີການຄລາສສິກແມ່ນ MySQL, PostgreSQL (ພວກເຂົາມີຢູ່ໃນເວລາດົນນານ). ພວກເຮົາເກືອບບໍ່ເຄີຍໃຊ້ການໂຕ້ຕອບທົ່ວໄປສໍາລັບຖານຂໍ້ມູນ SQL ແລະ RRD.

ບາງໂຄສະນາ🙂

ຂອບໃຈສໍາລັບການຢູ່ກັບພວກເຮົາ. ເຈົ້າມັກບົດຄວາມຂອງພວກເຮົາບໍ? ຕ້ອງການເບິ່ງເນື້ອຫາທີ່ຫນ້າສົນໃຈຫຼາຍບໍ? ສະຫນັບສະຫນູນພວກເຮົາໂດຍການວາງຄໍາສັ່ງຫຼືແນະນໍາໃຫ້ຫມູ່ເພື່ອນ, cloud VPS ສໍາລັບນັກພັດທະນາຈາກ $4.99, ການປຽບທຽບທີ່ເປັນເອກະລັກຂອງເຊີບເວີລະດັບເຂົ້າ, ເຊິ່ງຖືກປະດິດໂດຍພວກເຮົາສໍາລັບທ່ານ: ຄວາມຈິງທັງໝົດກ່ຽວກັບ 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