ໄປການເພີ່ມປະສິດທິພາບໃນ VictoriaMetrics. Alexander Valyalkin

ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ທ່ານອ່ານບົດບັນທຶກຂອງບົດລາຍງານທ້າຍປີ 2019 ໂດຍ Alexander Valyalkin "ໄປເພີ່ມປະສິດທິພາບໃນ VictoriaMetrics"

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

ນີ້ແມ່ນການເຊື່ອມຕໍ່ກັບວິດີໂອຂອງບົດລາຍງານນີ້ - https://youtu.be/MZ5P21j_HLE

ສະໄລ້

ບອກພວກເຮົາກ່ຽວກັບຕົວທ່ານເອງ. ຂ້ອຍແມ່ນ Alexander Valyalkin. ທີ່ນີ້ ບັນຊີ GitHub ຂອງຂ້ອຍ. ຂ້ອຍມີຄວາມກະຕືລືລົ້ນກ່ຽວກັບ Go ແລະການເພີ່ມປະສິດທິພາບການປະຕິບັດ. ຂ້າພະເຈົ້າໄດ້ຂຽນຫ້ອງສະຫມຸດທີ່ເປັນປະໂຫຍດຫຼາຍແລະບໍ່ມີປະໂຫຍດຫຼາຍ. ພວກເຂົາເຈົ້າເລີ່ມຕົ້ນດ້ວຍບໍ່ວ່າຈະ fast, ຫຼືກັບ quick ຄຳນຳໜ້າ.

ຕອນນີ້ຂ້ອຍກຳລັງເຮັດວຽກຢູ່ VictoriaMetrics. ມັນແມ່ນຫຍັງແລະຂ້ອຍກໍາລັງເຮັດຫຍັງຢູ່ທີ່ນັ້ນ? ຂ້ອຍຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້ໃນການນໍາສະເຫນີນີ້.

ເນື້ອໃນຂອງບົດລາຍງານມີດັ່ງນີ້:

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

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

VictoriaMetrics ສະຫນອງການບີບອັດຂໍ້ມູນທີ່ດີກວ່າຖານຂໍ້ມູນຊຸດເວລາອື່ນໆ.

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

VictoriaMetrics ຍັງປັບຂະຫນາດຕາມແນວນອນ - ນັ້ນແມ່ນ, ທ່ານສາມາດເພີ່ມຂໍ້ເພີ່ມເຕີມໃສ່ກຸ່ມ VictoriaMetrics, ແລະການປະຕິບັດຂອງມັນຈະເພີ່ມຂຶ້ນເກືອບເປັນເສັ້ນ.

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

ໃຜຮູ້ວ່າຊຸດເວລາແມ່ນຫຍັງ? ລາວຍັງຮູ້ຈັກຫຼາຍຄົນ. ຊຸດເວລາແມ່ນຊຸດຂອງຄູ່ (timestamp, значение), ບ່ອນທີ່ຄູ່ເຫຼົ່ານີ້ຖືກຈັດຮຽງຕາມເວລາ. ຄ່າແມ່ນຕົວເລກຈຸດລອຍ – float64.

ແຕ່ລະຊຸດເວລາຖືກລະບຸໄວ້ເປັນເອກະລັກໂດຍກະແຈ. ກຸນແຈນີ້ປະກອບດ້ວຍຫຍັງ? ມັນປະກອບດ້ວຍຊຸດຄູ່ຄີ-ຄ່າທີ່ບໍ່ຫວ່າງເປົ່າ.

ນີ້ແມ່ນຕົວຢ່າງຂອງຊຸດເວລາ. ກຸນແຈຂອງຊຸດນີ້ແມ່ນບັນຊີລາຍຊື່ຂອງຄູ່: __name__="cpu_usage" ແມ່ນ​ຊື່​ຂອງ​ການ​ວັດ​ແທກ​, instance="my-server" - ນີ້​ແມ່ນ​ຄອມ​ພິວ​ເຕີ​ທີ່ metric ນີ້​ໄດ້​ຖືກ​ເກັບ​ກໍາ​, datacenter="us-east" - ນີ້ແມ່ນສູນຂໍ້ມູນບ່ອນທີ່ຄອມພິວເຕີເຄື່ອງນີ້ຕັ້ງຢູ່.

ພວກເຮົາຈົບລົງດ້ວຍຊື່ຊຸດເວລາເຊິ່ງປະກອບດ້ວຍສາມຄູ່ຄີ-ຄ່າ. ລະຫັດນີ້ກົງກັບບັນຊີລາຍຊື່ຂອງຄູ່ (timestamp, value). t1, t3, t3, ..., tN - ເຫຼົ່າ​ນີ້​ແມ່ນ​ສະ​ແຕມ​ເວ​ລາ​, 10, 20, 12, ..., 15 - ຄ່າ​ທີ່​ສອດ​ຄ້ອງ​ກັນ​. ນີ້ແມ່ນການໃຊ້ cpu ໃນເວລາທີ່ກໍານົດໄວ້ສໍາລັບຊຸດທີ່ໃຫ້.

ສາມາດໃຊ້ຊຸດເວລາໄດ້ຢູ່ໃສ? ມີໃຜມີຄວາມຄິດແນວໃດ?

• ໃນ DevOps, ທ່ານສາມາດວັດແທກ CPU, RAM, ເຄືອຂ່າຍ, rps, ຈໍານວນຂໍ້ຜິດພາດ, ແລະອື່ນໆ.
• IoT - ພວກເຮົາສາມາດວັດແທກອຸນຫະພູມ, ຄວາມກົດດັນ, ພິກັດທາງພູມສາດແລະສິ່ງອື່ນ.
• ນອກ​ຈາກ​ນີ້​ທາງ​ດ້ານ​ການ​ເງິນ – ພວກ​ເຮົາ​ສາ​ມາດ​ຕິດ​ຕາມ​ກວດ​ກາ​ລາ​ຄາ​ສໍາ​ລັບ​ການ​ຄັດ​ເລືອກ​ທັງ​ຫມົດ​ຂອງ​ຫຼັກ​ຊັບ​ແລະ​ສະ​ກຸນ​ເງິນ​.
• ນອກຈາກນັ້ນ, ຊຸດເວລາສາມາດຖືກນໍາໃຊ້ໃນການຕິດຕາມຂະບວນການຜະລິດໃນໂຮງງານ. ພວກເຮົາມີຜູ້ໃຊ້ທີ່ໃຊ້ VictoriaMetrics ເພື່ອຕິດຕາມເຄື່ອງຈັກລົມ, ສໍາລັບຫຸ່ນຍົນ.
• ຊຸດເວລາຍັງເປັນປະໂຫຍດສໍາລັບການລວບລວມຂໍ້ມູນຈາກເຊັນເຊີຂອງອຸປະກອນຕ່າງໆ. ຕົວຢ່າງ, ສໍາລັບເຄື່ອງຈັກ; ສໍາລັບການວັດແທກຄວາມກົດດັນຢາງລົດ; ສໍາລັບການວັດແທກຄວາມໄວ, ໄລຍະທາງ; ສໍາລັບການວັດແທກການບໍລິໂພກນໍ້າມັນເຊື້ອໄຟ, ແລະອື່ນໆ.
• ຊຸດເວລາຍັງສາມາດຖືກນໍາໃຊ້ເພື່ອຕິດຕາມກວດກາເຮືອບິນ. ແຕ່ລະເຮືອບິນມີກ່ອງສີດໍາທີ່ເກັບກໍາຊຸດເວລາສໍາລັບພາລາມິເຕີຕ່າງໆຂອງສຸຂະພາບຂອງເຮືອບິນ. ຊຸດເວລາຍັງຖືກນໍາໃຊ້ໃນອຸດສາຫະກໍາການບິນອະວະກາດ.
• ການຮັກສາສຸຂະພາບແມ່ນຄວາມດັນເລືອດ, ກໍາມະຈອນ, ແລະອື່ນໆ.

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

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

