ຄວາມໂກດແຄ້ນ, ການຕໍ່ລອງແລະການຊຶມເສົ້າໃນເວລາທີ່ເຮັດວຽກກັບ InfluxDB

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

ຂໍ້ສັງເກດ: ບັນຫາທີ່ລະບຸໄວ້ໃຊ້ກັບ InfluxDB ເວີຊັນ 1.7.4.

ເປັນຫຍັງຊຸດເວລາ?

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

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

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

ມັນເປັນການສັບສົນເລັກນ້ອຍທີ່ຖານຂໍ້ມູນດັ່ງກ່າວປົກກະຕິແລ້ວຖືກນໍາໃຊ້ເພື່ອຈຸດປະສົງຂອງການເກັບກໍາ metrics. ການຕິດຕາມເຄື່ອງແມ່ຂ່າຍ, ອຸປະກອນ iot, ທຸກສິ່ງທຸກຢ່າງຈາກຈຸດຫຼາຍລ້ານຈຸດຂອງຮູບແບບ "ການໄຫຼ": [<time> - <metric value>]. ແຕ່ຖ້າຖານຂໍ້ມູນເຮັດວຽກໄດ້ດີກັບການໄຫລຂອງຂໍ້ມູນຂະຫນາດໃຫຍ່, ແລ້ວເປັນຫຍັງປະລິມານຂະຫນາດນ້ອຍຄວນເຮັດໃຫ້ເກີດບັນຫາ? ດ້ວຍຄວາມຄິດນີ້, ພວກເຮົາໄດ້ເອົາ InfluxDB ໄປເຮັດວຽກ.

ສິ່ງອື່ນທີ່ສະດວກໃນ InfluxDB

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

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

1. ສ້າງແບບສອບຖາມຢ່າງຕໍ່ເນື່ອງເພື່ອລວບລວມຂໍ້ມູນເຂົ້າໄປໃນຕາຕະລາງອື່ນ;
2. ສໍາລັບຕາຕະລາງທໍາອິດ, ກໍານົດນະໂຍບາຍສໍາລັບການລຶບ metrics ທີ່ເກົ່າກວ່າອາທິດດຽວກັນນັ້ນ.

ແລະ Influx ເປັນເອກະລາດຈະຫຼຸດຜ່ອນຂະຫນາດຂອງຂໍ້ມູນແລະລຶບສິ່ງທີ່ບໍ່ຈໍາເປັນ.

ກ່ຽວກັບຂໍ້ມູນທີ່ເກັບໄວ້

ບໍ່ໄດ້ເກັບຮັກສາຂໍ້ມູນຫຼາຍ: ປະມານ 70 ພັນທຸລະກໍາແລະອີກລ້ານຈຸດທີ່ມີຂໍ້ມູນຕະຫຼາດ. ເພີ່ມລາຍການໃຫມ່ - ບໍ່ເກີນ 3000 ຈຸດຕໍ່ມື້. ຍັງມີ metrics ສໍາລັບເວັບໄຊທ໌, ແຕ່ມີຂໍ້ມູນຫນ້ອຍຢູ່ທີ່ນັ້ນແລະ, ອີງຕາມນະໂຍບາຍການເກັບຮັກສາ, ພວກມັນຖືກເກັບໄວ້ບໍ່ເກີນຫນຶ່ງເດືອນ.

ບັນຫາ

ໃນລະຫວ່າງການພັດທະນາແລະການທົດສອບການບໍລິການຕໍ່ມາ, ບັນຫາທີ່ສໍາຄັນຫຼາຍຂື້ນເກີດຂື້ນໃນການດໍາເນີນງານຂອງ InfluxDB.

1. ການລຶບຂໍ້ມູນ

ມີຊຸດຂໍ້ມູນທີ່ມີທຸລະກໍາ:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

ຜົນໄດ້ຮັບ:

ຂ້ອຍກໍາລັງສົ່ງຄໍາສັ່ງເພື່ອລຶບຂໍ້ມູນ:

DELETE FROM transactions WHERE symbol=’USDT’

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

ຂ້ອຍພະຍາຍາມລຶບຕາຕະລາງທັງໝົດ:

DROP MEASUREMENT transactions

ຂ້ອຍກວດເບິ່ງການລຶບຕາຕະລາງ:

SHOW MEASUREMENTS

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

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

ດັ່ງນັ້ນ, ການລຶບແລະຫຼັງຈາກນັ້ນການຟື້ນຟູຖານຂໍ້ມູນທັງຫມົດຊ່ວຍ.

2. ຕົວເລກຈຸດລອຍ

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

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

3. ການສອບຖາມຢ່າງຕໍ່ເນື່ອງບໍ່ສາມາດປັບຕົວເຂົ້າກັບເຂດເວລາທີ່ແຕກຕ່າງກັນ

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

ໃນ InfluxDB, ເມື່ອຈັດກຸ່ມຕາມເວລາ, ທ່ານສາມາດກໍານົດການປ່ຽນແປງ, ຕົວຢ່າງສໍາລັບເວລາ Moscow (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

ແຕ່ຜົນການສອບຖາມຈະບໍ່ຖືກຕ້ອງ. ດ້ວຍເຫດຜົນບາງຢ່າງ, ຂໍ້ມູນທີ່ຖືກຈັດເປັນກຸ່ມໂດຍມື້ຈະເລີ່ມຕົ້ນທັງຫມົດກັບຄືນໄປບ່ອນ 1677 (InfluxDB ຢ່າງເປັນທາງການສະຫນັບສະຫນູນໄລຍະເວລາຈາກປີນີ້):

ເພື່ອແກ້ໄຂບັນຫານີ້, ພວກເຮົາໄດ້ປ່ຽນການບໍລິການເປັນ UTC+0 ຊົ່ວຄາວ.

4. ການປະຕິບັດ

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

ຂ້ອຍຈະບອກເຈົ້າກໍລະນີຂອງຂ້ອຍ.

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

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

ຄຳ ອະທິບາຍ:

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

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

ຂ້ອຍໄດ້ດໍາເນີນການທົດສອບຄວາມກົດດັນໃນວິທີການ API ນີ້. ສໍາລັບ 25 RPS, ເຄື່ອງແມ່ຂ່າຍໄດ້ສະແດງໃຫ້ເຫັນການໂຫຼດເຕັມຂອງຫົກ CPU:

ໃນເວລາດຽວກັນ, ຂະບວນການ NodeJs ບໍ່ໄດ້ສະຫນອງການໂຫຼດໃດໆ.

ຄວາມໄວການປະຕິບັດໄດ້ຫຼຸດລົງແລ້ວໂດຍ 7-10 RPS: ຖ້າລູກຄ້າຄົນຫນຶ່ງສາມາດໄດ້ຮັບການຕອບສະຫນອງໃນ 200 ms, ຫຼັງຈາກນັ້ນ 10 ລູກຄ້າຕ້ອງລໍຖ້າວິນາທີ. 25 RPS ແມ່ນຂອບເຂດຈໍາກັດທີ່ຄວາມຫມັ້ນຄົງໄດ້ຮັບຄວາມເສຍຫາຍ; 500 ຂໍ້ຜິດພາດຖືກສົ່ງຄືນໃຫ້ລູກຄ້າ.

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

ສະຫລຸບ

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

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

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

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