ເນື່ອງຈາກວ່າຊຸດເວລາມັກຈະມີຂໍ້ມູນຈໍານວນຫລາຍ, ເຊິ່ງຍາກທີ່ຈະເກັບຮັກສາແລະປຸງແຕ່ງໃນຖານຂໍ້ມູນທໍາມະດາ. ດັ່ງນັ້ນ, ຖານຂໍ້ມູນພິເສດສໍາລັບຊຸດເວລາປາກົດ. ພື້ນຖານເຫຼົ່ານີ້ມີປະສິດຕິຜົນເກັບຮັກສາຈຸດ (timestamp, value) ດ້ວຍກະແຈທີ່ໃຫ້ໄວ້. ພວກເຂົາສະຫນອງ API ສໍາລັບການອ່ານຂໍ້ມູນທີ່ເກັບໄວ້ໂດຍຄີ, ໂດຍຄູ່ຄີ-ຄ່າດຽວ, ຫຼືໂດຍຄູ່ຄີ-ຄ່າຫຼາຍ, ຫຼືໂດຍ regexp. ຕົວຢ່າງ, ທ່ານຕ້ອງການຊອກຫາການໂຫຼດ CPU ຂອງການບໍລິການທັງຫມົດຂອງທ່ານໃນສູນຂໍ້ມູນໃນອາເມລິກາ, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງໃຊ້ pseudo-query ນີ້.

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

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

ມັນປະກອບດ້ວຍສອງພາກສ່ວນ. ນີ້ແມ່ນການເກັບຮັກສາສໍາລັບດັດສະນີ inverted ແລະການເກັບຮັກສາສໍາລັບຄ່າຊຸດເວລາ. repositories ເຫຼົ່ານີ້ແມ່ນແຍກອອກ.

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

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

ຂໍໃຫ້ເບິ່ງຕົວຢ່າງຂອງວິທີການຖານຂໍ້ມູນຊຸດເວລາປະມວນຜົນການສອບຖາມທີ່ເຂົ້າມາ.

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

ໃນການນໍາສະເຫນີນີ້ຂ້າພະເຈົ້າຈະບອກທ່ານກ່ຽວກັບພາກສ່ວນທໍາອິດ. ນີ້ແມ່ນການຄົ້ນຫາ timeseries_ids ໂດຍ inverted index. ທ່ານສາມາດເບິ່ງກ່ຽວກັບພາກທີສອງແລະພາກທີສາມຕໍ່ມາ ແຫຼ່ງ VictoriaMetrics, ຫຼືລໍຖ້າຈົນກ່ວາຂ້າພະເຈົ້າກະກຽມບົດລາຍງານອື່ນໆ :)

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

ໃນຄວາມເປັນຈິງ, ມັນງ່າຍດາຍ. ມັນເປັນພຽງແຕ່ວັດຈະນານຸກົມທີ່ແຜນທີ່ລະຫັດໄປຫາຄ່າ. ກະແຈແມ່ນຫຍັງ? ຄູ່ນີ້ label=valueບ່ອນທີ່ label и value - ເຫຼົ່ານີ້ແມ່ນສາຍ. ແລະຄ່າແມ່ນຊຸດ timeseries_ids, ເຊິ່ງລວມມີຄູ່ທີ່ໃຫ້ label=value.

Inverted index ຊ່ວຍໃຫ້ທ່ານສາມາດຊອກຫາທຸກສິ່ງທຸກຢ່າງໄດ້ໄວ timeseries_ids, ທີ່​ໄດ້​ໃຫ້​ label=value.

ມັນຍັງອະນຸຍາດໃຫ້ທ່ານຊອກຫາຢ່າງໄວວາ timeseries_ids ຊຸດເວລາສໍາລັບຫຼາຍຄູ່ label=value, ຫຼືສໍາລັບຄູ່ຜົວເມຍ label=regexp. ນີ້ເກີດຂຶ້ນແນວໃດ? ໂດຍຊອກຫາຈຸດຕັດກັນຂອງຊຸດ timeseries_ids ສໍາລັບແຕ່ລະຄູ່ label=value.

ຂໍໃຫ້ເບິ່ງການປະຕິບັດຕ່າງໆຂອງດັດສະນີ inverted. ໃຫ້ເລີ່ມຕົ້ນດ້ວຍການປະຕິບັດ naive ທີ່ງ່າຍດາຍທີ່ສຸດ. ນາງເບິ່ງຄືວ່ານີ້.

ການທໍາງານຂອງ getMetricIDs ໄດ້ຮັບບັນຊີລາຍຊື່ຂອງສະຕຣິງ. ແຕ່ລະສາຍປະກອບດ້ວຍ label=value. ຟັງຊັນນີ້ສົ່ງຄືນລາຍຊື່ metricIDs.

ມັນເຮັດວຽກແນວໃດ? ໃນທີ່ນີ້ພວກເຮົາມີຕົວແປທົ່ວໂລກທີ່ເອີ້ນວ່າ invertedIndex. ນີ້ແມ່ນວັດຈະນານຸກົມປົກກະຕິ (map), ເຊິ່ງຈະສ້າງແຜນທີ່ string ເພື່ອຕັດ ints. ເສັ້ນປະກອບມີ label=value.

ການປະຕິບັດຫນ້າທີ່: ໄດ້ຮັບ metricIDs ສໍາລັບຄັ້ງທໍາອິດ label=value, ຫຼັງຈາກນັ້ນພວກເຮົາຜ່ານທຸກສິ່ງທຸກຢ່າງອື່ນ label=value, ພວກເຮົາໄດ້ຮັບມັນ metricIDs ສໍາ​ລັບ​ພວກ​ເຂົາ. ແລະໂທຫາຫນ້າທີ່ intersectInts, ເຊິ່ງຈະໄດ້ຮັບການປຶກສາຫາລືຂ້າງລຸ່ມນີ້. ແລະຟັງຊັນນີ້ສົ່ງຄືນຈຸດຕັດກັນຂອງລາຍຊື່ເຫຼົ່ານີ້.

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

ຂໍ້ບົກຜ່ອງທີສອງຍັງກ່ຽວຂ້ອງກັບຄວາມຊົງຈໍາ. ດັດຊະນີ inverted ຕ້ອງເຫມາະກັບ RAM. ຖ້າມັນເກີນຂະຫນາດຂອງ RAM, ແນ່ນອນພວກເຮົາຈະໄດ້ຮັບ - ຄວາມຜິດພາດຂອງຫນ່ວຍຄວາມຈໍາ. ແລະໂຄງການຈະບໍ່ເຮັດວຽກ.

ບັນຫານີ້ສາມາດແກ້ໄຂໄດ້ໂດຍໃຊ້ວິທີແກ້ໄຂທີ່ພ້ອມທີ່ຈະເຮັດເຊັ່ນ: LevelDB, ຫຼື RocksDB.

ໃນສັ້ນ, ພວກເຮົາຕ້ອງການຖານຂໍ້ມູນທີ່ອະນຸຍາດໃຫ້ພວກເຮົາດໍາເນີນການສາມຢ່າງໄວ.

• ການດໍາເນີນງານທໍາອິດແມ່ນການບັນທຶກ ключ-значение ກັບຖານຂໍ້ມູນນີ້. ນາງເຮັດສິ່ງນີ້ຢ່າງໄວວາ, ບ່ອນທີ່ ключ-значение ແມ່ນສາຍທີ່ມັກ.
• ການດໍາເນີນງານທີສອງແມ່ນການຄົ້ນຫາໄວສໍາລັບມູນຄ່າໂດຍໃຊ້ລະຫັດທີ່ໃຫ້.
• ແລະການດໍາເນີນງານທີສາມແມ່ນການຊອກຫາໄວສໍາລັບຄ່າທັງຫມົດໂດຍຄໍານໍາຫນ້າທີ່ໃຫ້.

LevelDB ແລະ RocksDB - ຖານຂໍ້ມູນເຫຼົ່ານີ້ຖືກພັດທະນາໂດຍ Google ແລະ Facebook. ທໍາອິດມາ LevelDB. ຫຼັງຈາກນັ້ນ, guys ຈາກເຟສບຸກໄດ້ເອົາ LevelDB ແລະເລີ່ມປັບປຸງມັນ, ພວກເຂົາເຈົ້າເຮັດໃຫ້ RocksDB. ໃນປັດຈຸບັນເກືອບທຸກຖານຂໍ້ມູນພາຍໃນເຮັດວຽກຢູ່ໃນ RocksDB ພາຍໃນ Facebook, ລວມທັງຂໍ້ມູນທີ່ຖືກໂອນໄປຫາ RocksDB ແລະ MySQL. ເຂົາເຈົ້າຕັ້ງຊື່ໃຫ້ເຂົາ MyRocks.

ດັດຊະນີ inverted ສາມາດຖືກປະຕິບັດໂດຍໃຊ້ LevelDB. ເຮັດແນວໃດມັນ? ພວກເຮົາບັນທຶກເປັນກະແຈ label=value. ແລະຄ່າແມ່ນຕົວລະບຸໄລຍະເວລາທີ່ຄູ່ຢູ່ label=value.

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

ນີ້ແມ່ນຕົວຢ່າງການຈັດຕັ້ງປະຕິບັດສິ່ງທີ່ມັນເບິ່ງຄືວ່າຢູ່ໃນ Go. ພວກເຮົາມີດັດຊະນີ inverted. ນີ້ແມ່ນ LevelDB.

ຫນ້າທີ່ແມ່ນຄືກັນກັບການປະຕິບັດ naive. ມັນເຮັດເລື້ມຄືນການປະຕິບັດ naive ເກືອບເສັ້ນໂດຍສາຍ. ຈຸດດຽວແມ່ນວ່າແທນທີ່ຈະຫັນໄປຫາ map ພວກເຮົາເຂົ້າເຖິງດັດຊະນີ inverted. ພວກເຮົາໄດ້ຮັບຄ່າທັງຫມົດສໍາລັບຄັ້ງທໍາອິດ label=value. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຜ່ານຄູ່ທີ່ຍັງເຫຼືອທັງຫມົດ label=value ແລະໄດ້ຮັບຊຸດ metricIDs ທີ່ສອດຄ້ອງກັນສໍາລັບພວກເຂົາ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຊອກຫາທາງແຍກ.

ທຸກຢ່າງເບິ່ງຄືວ່າດີ, ແຕ່ມີຂໍ້ເສຍຕໍ່ກັບການແກ້ໄຂນີ້. VictoriaMetrics ໃນເບື້ອງຕົ້ນໄດ້ປະຕິບັດດັດສະນີ inverted ໂດຍອີງໃສ່ LevelDB. ແຕ່ໃນທີ່ສຸດຂ້ອຍຕ້ອງຍອມແພ້.

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

ໃນ LevelDB, ທຸກຄັ້ງທີ່ຟັງຊັນຖືກເອີ້ນ GetValues ທ່ານຈໍາເປັນຕ້ອງໄປໂດຍຜ່ານສາຍທັງຫມົດທີ່ເລີ່ມຕົ້ນດ້ວຍ label=value. ແລະໄດ້ຮັບມູນຄ່າສໍາລັບແຕ່ລະເສັ້ນ timeseries_ids. ຂອງດັ່ງກ່າວ timeseries_ids ເກັບກໍາຂໍ້ບາງສ່ວນຂອງເຫຼົ່ານີ້ timeseries_ids. ແນ່ນອນ, ນີ້ແມ່ນຊ້າກວ່າການເຂົ້າຫາແຜນທີ່ປົກກະຕິໂດຍຄີ.

ຂໍ້ບົກຜ່ອງທີສອງແມ່ນວ່າ LevelDB ຖືກຂຽນໄວ້ໃນ C. ການເອີ້ນຟັງຊັນ C ຈາກ Go ແມ່ນບໍ່ໄວຫຼາຍ. ມັນໃຊ້ເວລາຫຼາຍຮ້ອຍ nanoseconds. ນີ້ບໍ່ແມ່ນໄວຫຼາຍ, ເພາະວ່າເມື່ອປຽບທຽບກັບການໂທແບບປົກກະຕິທີ່ຂຽນໃນ go, ເຊິ່ງໃຊ້ເວລາ 1-5 nanoseconds, ຄວາມແຕກຕ່າງໃນການປະຕິບັດແມ່ນຫຼາຍສິບເທື່ອ. ສໍາລັບ VictoriaMetrics ນີ້ແມ່ນຂໍ້ບົກພ່ອງທີ່ຮ້າຍແຮງ :)

ດັ່ງນັ້ນຂ້າພະເຈົ້າໄດ້ຂຽນການປະຕິບັດຂອງຕົນເອງຂອງດັດສະນີ inverted. ແລະພຣະອົງໄດ້ໂທຫານາງ ຮວມ.

Mergeset ແມ່ນອີງໃສ່ໂຄງສ້າງຂໍ້ມູນ MergeTree. ໂຄງສ້າງຂໍ້ມູນນີ້ແມ່ນຢືມມາຈາກ ClickHouse. ແນ່ນອນ, mergeset ຄວນຖືກປັບແຕ່ງສໍາລັບການຊອກຫາໄວ timeseries_ids ອີງຕາມລະຫັດທີ່ໃຫ້. Mergeset ຖືກຂຽນທັງຫມົດໃນ Go. ທ່ານສາມາດເບິ່ງ ແຫຼ່ງ VictoriaMetrics ໃນ GitHub. ການປະຕິບັດການລວມຢູ່ໃນໂຟນເດີ /lib/mergeset. ເຈົ້າສາມາດພະຍາຍາມຄິດອອກວ່າມີຫຍັງເກີດຂຶ້ນຢູ່ທີ່ນັ້ນ.

API mergeset ແມ່ນຄ້າຍຄືກັນຫຼາຍກັບ LevelDB ແລະ RocksDB. ນັ້ນແມ່ນ, ມັນຊ່ວຍໃຫ້ທ່ານສາມາດບັນທຶກບັນທຶກໃຫມ່ຢູ່ທີ່ນັ້ນຢ່າງໄວວາແລະເລືອກເອົາບັນທຶກຢ່າງໄວວາໂດຍຄໍານໍາຫນ້າ.

ພວກເຮົາຈະເວົ້າກ່ຽວກັບຂໍ້ເສຍຂອງການປະສົມປະສານໃນພາຍຫຼັງ. ຕອນນີ້ໃຫ້ເວົ້າກ່ຽວກັບບັນຫາທີ່ເກີດຂື້ນກັບ VictoriaMetrics ໃນການຜະລິດໃນເວລາທີ່ປະຕິບັດດັດສະນີ inverted.

ເປັນຫຍັງພວກມັນຈຶ່ງເກີດຂື້ນ?

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

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

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

ແຕ່ວ່າບໍ່ແມ່ນທັງຫມົດ. ແຕ່ລະຫຼັກຂອງໂປເຊດເຊີສາມາດມີຫຼາຍລັດ, ເຊັ່ນວ່າ idle, ເມື່ອມັນບໍ່ເຮັດວຽກ. ແລະຍັງເຮັດວຽກຢູ່ໃນພື້ນທີ່ຜູ້ໃຊ້, ເຮັດວຽກຢູ່ໃນພື້ນທີ່ kernel ແລະລັດອື່ນໆ. ແລະແຕ່ລະລັດດັ່ງກ່າວຍັງສາມາດຖືກວັດແທກເປັນຊຸດເວລາແຍກຕ່າງຫາກ. ນີ້ຍັງເພີ່ມຈໍານວນແຖວ 7-8 ເທື່ອ.

ຈາກຫນຶ່ງ metrics ພວກເຮົາໄດ້ຮັບ 40 x 8 = 320 metrics ສໍາລັບພຽງແຕ່ຫນຶ່ງຄອມພິວເຕີ. ຄູນດ້ວຍ 100, ພວກເຮົາໄດ້ຮັບ 32 ແທນ 000.

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

ຂໍໃຫ້ພິຈາລະນາຢ່າງລະອຽດກ່ຽວກັບອັດຕາການປັ່ນປ່ວນສູງ. ແມ່ນຫຍັງເຮັດໃຫ້ອັດຕາ churn ສູງໃນການຜະລິດ? ເນື່ອງຈາກວ່າບາງຄວາມຫມາຍຂອງປ້າຍຊື່ແລະ tags ມີການປ່ຽນແປງຢ່າງຕໍ່ເນື່ອງ.

ຕົວຢ່າງ, ເອົາ Kubernetes, ເຊິ່ງມີແນວຄວາມຄິດ deployment, i.e. ເມື່ອເວີຊັນໃຫມ່ຂອງແອັບພລິເຄຊັນຂອງທ່ານຖືກເປີດຕົວ. ດ້ວຍເຫດຜົນບາງຢ່າງ, ຜູ້ພັດທະນາ Kubernetes ຕັດສິນໃຈເພີ່ມ id ການນຳໃຊ້ໃສ່ປ້າຍກຳກັບ.

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

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

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

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

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

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

ມີທາງເລືອກອື່ນເພື່ອແກ້ໄຂບັນຫານີ້. ນີ້ແມ່ນການເກັບຮັກສາສໍາລັບແຕ່ລະມື້ບັນຊີລາຍຊື່ແຍກຕ່າງຫາກຂອງ ids ຂອງຊຸດເວລາທີ່ເກີດຂຶ້ນໃນມື້ນັ້ນ.

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

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

ຂ້ອຍຕ້ອງຕໍ່ສູ້ກັບນາງ. ການຕໍ່ສູ້ແມ່ນວ່າໃນການປະຕິບັດນີ້, ທ່ານຍັງຈໍາເປັນຕ້ອງເລືອກຈໍານວນຂະຫນາດໃຫຍ່ຫຼາຍ timeseries_ids ສໍາ​ລັບ​ຂໍ້​ມູນ​ກ​່​ວາ​ໃນ​ເວ​ລາ​ທີ່​ດັດ​ຊະ​ນີ inverted ແມ່ນ​ການ​ແບ່ງ​ປັນ​ເວ​ລາ​.

ພວກເຮົາໄດ້ແກ້ໄຂບັນຫານີ້ແນວໃດ? ພວກ​ເຮົາ​ໄດ້​ແກ້​ໄຂ​ມັນ​ໃນ​ວິ​ທີ​ການ​ຕົ້ນ​ສະ​ບັບ - ໂດຍ​ການ​ເກັບ​ຮັກ​ສາ​ຕົວ​ລະ​ບຸ​ຊຸດ​ທີ່​ໃຊ້​ເວ​ລາ​ຫຼາຍ​ໃນ​ແຕ່​ລະ inverted index entry ແທນ​ທີ່​ຈະ​ເປັນ​ຕົວ​ລະ​ບຸ​ຫນຶ່ງ​. ນັ້ນແມ່ນ, ພວກເຮົາມີກຸນແຈ label=value, ເຊິ່ງເກີດຂຶ້ນໃນທຸກໆຊຸດເວລາ. ແລະໃນປັດຈຸບັນພວກເຮົາປະຫຍັດຫຼາຍ timeseries_ids ໃນ​ຫນຶ່ງ​ເຂົ້າ​.

ນີ້ແມ່ນຕົວຢ່າງ. ໃນເມື່ອກ່ອນພວກເຮົາມີ N entries, ແຕ່ໃນປັດຈຸບັນພວກເຮົາມີຫນຶ່ງ entries ທີ່ prefix ແມ່ນຄືກັນກັບອື່ນໆທັງຫມົດ. ສໍາລັບລາຍການທີ່ຜ່ານມາ, ຄ່າປະກອບມີ ids ຊຸດເວລາທັງຫມົດ.

ນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະເພີ່ມຄວາມໄວການສະແກນຂອງດັດຊະນີ inverted ດັ່ງກ່າວເຖິງ 10 ເທົ່າ. ແລະມັນອະນຸຍາດໃຫ້ພວກເຮົາຫຼຸດຜ່ອນການບໍລິໂພກຫນ່ວຍຄວາມຈໍາສໍາລັບ cache, ເພາະວ່າຕອນນີ້ພວກເຮົາເກັບຮັກສາສາຍ label=value ພຽງແຕ່ຄັ້ງດຽວໃນ cache ຮ່ວມກັນ N ຄັ້ງ. ແລະເສັ້ນນີ້ສາມາດມີຂະຫນາດໃຫຍ່ຖ້າທ່ານເກັບຮັກສາເສັ້ນຍາວຢູ່ໃນປ້າຍຊື່ແລະປ້າຍຊື່ຂອງທ່ານ, ເຊິ່ງ Kubernetes ມັກຈະ shove ຢູ່ທີ່ນັ້ນ.

ທາງເລືອກອື່ນສໍາລັບການເລັ່ງການຄົ້ນຫາໃນດັດສະນີ inverted ແມ່ນ sharding. ການສ້າງດັດສະນີ inverted ຫຼາຍແທນທີ່ຈະເປັນຫນຶ່ງແລະ sharding ຂໍ້ມູນລະຫວ່າງເຂົາເຈົ້າໂດຍທີ່ສໍາຄັນ. ນີ້ແມ່ນຊຸດ key=value ອາຍ. ນັ້ນແມ່ນ, ພວກເຮົາໄດ້ຮັບດັດສະນີ inverted ເອກະລາດຫຼາຍອັນ, ເຊິ່ງພວກເຮົາສາມາດສອບຖາມໃນຂະຫນານໃນຫຼາຍໆໂປເຊດເຊີ. ການປະຕິບັດທີ່ຜ່ານມາອະນຸຍາດໃຫ້ດໍາເນີນການພຽງແຕ່ໃນໂຫມດໂປເຊດເຊີດຽວ, i.e., ການສະແກນຂໍ້ມູນໃນແກນດຽວເທົ່ານັ້ນ. ການ​ແກ້​ໄຂ​ນີ້​ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ​ສາ​ມາດ​ສະ​ແກນ​ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ຫຼາຍ​ຫຼັກ​ໃນ​ເວ​ລາ​ດຽວ​ກັນ​, ເປັນ ClickHouse ມັກ​ເຮັດ​. ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາວາງແຜນທີ່ຈະປະຕິບັດ.

ຕອນນີ້ໃຫ້ກັບຄືນໄປຫາແກະຂອງພວກເຮົາ - ກັບຫນ້າທີ່ຕັດກັນ timeseries_ids. ຂໍ​ໃຫ້​ພິຈາລະນາ​ວ່າ​ມີ​ການ​ປະຕິບັດ​ອັນ​ໃດ​ແດ່. ຟັງຊັນນີ້ອະນຸຍາດໃຫ້ທ່ານຊອກຫາ timeseries_ids ສໍາລັບຊຸດທີ່ກໍານົດໄວ້ label=value.

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

ການ​ປະ​ຕິ​ບັດ naive ຄື​ແນວ​ນີ້. ພວກເຮົາ iterate ຫຼາຍກວ່າມູນຄ່າທັງຫມົດຈາກ slice a, ພາຍໃນ loop ນີ້ພວກເຮົາໄປໂດຍຜ່ານມູນຄ່າທັງຫມົດຂອງ slice b. ແລະພວກເຮົາປຽບທຽບພວກມັນ. ຖ້າພວກເຂົາກົງກັນ, ຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ພົບເຫັນສີ່ແຍກ. ແລະບັນທຶກມັນຢູ່ໃນ result.

ຂໍ້ເສຍແມ່ນຫຍັງ? ຄວາມຊັບຊ້ອນສີ່ຫຼ່ຽມແມ່ນຂໍ້ເສຍຫຼັກຂອງມັນ. ຕົວຢ່າງ, ຖ້າຂະຫນາດຂອງເຈົ້າຖືກຕັດ a и b ຫນຶ່ງລ້ານຕໍ່ຄັ້ງ, ຫຼັງຈາກນັ້ນຟັງຊັນນີ້ຈະບໍ່ຕອບຄໍາຕອບໃຫ້ທ່ານ. ເນື່ອງຈາກວ່າມັນຈະຕ້ອງເຮັດໃຫ້ຫນຶ່ງພັນຕື້ iterations, ຊຶ່ງເປັນຫຼາຍເຖິງແມ່ນວ່າສໍາລັບຄອມພິວເຕີທີ່ທັນສະໄຫມ.

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

ຜົນປະໂຫຍດແມ່ນຫຍັງ? ຂໍ້ໄດ້ປຽບແມ່ນວ່າມີພຽງແຕ່ສະລັບສັບຊ້ອນເສັ້ນ. ນັ້ນແມ່ນ, ຟັງຊັນຈະປະຕິບັດໄດ້ໄວຂຶ້ນຫຼາຍສໍາລັບຕ່ອນໃຫຍ່. ສໍາລັບຕ່ອນຂະຫນາດລ້ານ, ຟັງຊັນນີ້ຈະປະຕິບັດໃນ 2 ລ້ານ iterations, ກົງກັນຂ້າມກັບ trillion iterations ຂອງຟັງຊັນທີ່ຜ່ານມາ.

ຂໍ້ເສຍແມ່ນວ່າຟັງຊັນນີ້ຕ້ອງການຄວາມຊົງຈໍາຫຼາຍເພື່ອສ້າງແຜນທີ່ນີ້.

ຂໍ້ເສຍປຽບທີສອງແມ່ນ overhead ຂະຫນາດໃຫຍ່ສໍາລັບການ hashing. ຂໍ້ບົກຜ່ອງນີ້ບໍ່ຊັດເຈນຫຼາຍ. ແລະສໍາລັບພວກເຮົາມັນຍັງບໍ່ຊັດເຈນຫຼາຍ, ດັ່ງນັ້ນໃນຕອນທໍາອິດໃນ VictoriaMetrics ການປະຕິບັດທາງຕັດແມ່ນຜ່ານແຜນທີ່. ແຕ່ຫຼັງຈາກນັ້ນ profileing ສະແດງໃຫ້ເຫັນວ່າເວລາຂອງໂປເຊດເຊີຕົ້ນຕໍແມ່ນໃຊ້ເວລາຂຽນລົງໃນແຜນທີ່ແລະກວດສອບການມີຄ່າໃນແຜນທີ່ນີ້.

ເປັນຫຍັງເວລາ CPU ຈຶ່ງເສຍໄປໃນສະຖານທີ່ເຫຼົ່ານີ້? ເນື່ອງຈາກວ່າ Go ດໍາເນີນການ hashing ໃນສາຍເຫຼົ່ານີ້. ນັ້ນແມ່ນ, ມັນຄິດໄລ່ hash ຂອງປຸ່ມເພື່ອເຂົ້າຫາມັນຢູ່ໃນດັດຊະນີທີ່ກໍານົດໄວ້ໃນ HashMap. ການ​ປະ​ຕິ​ບັດ​ການ​ຄິດ​ໄລ່ hash ແມ່ນ​ສໍາ​ເລັດ​ໃນ​ສິບ​ນາ​ໂນ​ວິ​ນາ​ທີ​. ນີ້ແມ່ນຊ້າສໍາລັບ VictoriaMetrics.

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

ຢູ່ glance ທໍາອິດ, ມັນເບິ່ງຄືວ່ານີ້ຄວນຈະເຮັດວຽກຊ້າລົງ, ຖ້າກ່ອນຫນ້ານີ້ແຜນທີ່ມາດຕະຖານຖືກນໍາໃຊ້ຢູ່ທີ່ນັ້ນ, ແລະຫຼັງຈາກນັ້ນບາງຫນ້າທີ່ເອີ້ນວ່າ, ແຕ່ profileing ສະແດງໃຫ້ເຫັນວ່າສິ່ງນີ້ເຮັດວຽກໄວກວ່າແຜນທີ່ມາດຕະຖານ 10 ເທົ່າໃນກໍລະນີຂອງ VictoriaMetrics.

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

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

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

ໃຫ້ພິຈາລະນາການປະຕິບັດໂຄງສ້າງນີ້. ຖ້າທ່ານຕ້ອງການເບິ່ງ, ມັນຕັ້ງຢູ່ໃນແຫຼ່ງ VictoriaMetrics, ໃນໂຟນເດີ lib/uint64set. ມັນໄດ້ຖືກປັບປຸງໂດຍສະເພາະສໍາລັບກໍລະນີ VictoriaMetrics, ບ່ອນທີ່ timeseries_id ແມ່ນຄ່າ 64-bit, ບ່ອນທີ່ 32 bits ທໍາອິດແມ່ນຄົງທີ່ໂດຍພື້ນຖານແລ້ວແລະພຽງແຕ່ 32 bits ສຸດທ້າຍມີການປ່ຽນແປງ.

ໂຄງສ້າງຂໍ້ມູນນີ້ບໍ່ໄດ້ຖືກເກັບໄວ້ໃນແຜ່ນ, ມັນພຽງແຕ່ດໍາເນີນການຢູ່ໃນຫນ່ວຍຄວາມຈໍາ.

ນີ້ແມ່ນ API ຂອງມັນ. ມັນບໍ່ສັບສົນຫຼາຍ. API ແມ່ນປັບແຕ່ງສະເພາະກັບຕົວຢ່າງສະເພາະຂອງການໃຊ້ VictoriaMetrics. ນັ້ນແມ່ນ, ບໍ່ມີຫນ້າທີ່ທີ່ບໍ່ຈໍາເປັນຢູ່ທີ່ນີ້. ນີ້ແມ່ນຫນ້າທີ່ຖືກນໍາໃຊ້ຢ່າງຊັດເຈນໂດຍ VictoriaMetrics.

ມີຫນ້າທີ່ add, ເຊິ່ງເພີ່ມມູນຄ່າໃຫມ່. ມີຫນ້າທີ່ has, ເຊິ່ງກວດສອບຄ່າໃຫມ່. ແລະມີຫນ້າທີ່ del, ເຊິ່ງເອົາຄ່າ. ມີຫນ້າທີ່ຜູ້ຊ່ວຍ len, ເຊິ່ງສົ່ງຄືນຂະຫນາດຂອງຊຸດ. ຟັງຊັນ clone clones ຫຼາຍ. ແລະຫນ້າທີ່ appendto ປ່ຽນຊຸດນີ້ເປັນຊອຍ timeseries_ids.

ນີ້ແມ່ນສິ່ງທີ່ການປະຕິບັດໂຄງສ້າງຂໍ້ມູນນີ້ເບິ່ງຄືວ່າ. ຊຸດ​ມີ​ສອງ​ອົງ​ປະ​ກອບ​:

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

• ພາກສະຫນາມທີສອງແມ່ນ buckets. ນີ້ແມ່ນ slice ຈາກໂຄງສ້າງ bucket32. ແຕ່ລະໂຄງສ້າງເກັບຮັກສາ hi ພາກສະຫນາມ. ເຫຼົ່ານີ້ແມ່ນ 32 bits ເທິງ. ແລະສອງຕ່ອນ - b16his и buckets ຈາກນັ້ນ bucket16 ໂຄງສ້າງ.

ເທິງ 16 bits ຂອງສ່ວນທີສອງຂອງໂຄງສ້າງ 64-bit ແມ່ນເກັບໄວ້ທີ່ນີ້. ແລະນີ້ bitsets ຖືກເກັບໄວ້ສໍາລັບ 16 bits ຕ່ໍາຂອງແຕ່ລະ byte.

Bucket64 ປະກອບດ້ວຍອາເຣ uint64. ຄວາມຍາວແມ່ນຄິດໄລ່ໂດຍໃຊ້ຄ່າຄົງທີ່ເຫຼົ່ານີ້. ໃນຫນຶ່ງ bucket16 ສູງສຸດສາມາດເກັບຮັກສາໄດ້ 2^16=65536 ນ້ອຍ. ຖ້າເຈົ້າແບ່ງອັນນີ້ດ້ວຍ 8, ມັນແມ່ນ 8 ກິໂລໄບ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຫານ​ໂດຍ 8 ອີກ​ເທື່ອ​ຫນຶ່ງ​, ມັນ​ເປັນ 1000​ uint64 ຄວາມ​ຫມາຍ. ນັ້ນ​ແມ່ນ Bucket16 - ນີ້ແມ່ນໂຄງສ້າງ 8 ກິໂລແມັດຂອງພວກເຮົາ.

ຂໍໃຫ້ພິຈາລະນາວິທີການຫນຶ່ງຂອງໂຄງສ້າງນີ້ສໍາລັບການເພີ່ມມູນຄ່າໃຫມ່ຖືກປະຕິບັດ.

ມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍ uint64 ຄວາມ​ຫມາຍ. ພວກເຮົາຄິດໄລ່ 32 bits ເທິງ, ພວກເຮົາຄິດໄລ່ 32 bits ຕ່ໍາ. ຂໍໃຫ້ຜ່ານທຸກສິ່ງທຸກຢ່າງ buckets. ພວກເຮົາປຽບທຽບ 32 bits ເທິງສຸດໃນແຕ່ລະ bucket ກັບມູນຄ່າທີ່ຖືກເພີ່ມ. ແລະຖ້າພວກເຂົາກົງກັນ, ຫຼັງຈາກນັ້ນພວກເຮົາໂທຫາຫນ້າທີ່ add ໃນໂຄງສ້າງ b32 buckets. ແລະເພີ່ມ 32 bits ຕ່ໍາຢູ່ທີ່ນັ້ນ. ແລະຖ້າມັນກັບຄືນມາ true, ນີ້ຫມາຍຄວາມວ່າພວກເຮົາໄດ້ເພີ່ມມູນຄ່າດັ່ງກ່າວຢູ່ທີ່ນັ້ນແລະພວກເຮົາບໍ່ມີຄ່າດັ່ງກ່າວ. ຖ້າມັນກັບຄືນມາ false, ຫຼັງຈາກນັ້ນຄວາມຫມາຍດັ່ງກ່າວມີຢູ່ແລ້ວ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາເພີ່ມຈໍານວນຂອງອົງປະກອບໃນໂຄງສ້າງ.

ຖ້າພວກເຮົາບໍ່ພົບອັນທີ່ທ່ານຕ້ອງການ bucket ດ້ວຍຄ່າສູງທີ່ຕ້ອງການ, ຫຼັງຈາກນັ້ນພວກເຮົາໂທຫາຟັງຊັນ addAlloc, ເຊິ່ງຈະຜະລິດໃຫມ່ bucket, ເພີ່ມມັນກັບໂຄງສ້າງ bucket.

ນີ້ແມ່ນການປະຕິບັດຫນ້າທີ່ b32.add. ມັນຄ້າຍຄືກັບການປະຕິບັດທີ່ຜ່ານມາ. ພວກເຮົາຄິດໄລ່ 16 bits ທີ່ສໍາຄັນທີ່ສຸດ, ຫນ້ອຍທີ່ສຸດ 16 bits.

ຫຼັງຈາກນັ້ນ, ພວກເຮົາໄປໂດຍຜ່ານທັງຫມົດເທິງ 16 bits. ພວກເຮົາຊອກຫາການແຂ່ງຂັນ. ແລະຖ້າມີການແຂ່ງຂັນ, ພວກເຮົາໂທຫາວິທີການເພີ່ມ, ເຊິ່ງພວກເຮົາຈະພິຈາລະນາໃນຫນ້າຕໍ່ໄປ bucket16.

ແລະນີ້ແມ່ນລະດັບຕໍ່າສຸດ, ເຊິ່ງຄວນຈະຖືກປັບປຸງໃຫ້ດີທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້. ພວກເຮົາຄິດໄລ່ສໍາລັບ uint64 ຄ່າ id ໃນ slice bit ແລະ bitmask. ນີ້ແມ່ນຫນ້າກາກສໍາລັບຄ່າ 64-bit ທີ່ໃຫ້, ເຊິ່ງສາມາດນໍາໃຊ້ເພື່ອກວດເບິ່ງການປະກົດຕົວຂອງບິດນີ້, ຫຼືຕັ້ງມັນ. ພວກເຮົາກວດເບິ່ງເພື່ອເບິ່ງວ່າບິດນີ້ຖືກຕັ້ງແລະຕັ້ງມັນ, ແລະກັບຄືນມາ. ນີ້ແມ່ນການປະຕິບັດຂອງພວກເຮົາ, ເຊິ່ງອະນຸຍາດໃຫ້ພວກເຮົາເລັ່ງການດໍາເນີນງານຂອງ intersecting ids ຂອງຊຸດເວລາໂດຍ 10 ເທື່ອເມື່ອທຽບກັບແຜນທີ່ທໍາມະດາ.

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

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

ຂ້ອຍມີຄໍາຖາມກ່ຽວກັບ bitset. ຄ້າຍຄືກັນກັບການປະຕິບັດ C++ vector bool, optimized bitset. ເຈົ້າເອົາການຈັດຕັ້ງປະຕິບັດຈາກບ່ອນນັ້ນບໍ?

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

ຂ້າພະເຈົ້າຍັງແນະນໍາໃຫ້ທ່ານເບິ່ງບົດລາຍງານຂອງ Alexey Milovid. ປະມານຫນຶ່ງເດືອນກ່ອນຫນ້ານີ້, ລາວໄດ້ເວົ້າກ່ຽວກັບການເພີ່ມປະສິດທິພາບໃນ ClickHouse ສໍາລັບການພິເສດສະເພາະ. ລາວພຽງແຕ່ເວົ້າວ່າໃນກໍລະນີທົ່ວໄປ, ການປະຕິບັດ C ++ ຫຼືບາງການປະຕິບັດອື່ນໆແມ່ນເຫມາະສົມກັບການປະຕິບັດທີ່ດີໂດຍສະເລ່ຍໃນໂຮງຫມໍ. ມັນອາດຈະປະຕິບັດຮ້າຍແຮງກວ່າການປະຕິບັດຄວາມຮູ້ສະເພາະເຊັ່ນພວກເຮົາ, ບ່ອນທີ່ພວກເຮົາຮູ້ວ່າ 32 bits ສູງສຸດແມ່ນຄົງທີ່.

ຂ້ອຍມີຄໍາຖາມທີສອງ. ຄວາມແຕກຕ່າງພື້ນຖານຈາກ InfluxDB ແມ່ນຫຍັງ?

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

ຄວາມແຕກຕ່າງພື້ນຖານທີສອງແມ່ນວ່າ InfluxDB ມີພາສາສອບຖາມທີ່ແປກປະຫຼາດ - Flux ແລະ InfluxQL. ພວກເຂົາເຈົ້າແມ່ນບໍ່ສະດວກຫຼາຍສໍາລັບການເຮັດວຽກກັບຊຸດເວລາເມື່ອທຽບກັບ PromQL, ເຊິ່ງສະຫນັບສະຫນູນໂດຍ VictoriaMetrics. PromQL ເປັນພາສາສອບຖາມຈາກ Prometheus.

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

ໃນ VictoriaMetrics ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍຫຼາຍ. ຢູ່ທີ່ນັ້ນ, ແຕ່ລະຊຸດເວລາເປັນຄ່າຫຼັກ. ມູນຄ່າແມ່ນຊຸດຂອງຈຸດ - (timestamp, value), ແລະທີ່ສໍາຄັນແມ່ນຊຸດ label=value. ບໍ່ມີການແຍກລະຫວ່າງທົ່ງນາແລະການວັດແທກ. ມັນຊ່ວຍໃຫ້ທ່ານສາມາດເລືອກຂໍ້ມູນໃດໆແລະຫຼັງຈາກນັ້ນສົມທົບ, ເພີ່ມ, ລົບ, ຄູນ, ແບ່ງ, ບໍ່ເຫມືອນກັບ InfluxDB ບ່ອນທີ່ການຄິດໄລ່ລະຫວ່າງແຖວຕ່າງໆຍັງບໍ່ຖືກປະຕິບັດເທົ່າທີ່ຂ້ອຍຮູ້. ເຖິງແມ່ນວ່າພວກເຂົາຖືກປະຕິບັດ, ມັນເປັນການຍາກ, ທ່ານຕ້ອງຂຽນລະຫັດຫຼາຍ.

ຂ້ອຍມີຄຳຖາມທີ່ຊີ້ແຈງ. ຂ້ອຍເຂົ້າໃຈຢ່າງຖືກຕ້ອງບໍວ່າມີບັນຫາບາງຢ່າງທີ່ເຈົ້າເວົ້າກ່ຽວກັບ, ວ່າດັດສະນີ inverted ນີ້ບໍ່ເຫມາະສົມກັບຫນ່ວຍຄວາມຈໍາ, ດັ່ງນັ້ນມີການແບ່ງສ່ວນຢູ່ທີ່ນັ້ນ?

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

ສະບາຍດີ! ຂອບໃຈສໍາລັບບົດລາຍງານ! ຂ້ອຍຊື່ Pavel. ຂ້ອຍມາຈາກ Wildberries. ຂ້ອຍມີຄຳຖາມບາງອັນສຳລັບເຈົ້າ. ຄໍາຖາມຫນຶ່ງ. ທ່ານຄິດວ່າຖ້າທ່ານໄດ້ເລືອກຫຼັກການທີ່ແຕກຕ່າງກັນໃນເວລາສ້າງສະຖາປັດຕະຍະກໍາຂອງຄໍາຮ້ອງສະຫມັກຂອງທ່ານແລະແບ່ງສ່ວນຂໍ້ມູນໃນໄລຍະເວລາ, ບາງທີທ່ານອາດຈະສາມາດຕັດຂໍ້ມູນໃນເວລາຄົ້ນຫາ, ອີງໃສ່ຄວາມຈິງທີ່ວ່າຫນຶ່ງພາທິຊັນມີຂໍ້ມູນສໍາລັບຫນຶ່ງ. ໄລຍະເວລາ, ນັ້ນແມ່ນ, ໃນໄລຍະເວລາຫນຶ່ງແລະທ່ານຈະບໍ່ຕ້ອງກັງວົນກ່ຽວກັບຄວາມຈິງທີ່ວ່າຊິ້ນສ່ວນຂອງເຈົ້າຖືກກະແຈກກະຈາຍແຕກຕ່າງກັນບໍ? ຄໍາຖາມທີ 2 - ນັບຕັ້ງແຕ່ທ່ານກໍາລັງປະຕິບັດ algorithm ທີ່ຄ້າຍຄືກັນກັບ bitset ແລະສິ່ງອື່ນໆ, ບາງທີເຈົ້າອາດຈະພະຍາຍາມໃຊ້ຄໍາແນະນໍາຂອງໂປເຊດເຊີ? ບາງທີເຈົ້າໄດ້ພະຍາຍາມເພີ່ມປະສິດທິພາບດັ່ງກ່າວບໍ?

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

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

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

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

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

ເປັນຫຍັງພວກເຮົາບໍ່ໃຊ້ຕົວກະພິບເພື່ອຂ້າມຂໍ້ມູນ?

ແມ່ນແລ້ວ.

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

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

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

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

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

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

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

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

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

ລັກສະນະອື່ນແມ່ນວ່າ VictoriaMetrics ບີບອັດຂໍ້ມູນນີ້ຢ່າງມີປະສິດທິພາບ. ການບີບອັດໂດຍສະເລ່ຍໃນການຜະລິດແມ່ນຈາກ 0,4 ຫາ 0,8 bytes ຕໍ່ຈຸດ. ແຕ່ລະຈຸດແມ່ນເວລາ + ຄ່າ. ແລະມັນຖືກບີບອັດເຂົ້າໄປໃນຫນ້ອຍກວ່າຫນຶ່ງ byte ໂດຍສະເລ່ຍ.

Sergey. ຂ້ອຍ​ມີ​ຄໍາ​ຖາມ. quantum ທີ່ໃຊ້ເວລາບັນທຶກຕໍາ່ສຸດແມ່ນຫຍັງ?

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

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

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

ຂອບ​ໃຈ! ແລະຄໍາຖາມອື່ນ. ຄວາມເຂົ້າກັນໄດ້ໃນ PromQL ແມ່ນຫຍັງ?

ຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງເຕັມ. VictoriaMetrics ສະຫນັບສະຫນູນ PromQL ຢ່າງເຕັມສ່ວນ. ນອກຈາກນັ້ນ, ມັນເພີ່ມຫນ້າທີ່ກ້າວຫນ້າທາງດ້ານເພີ່ມເຕີມໃນ PromQL, ເຊິ່ງເອີ້ນວ່າ MetricsQL. ມີການສົນທະນາໃນ YouTube ກ່ຽວກັບຫນ້າທີ່ຂະຫຍາຍນີ້. ຂ້າພະເຈົ້າໄດ້ເວົ້າຢູ່ໃນກອງປະຊຸມ Monitoring Meetup ໃນພາກຮຽນ spring ໃນ St.

ຊ່ອງທາງ Telegram VictoriaMetrics.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ແມ່ນຫຍັງທີ່ຂັດຂວາງທ່ານຈາກການປ່ຽນໄປໃຊ້ VictoriaMetrics ເປັນການເກັບຮັກສາໄລຍະຍາວຂອງທ່ານສໍາລັບ Prometheus? (ຂຽນໃນຄໍາເຫັນ, ຂ້ອຍຈະເພີ່ມມັນໃສ່ແບບສໍາຫຼວດ))

• 71,4%ຂ້ອຍບໍ່ໃຊ້ Prometheus5

• 28,6%ບໍ່ຮູ້ກ່ຽວກັບ VictoriaMetrics2

7 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 12 ຜູ້ໃຊ້ງົດ.

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