ClickHouse ສໍາລັບຜູ້ໃຊ້ຂັ້ນສູງໃນຄໍາຖາມແລະຄໍາຕອບ

ໃນເດືອນເມສາ, ວິສະວະກອນ Avito ໄດ້ເຕົ້າໂຮມກັນສໍາລັບກອງປະຊຸມອອນໄລນ໌ກັບຜູ້ພັດທະນາ ClickHouse ຕົ້ນຕໍ Alexey Milovidov ແລະ Kirill Shvakov, ຜູ້ພັດທະນາ Golang ຈາກ Integros. ພວກເຮົາໄດ້ປຶກສາຫາລືກ່ຽວກັບວິທີທີ່ພວກເຮົານໍາໃຊ້ລະບົບການຄຸ້ມຄອງຖານຂໍ້ມູນແລະສິ່ງທີ່ພວກເຮົາພົບຄວາມຫຍຸ້ງຍາກ.

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

ຈົ່ງລະມັດລະວັງ, ມີຫຼາຍຂໍ້ຄວາມພາຍໃຕ້ການຕັດ. ພວກເຮົາຫວັງວ່າເນື້ອໃນທີ່ມີຄໍາຖາມຈະຊ່ວຍໃຫ້ທ່ານນໍາທາງ.

ເນື້ອໃນ

• ClickHouse ແມ່ນການປັບປຸງຢ່າງຕໍ່ເນື່ອງ, ແຕ່ຂໍ້ມູນຂອງພວກເຮົາບໍ່ແມ່ນ. ຈະເຮັດແນວໃດກ່ຽວກັບມັນ?
• ການປະຕິບັດທີ່ດີທີ່ສຸດໃນປະຈຸບັນສໍາລັບການສໍາຮອງຂໍ້ມູນຂໍ້ມູນຈາກ ClickHouse ແມ່ນຫຍັງ?
• ມັນເປັນໄປໄດ້ທີ່ຈະຈັດລະບຽບ lag ຂອງ replicas ຄວບຄຸມໃນ shafts ໄດ້?
• ຈະເປັນແນວໃດຖ້າໂຄງສ້າງຕາຕະລາງມີການປ່ຽນແປງ?
• ການປະຕິບັດທີ່ດີທີ່ສຸດໃນການສົ່ງຕໍ່ຂໍ້ມູນໃນປະຈຸບັນແມ່ນຫຍັງ?
• ClickHouse ມີປະໂຫຍດຂອງ clickhouse-copier. ເຈົ້າສາມາດບອກຂ້ອຍກ່ຽວກັບນາງໄດ້ບໍ?
• ທ່ານມີສິ່ງທົດລອງທີ່ເອີ້ນວ່າ resharding. ແມ່ນຫຍັງກັບນາງ?
• ມັນເປັນໄປໄດ້ບໍທີ່ຈະລວມຂໍ້ມູນທັງໝົດເຂົ້າກັນກ່ອນທີ່ຈະຍ້າຍມັນໄປໃສ່ແຜ່ນຊ້າ?
• ວິທີການຍ້າຍໄປຍັງ ClickHouse ຮຸ່ນໃຫມ່ຖ້າບໍ່ມີວິທີການກວດສອບຄວາມເຂົ້າກັນໄດ້ລ່ວງຫນ້າ?
• Kill query ແມ່ນ supposed ທີ່ຈະຂ້າ queries, ແຕ່ມັນບໍ່. ເປັນຫຍັງ?
• ວິທີການຄິດໄລ່ເວລາຕອບສະຫນອງພາຍໃຕ້ການອ່ານການໂຫຼດ?
• ຂ້ອຍສາມາດປັບແຕ່ງຫຍັງໃນ ClickHouse ເພື່ອໃຫ້ມີຂໍ້ມູນຫຼາຍຂຶ້ນຢູ່ໃນແຄດ?
• ຂ້ອຍສາມາດຕັ້ງຄ່າ storage_configuration ສໍາລັບການເກັບຮັກສາໃນ RAM ໄດ້ແນວໃດ?
• ເຖິງວ່າຈໍານວນຄ່າທີ່ເປັນເອກະລັກແມ່ນ Low Cardinality ມີປະສິດທິພາບແນວໃດ?
• ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການຊອກຫາຂໍ້ຄວາມເຕັມຕາຕະລາງທີ່ມີຫ້າພັນລ້ານແຖວແມ່ນຫຍັງ?
• ວິທີທີ່ດີທີ່ສຸດໃນການຈັດລະບຽບການເຂົ້າເຖິງ ClickHouse ສໍາລັບຈໍານວນຜູ້ໃຊ້ຈໍານວນຫລາຍແມ່ນຫຍັງ?
• ມັນເປັນໄປໄດ້ທີ່ຈະໃຫ້ຜົນໄດ້ຮັບຂອງການສອບຖາມຫນຶ່ງໃຫ້ກັບລູກຄ້າສິບຄົນ?
• ຈະເປັນແນວໃດກ່ຽວກັບການດໍາເນີນງານ asynchronous ແລະ views materialized?
• ClickHouse ມີຫຼາຍບັນທຶກ. ຂ້ອຍຈະເຫັນທຸກຢ່າງທີ່ເກີດຂື້ນກັບເຄື່ອງແມ່ຂ່າຍໃນປັດຈຸບັນໄດ້ແນວໃດ?
• ວິທີການມີອິດທິພົນຕໍ່ການປະສົມປະສານເພື່ອໃຫ້ເຄື່ອງແມ່ຂ່າຍບໍ່ crash ເຂົ້າໄປໃນ OOM?
• ໄດເວີ Golang ສໍາລັບ ClickHouse ຈະຖືກພັດທະນາແນວໃດ?
• ວັດຈະນານຸກົມພາຍນອກບໍ່ໂຫຼດຫຼັງຈາກປິດເປີດຄືນໃໝ່ດ້ວຍການຕັ້ງຄ່າ lazy_load ເປີດໃຊ້ງານ. ຈະເຮັດແນວໃດ?
• ຈະເຮັດແນວໃດກັບຄວາມຈິງທີ່ວ່າວັດຈະນານຸກົມການໂຫຼດຄືນລະບົບບໍ່ໂຫຼດວັດຈະນານຸກົມໃດນຶ່ງໃນຫຼາຍໆວັດຈະນານຸກົມ ຖ້າຢ່າງໜ້ອຍນຶ່ງໃນນັ້ນເກີດຄວາມຜິດພາດ?
• ມີວິທີການກໍານົດລາຍລະອຽດໃນ ClickHouse config, ແຕ່ບໍ່ສະແດງພວກມັນໃນກໍລະນີທີ່ມີຂໍ້ຜິດພາດບໍ?
• ໂບນັດ: ພື້ນຫຼັງສຳລັບການຊູມຈາກການຊຸມນຸມ

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

ClickHouse ແມ່ນການປັບປຸງຢ່າງຕໍ່ເນື່ອງ, ແຕ່ຂໍ້ມູນຂອງພວກເຮົາບໍ່ແມ່ນ. ຈະເຮັດແນວໃດກ່ຽວກັບມັນ?

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

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

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

ການປະຕິບັດທີ່ດີທີ່ສຸດໃນປະຈຸບັນສໍາລັບການສໍາຮອງຂໍ້ມູນຂໍ້ມູນຈາກ ClickHouse ແມ່ນຫຍັງ?

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

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

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

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

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

ຖ້າຕາຕະລາງທີ່ມີຂໍ້ມູນຄອບຄອງພຽງແຕ່ສອງສາມກິກາໄບ, ການສໍາຮອງຂໍ້ມູນສາມາດເຮັດໄດ້ເຊັ່ນນີ້:

1. ບັນທຶກຄໍານິຍາມຕາຕະລາງເຊັ່ນ metadata − ສະແດງໃຫ້ເຫັນການສ້າງຕາຕະລາງ.
2. ເຮັດການຖິ້ມຂີ້ເຫຍື້ອໂດຍໃຊ້ລູກຄ້າ ClickHouse - ເລືອກ * ຈາກຕາຕະລາງ ຍື່ນ. ໂດຍຄ່າເລີ່ມຕົ້ນທ່ານຈະໄດ້ຮັບໄຟລ໌ໃນຮູບແບບ TabSeparated. ຖ້າທ່ານຕ້ອງການໃຫ້ມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ທ່ານສາມາດເຮັດໄດ້ໃນຮູບແບບພື້ນເມືອງ.

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

ສໍາລັບກໍລະນີທີ່ກ້າວຫນ້າທາງດ້ານຫຼາຍ, ClickHouse ມີຄວາມສາມາດໃນການສ້າງພາບລວມຂອງພາທິຊັນໃນລະບົບໄຟລ໌ທ້ອງຖິ່ນ. ຄຸນສົມບັດນີ້ສາມາດໃຊ້ໄດ້ຕາມຄຳຮ້ອງຂໍ ການ​ປ່ຽນ​ແປງ​ການ​ແບ່ງ​ປັນ freeze ຕາ​ຕະ​ລາງ​. ຫຼືງ່າຍດາຍ ປ່ຽນແປງຕາຕະລາງ freeze - ນີ້ແມ່ນພາບລວມຂອງຕາຕະລາງທັງຫມົດ.

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

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

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

ທໍາອິດທ່ານຈໍາເປັນຕ້ອງສ້າງເຄື່ອງແມ່ຂ່າຍຈໍານວນຫນຶ່ງທີ່ມີຊັ້ນວາງແຜ່ນຂະຫນາດໃຫຍ່. ຕໍ່ໄປ, ໃນເຄື່ອງແມ່ຂ່າຍເຫຼົ່ານີ້, ຍົກສູງຫຼາຍເຄື່ອງແມ່ຂ່າຍ ClickHouse ແລະ configure ໃຫ້ເຂົາເຈົ້າເພື່ອໃຫ້ເຂົາເຈົ້າເຮັດວຽກເປັນ replica ອື່ນສໍາລັບ shards ດຽວກັນ. ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ລະບົບໄຟລ໌ຫຼືເຄື່ອງມືບາງຢ່າງໃນເຄື່ອງແມ່ຂ່າຍເຫຼົ່ານີ້ທີ່ອະນຸຍາດໃຫ້ທ່ານສ້າງພາບຖ່າຍ. ມີສອງທາງເລືອກທີ່ນີ້. ທາງເລືອກທໍາອິດແມ່ນ LVM snapshots, ທາງເລືອກທີສອງແມ່ນ ZFS ໃນ Linux.

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

ມັນເປັນໄປໄດ້ທີ່ຈະຈັດລະບຽບ lag ຂອງ replicas ຄວບຄຸມໃນ shafts ໄດ້?

ປີນີ້ທ່ານກໍາລັງວາງແຜນທີ່ຈະເຮັດໃຫ້ shafts ໃນ ClickHouse. ມັນເປັນໄປໄດ້ທີ່ຈະຈັດລະບຽບແບບຈໍາລອງທີ່ຄວບຄຸມຢູ່ໃນພວກມັນບໍ? ພວກເຮົາຢາກໃຊ້ມັນເພື່ອປົກປ້ອງຕົວເຮົາເອງຈາກສະຖານະການທາງລົບກັບການປ່ຽນແປງແລະການປ່ຽນແປງອື່ນໆ.

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

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

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

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

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

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

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

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

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

ຈະເປັນແນວໃດຖ້າໂຄງສ້າງຕາຕະລາງມີການປ່ຽນແປງ?

ວິທີການຟື້ນຟູການສໍາຮອງຂໍ້ມູນທີ່ໄດ້ເຮັດກັບໂຄງການເກົ່າ? ແລະຄໍາຖາມທີສອງແມ່ນກ່ຽວກັບກໍລະນີທີ່ມີຮູບຖ່າຍແລະເຄື່ອງມືລະບົບໄຟລ໌. Btrfs ດີຢູ່ທີ່ນີ້ແທນ ZFS ໃນ Linux LVM ບໍ?

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

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

ການປະຕິບັດທີ່ດີທີ່ສຸດໃນການສົ່ງຕໍ່ຂໍ້ມູນໃນປະຈຸບັນແມ່ນຫຍັງ?

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

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

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

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

ວິທີການນີ້ມີຈຸດອ່ອນຫນຶ່ງ, ແລະມັນຂຶ້ນກັບໂຄງການ sharding, ບໍ່ວ່າທ່ານຈະສັນຍາກັບໂຄງການ sharding ນີ້, ສິ່ງທີ່ທ່ານມີ sharding key. ໃນຕົວຢ່າງຂອງທ່ານສໍາລັບກໍລະນີທີ່ມີ metrics, sharding key ແມ່ນ hash ຂອງເສັ້ນທາງ. ເມື່ອທ່ານເລືອກຕາຕະລາງແຈກຢາຍ, ມັນຈະໄປຫາ shards ທັງຫມົດໃນ cluster ໃນເວລາດຽວກັນແລະເອົາຂໍ້ມູນຈາກບ່ອນນັ້ນ.

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

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

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

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

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

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

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

ຂ້ອຍມີຈຸດເພີ່ມເຕີມເພື່ອຕອບຄໍາຖາມ. ຫນຶ່ງໃນນັ້ນແມ່ນກ່ຽວກັບວິທີການທໍາອິດໃນການອອກແບບໂຄງການ sharding ເພື່ອໃຫ້ re-sharding ຈະເຮັດໃຫ້ເຈັບປວດຫນ້ອຍ. ອັນນີ້ເປັນໄປບໍ່ໄດ້ສະເໝີໄປ.

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

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

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

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

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

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

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

ມີກຸ່ມຕົ້ນຕໍທີ່ມີເຫດການ Yandex.Metrica. ເຫດການແມ່ນການເບິ່ງຫນ້າ, ການຄລິກ, ແລະການປ່ຽນແປງ. ຄໍາຮ້ອງຂໍສ່ວນໃຫຍ່ໄປຫາເວັບໄຊທ໌ສະເພາະ. ທ່ານເປີດບໍລິການ Yandex.Metrica, ທ່ານມີເວັບໄຊທ໌ - avito.ru, ໄປຫາບົດລາຍງານ, ແລະການຮ້ອງຂໍແມ່ນເຮັດສໍາລັບເວັບໄຊທ໌ຂອງທ່ານ.

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

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

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

ມີທາງເລືອກທີ່ກົງກັນຂ້າມກັບ diametrically. ຈິນຕະນາການຖ້າພວກເຮົາແບ່ງປັນຂໍ້ມູນໃນທົ່ວເວັບໄຊທ໌, ແລະການຮ້ອງຂໍສໍາລັບເວັບໄຊທ໌ຫນຶ່ງໄປຫາຫນຶ່ງ shard. ໃນປັດຈຸບັນ cluster ຈະສາມາດຈັດການກັບ 10 ພັນຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, ແຕ່ວ່າໃນຫນຶ່ງ shard ຄໍາຮ້ອງຂໍຫນຶ່ງຈະເຮັດວຽກຊ້າເກີນໄປ. ມັນ​ຈະ​ບໍ່​ມີ​ການ​ປັບ​ຂະ​ຫນາດ​ໃນ​ແງ່​ຂອງ​ການ​ຜ່ານ​. ໂດຍສະເພາະຖ້ານີ້ແມ່ນເວັບໄຊທ໌ avito.ru. ຂ້ອຍຈະບໍ່ເປີດເຜີຍຄວາມລັບຖ້າຂ້ອຍເວົ້າວ່າ Avito ແມ່ນຫນຶ່ງໃນເວັບໄຊທ໌ທີ່ມີການເຂົ້າຊົມຫລາຍທີ່ສຸດໃນ RuNet. ແລະການປຸງແຕ່ງມັນຢູ່ໃນຫນຶ່ງ shard ຈະເປັນ madness.

ດັ່ງນັ້ນ, ໂຄງການ sharding ໄດ້ຖືກອອກແບບໃນວິທີການ cunning ຫຼາຍ. ກຸ່ມທັງໝົດແມ່ນແບ່ງອອກເປັນຫຼາຍກຸ່ມ, ເຊິ່ງພວກເຮົາເອີ້ນວ່າຊັ້ນຕ່າງໆ. ແຕ່​ລະ​ກຸ່ມ​ປະ​ກອບ​ດ້ວຍ​ຈາກ​ອາຍ​ແກ​ັ​ສ​ຫາ​ຫຼາຍ​ອາຍ​ແກ​ັ​ສ shards​. ມີທັງໝົດສາມສິບເກົ້າກຸ່ມດັ່ງກ່າວ.

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

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

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

ໃນໂຄງການໃຫມ່, ສະຖານທີ່ທັງຫມົດຖືກແບ່ງອອກເປັນສອງປະເພດ - ຂະຫນາດໃຫຍ່ແລະຂະຫນາດນ້ອຍ. ຂ້ອຍບໍ່ຮູ້ວ່າຂອບເຂດຖືກເລືອກແນວໃດ, ແຕ່ຜົນໄດ້ຮັບແມ່ນວ່າເວັບໄຊທ໌ຂະຫນາດໃຫຍ່ຖືກບັນທຶກໄວ້ໃນກຸ່ມຫນຶ່ງ, ບ່ອນທີ່ມີ 120 shards ທີ່ມີສາມ replicas ແຕ່ລະຄົນ - ນັ້ນແມ່ນ, 360 servers. ແລະໂຄງການ sharding ແມ່ນເຊັ່ນວ່າຄໍາຮ້ອງຂໍໃດໆໄປຫາ shards ທັງຫມົດໃນເວລາດຽວກັນ. ຖ້າຕອນນີ້ເຈົ້າເປີດຫນ້າລາຍງານໃດໆສໍາລັບ avito.ru ໃນ Yandex.Metrica, ການຮ້ອງຂໍຈະໄປຫາ 120 ເຄື່ອງແມ່ຂ່າຍ. ມີສະຖານທີ່ຂະຫນາດໃຫຍ່ຈໍານວນຫນ້ອຍຢູ່ໃນ RuNet. ແລະ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ບໍ່​ແມ່ນ​ເປັນ​ພັນ​ຕໍ່​ວິ​ນາ​ທີ​, ແຕ່​ເຖິງ​ແມ່ນ​ວ່າ​ຫນ້ອຍ​ກ​່​ວາ​ຮ້ອຍ​. ທັງຫມົດນີ້ແມ່ນ chewed ຢ່າງງຽບໆໂດຍຕາຕະລາງການແຈກຢາຍ, ເຊິ່ງແຕ່ລະອັນຂອງພວກເຂົາດໍາເນີນການກັບ 120 ເຄື່ອງແມ່ຂ່າຍ.

ແລະກຸ່ມທີສອງແມ່ນສໍາລັບສະຖານທີ່ຂະຫນາດນ້ອຍ. ນີ້ແມ່ນໂຄງການ sharding ໂດຍອີງໃສ່ ID ເວັບໄຊທ໌, ແລະແຕ່ລະຄໍາຮ້ອງຂໍໄປຫາຫນຶ່ງ shard ແທ້.

ClickHouse ມີປະໂຫຍດຂອງ clickhouse-copier. ເຈົ້າສາມາດບອກຂ້ອຍກ່ຽວກັບນາງໄດ້ບໍ?

ຂ້ອຍຈະເວົ້າທັນທີວ່າການແກ້ໄຂນີ້ແມ່ນສັບສົນຫຼາຍແລະມີຜົນຜະລິດຫນ້ອຍ. ປະໂຫຍດແມ່ນວ່າມັນ smears ຂໍ້ມູນຢ່າງສົມບູນຕາມຮູບແບບທີ່ທ່ານລະບຸ. ແຕ່ຂໍ້ເສຍຂອງຜົນປະໂຫຍດແມ່ນວ່າມັນບໍ່ໄດ້ reshard ທັງຫມົດ. ມັນຄັດລອກຂໍ້ມູນຈາກ schema ກຸ່ມຫນຶ່ງໄປຫາ schema ກຸ່ມອື່ນ.

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

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

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

ທ່ານມີສິ່ງທົດລອງທີ່ເອີ້ນວ່າ resharding. ແມ່ນຫຍັງກັບນາງ?

ກັບໄປໃນປີ 2017, ທ່ານມີສິ່ງທົດລອງທີ່ເອີ້ນວ່າ resharding. ມີແມ້ກະທັ້ງທາງເລືອກໃນ ClickHouse. ດັ່ງທີ່ຂ້ອຍເຂົ້າໃຈມັນ, ມັນບໍ່ໄດ້ອອກ. ເຈົ້າສາມາດບອກຂ້ອຍໄດ້ວ່າເປັນຫຍັງນີ້ເກີດຂຶ້ນ? ມັນເບິ່ງຄືວ່າມີຄວາມກ່ຽວຂ້ອງຫຼາຍ.

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

ມັນເປັນໄປໄດ້ບໍທີ່ຈະລວມຂໍ້ມູນທັງໝົດເຂົ້າກັນກ່ອນທີ່ຈະຍ້າຍມັນໄປໃສ່ແຜ່ນຊ້າ?

ຄໍາ​ຖາມ​ກ່ຽວ​ກັບ TTL ກັບ​ການ​ຍ້າຍ​ໄປ​ທາງ​ເລືອກ disk ຊ້າ​ໃນ​ສະ​ພາບ​ການ​ຂອງ​ການ​ລວມ​. ມີວິທີໃດແດ່, ນອກເໜືອໄປຈາກທາງ cron, ເພື່ອຮວມພາກສ່ວນທັງໝົດເປັນອັນໜຶ່ງ ກ່ອນທີ່ຈະຍ້າຍພວກມັນໄປໃສ່ແຜ່ນຊ້າບໍ?

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

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

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

ວິທີການຍ້າຍໄປຍັງ ClickHouse ຮຸ່ນໃຫມ່ຖ້າບໍ່ມີວິທີການກວດສອບຄວາມເຂົ້າກັນໄດ້ລ່ວງຫນ້າ?

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

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

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

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

ມີເວີຊັນ 20.3.4. ຕົວເລກ 20 ຊີ້ໃຫ້ເຫັນເຖິງປີຂອງການຜະລິດ - 2020. ຈາກຈຸດຂອງສິ່ງທີ່ຢູ່ພາຍໃນ, ນີ້ບໍ່ສໍາຄັນ, ດັ່ງນັ້ນພວກເຮົາຈະບໍ່ເອົາໃຈໃສ່ກັບມັນ. ຕໍ່ໄປ - 20.3. ພວກເຮົາເພີ່ມຕົວເລກທີສອງ - ໃນກໍລະນີນີ້ 3 - ທຸກໆຄັ້ງທີ່ພວກເຮົາປ່ອຍຕົວປ່ອຍອອກມາດ້ວຍບາງຫນ້າທີ່ໃຫມ່. ຖ້າພວກເຮົາຕ້ອງການເພີ່ມຄຸນສົມບັດບາງຢ່າງໃຫ້ກັບ ClickHouse, ພວກເຮົາຕ້ອງເພີ່ມຈໍານວນນີ້. ນັ້ນແມ່ນ, ໃນຮຸ່ນ 20.4 ClickHouse ຈະເຮັດວຽກດີກວ່າ. ຕົວເລກທີສາມແມ່ນ 20.3.4. ນີ້ແມ່ນ 4 ຈໍານວນການອອກ patch ທີ່ພວກເຮົາບໍ່ໄດ້ເພີ່ມຄຸນສົມບັດໃຫມ່, ແຕ່ແກ້ໄຂບາງຂໍ້ບົກພ່ອງ. ແລະ 4 ຫມາຍຄວາມວ່າພວກເຮົາໄດ້ເຮັດສີ່ຄັ້ງ.

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

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

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

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

ສິ່ງທີ່ສາມາດເຮັດໄດ້? ມັນຈະເປັນການດີທີ່ຈະໃຫ້ຕົວຢ່າງໃນເອກະສານ ClickHouse ກ່ຽວກັບວິທີການຕິດຕັ້ງກຸ່ມຂະຫນາດນ້ອຍໃນເຮືອນຂອງເຈົ້າເອງ - ໃນ Docker, ໃນ LXC, ບາງທີອາດຈະສ້າງ Ansible playbook, ເພາະວ່າຄົນທີ່ແຕກຕ່າງກັນມີການຕິດຕັ້ງທີ່ແຕກຕ່າງກັນ. ນີ້ຈະງ່າຍຫຼາຍ. ເມື່ອທ່ານເອົາ ແລະນຳໃຊ້ກຸ່ມໃນຫ້ານາທີ, ມັນງ່າຍກວ່າທີ່ຈະພະຍາຍາມຫາອັນໃດອັນໜຶ່ງອອກ. ນີ້ແມ່ນສະດວກກວ່າ, ເພາະວ່າການມ້ວນເຂົ້າໄປໃນຮຸ່ນການຜະລິດທີ່ທ່ານບໍ່ໄດ້ທົດສອບແມ່ນເສັ້ນທາງໄປຫາບ່ອນໃດ. ບາງຄັ້ງມັນເຮັດວຽກແລະບາງຄັ້ງມັນບໍ່ໄດ້. ແລະດັ່ງນັ້ນ, ຄວາມຫວັງສໍາລັບຄວາມສໍາເລັດແມ່ນບໍ່ດີ.

Maxim Kotyakov, ວິສະວະກອນ backend ອາວຸໂສ Avito: ຂ້າພະເຈົ້າຈະເພີ່ມເລັກນ້ອຍກ່ຽວກັບສະພາບແວດລ້ອມການທົດສອບຈາກຊຸດຂອງບັນຫາທີ່ບໍລິສັດໃຫຍ່ປະເຊີນຫນ້າ. ພວກເຮົາມີກຸ່ມການຍອມຮັບ ClickHouse ເຕັມຮູບແບບ; ກຸ່ມນີ້ຖືກນຳໃຊ້ຢູ່ໃນຖັງເກັບນ້ຳທີ່ຂ້ອນຂ້າງພໍສົມຄວນທີ່ມີຊັບພະຍາກອນຢ່າງໜ້ອຍສຸດ. ພວກເຮົາຂຽນຂໍ້ມູນການຜະລິດຈໍານວນຫນຶ່ງຢູ່ທີ່ນັ້ນ, ໂຊກດີທີ່ມັນເປັນໄປໄດ້ທີ່ຈະ replicate ນ້ໍາໃນ Kafka. ທຸກສິ່ງທຸກຢ່າງມີ synchronized ແລະຂະຫນາດ - ທັງໃນແງ່ຂອງຄວາມສາມາດແລະການໄຫຼເຂົ້າ, ແລະ, ໃນທາງທິດສະດີ, ສິ່ງອື່ນໆທັງຫມົດແມ່ນເທົ່າທຽມກັນ, ມັນຄວນຈະປະຕິບັດຕົວເຊັ່ນການຜະລິດຕາມ metrics. ທຸກຢ່າງທີ່ອາດຈະເກີດລະເບີດແມ່ນໄດ້ຖືກມ້ວນໃສ່ບ່ອນຕັ້ງແຫ່ງນີ້ ແລະປະໄວ້ບ່ອນນັ້ນເປັນເວລາຫຼາຍມື້ຈົນກວ່າຈະກຽມພ້ອມ. ແຕ່ຕາມທໍາມະຊາດ, ການແກ້ໄຂນີ້ແມ່ນລາຄາແພງ, ມີຄວາມຫຍຸ້ງຍາກແລະມີຄ່າໃຊ້ຈ່າຍທີ່ບໍ່ແມ່ນສູນ.

Alexey Milovidov: ຂ້າພະເຈົ້າຈະບອກທ່ານວ່າສະພາບແວດລ້ອມການທົດສອບຂອງຫມູ່ເພື່ອນຂອງພວກເຮົາຈາກ Yandex.Metrica ເປັນແນວໃດ. ກຸ່ມຫນຶ່ງມີ 600-odd servers, ອື່ນມີ 360, ແລະມີ clusters ທີສາມແລະຫຼາຍ. ສະພາບແວດລ້ອມການທົດສອບສໍາລັບຫນຶ່ງໃນນັ້ນແມ່ນພຽງແຕ່ສອງ shards ທີ່ມີສອງ replicas ໃນແຕ່ລະ. ເປັນຫຍັງສອງ shard? ດັ່ງນັ້ນເຈົ້າບໍ່ໄດ້ຢູ່ຄົນດຽວ. ແລະຄວນຈະມີ replicas ຄືກັນ. ພຽງແຕ່ຈໍານວນຕໍາ່ສຸດທີ່ແນ່ນອນວ່າທ່ານສາມາດຈ່າຍໄດ້.

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

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

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

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

Kill query ແມ່ນ supposed ທີ່ຈະຂ້າ queries, ແຕ່ມັນບໍ່. ເປັນຫຍັງ?

ຜູ້ໃຊ້, ບາງປະເພດຂອງນັກວິເຄາະ, ໄດ້ມາຫາຂ້ອຍແລະສ້າງຄໍາຮ້ອງຂໍທີ່ເຮັດໃຫ້ກຸ່ມ ClickHouse ຂອງຂ້ອຍ. ບາງ node ຫຼື cluster ທັງຫມົດ, ຂຶ້ນກັບການ replica ຫຼື shard ທີ່ຮ້ອງຂໍໄປ. ຂ້ອຍເຫັນວ່າຊັບພະຍາກອນ CPU ທັງໝົດຢູ່ໃນເຊີບເວີນີ້ຢູ່ໃນຊັ້ນວາງ, ທຸກຢ່າງແມ່ນສີແດງ. ໃນເວລາດຽວກັນ, ClickHouse ຕົວຂອງມັນເອງຕອບສະຫນອງຄໍາຮ້ອງຂໍ. ແລະຂ້ອຍຂຽນວ່າ: "ກະລຸນາສະແດງໃຫ້ຂ້ອຍ, ບັນຊີລາຍຊື່ຂະບວນການ, ການຮ້ອງຂໍອັນໃດທີ່ເຮັດໃຫ້ຄວາມບ້ານີ້."

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

ໃນປັດຈຸບັນຈະມີຄໍາຕອບທີ່ແປກປະຫຼາດຫຼາຍ. ຈຸດແມ່ນວ່າ kill query ບໍ່ໄດ້ຂ້າການສອບຖາມ.

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

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

ວິທີການຄິດໄລ່ເວລາຕອບສະຫນອງພາຍໃຕ້ການອ່ານການໂຫຼດ?

ມີຕາຕະລາງທີ່ເກັບລວບລວມລາຍການ - counters ຕ່າງໆ. ຈໍານວນຂອງສາຍແມ່ນປະມານຫນຶ່ງຮ້ອຍລ້ານ. ມັນເປັນໄປໄດ້ທີ່ຈະນັບເວລາຕອບສະຫນອງທີ່ຄາດເດົາໄດ້ຖ້າທ່ານຖອກ 1K RPS ສໍາລັບລາຍການ 1K?

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

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

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

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

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

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

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

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

ຂ້ອຍສາມາດປັບແຕ່ງຫຍັງໃນ ClickHouse ເພື່ອໃຫ້ມີຂໍ້ມູນຫຼາຍຂຶ້ນຢູ່ໃນແຄດ?

ຂໍໃຫ້ຈິນຕະນາການສະຖານະການ - ເຄື່ອງແມ່ຂ່າຍມີ 256 GB ຂອງ RAM, ໃນປະຈໍາວັນ ClickHouse ໃຊ້ເວລາປະມານ 60-80 GB, ສູງສຸດ - ເຖິງ 130. ສິ່ງທີ່ສາມາດເປີດໃຊ້ແລະ tweaked ເພື່ອໃຫ້ມີຂໍ້ມູນຫຼາຍຢູ່ໃນ cache ແລະ, ຕາມຄວາມເຫມາະສົມ. ມີການເດີນທາງຫນ້ອຍລົງໃນແຜ່ນ?

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

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

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

ຂ້ອຍສາມາດຕັ້ງຄ່າ storage_configuration ສໍາລັບການເກັບຮັກສາໃນ RAM ໄດ້ແນວໃດ?

ໃນເອກະສານ ClickHouse ໃຫມ່ຂ້າພະເຈົ້າອ່ານພາກສ່ວນທີ່ກ່ຽວຂ້ອງ ດ້ວຍການເກັບຮັກສາຂໍ້ມູນ. ຄໍາອະທິບາຍປະກອບມີຕົວຢ່າງທີ່ມີ SSD ໄວ.

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

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

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

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

ໃນຄວາມຫມາຍນີ້, ການເກັບຮັກສາຂໍ້ມູນໃນ RAM ແມ່ນບໍ່ແຕກຕ່າງຈາກການເກັບຮັກສາໄວ້ໃນແຜ່ນ, ເພາະວ່າເມື່ອຂໍ້ມູນຖືກຂຽນລົງໃນແຜ່ນ, ມັນຍັງທໍາອິດຈົບລົງໃນ cache ຂອງຫນ້າແລະຖືກຂຽນໄວ້ຕໍ່ມາ. ນີ້ແມ່ນຂຶ້ນກັບຕົວເລືອກການຕິດຕັ້ງລະບົບໄຟລ໌. ແຕ່ໃນກໍລະນີ, ຂ້າພະເຈົ້າຈະເວົ້າວ່າ ClickHouse ບໍ່ fsync ເມື່ອໃສ່.

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

ເຖິງວ່າຈໍານວນຄ່າທີ່ເປັນເອກະລັກແມ່ນ Low Cardinality ມີປະສິດທິພາບແນວໃດ?

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

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

ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການຊອກຫາຂໍ້ຄວາມເຕັມຕາຕະລາງທີ່ມີຫ້າພັນລ້ານແຖວແມ່ນຫຍັງ?

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

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

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

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

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

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

ບໍ່ດົນມານີ້, ClickHouse ໄດ້ເພີ່ມຫນ້າທີ່ກ້າວຫນ້າທາງດ້ານຫຼາຍກວ່າເກົ່າສໍາລັບການຄົ້ນຫາຂໍ້ຄວາມເຕັມ. ນີ້ແມ່ນ, ທໍາອິດ, ການຄົ້ນຫາສໍາລັບຊໍ່ຂອງ substrings ໃນເວລາດຽວກັນໃນຫນຶ່ງ pass, ລວມທັງທາງເລືອກທີ່ມີຕົວພິມໃຫຍ່, ກໍລະນີ-ບໍ່ອ່ອນໄຫວ, ສະຫນັບສະຫນູນ UTF-8 ຫຼືພຽງແຕ່ສໍາລັບ ASCII. ເລືອກປະສິດທິພາບທີ່ສຸດທີ່ທ່ານຕ້ອງການ.

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

ອັນທີສາມ, ໃນປັດຈຸບັນມີການຄົ້ນຫາໂດຍປະມານສໍາລັບ regexps ແລະການຄົ້ນຫາໂດຍປະມານສໍາລັບ substrings. ຖ້າໃຜຜູ້ຫນຶ່ງສະກົດຄໍາຜິດ, ມັນຈະຖືກຄົ້ນຫາສໍາລັບຄໍາທີ່ກົງກັນສູງສຸດ.

ວິທີທີ່ດີທີ່ສຸດໃນການຈັດລະບຽບການເຂົ້າເຖິງ ClickHouse ສໍາລັບຈໍານວນຜູ້ໃຊ້ຈໍານວນຫລາຍແມ່ນຫຍັງ?

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

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

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

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

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

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

ນີ້ແມ່ນການຕັ້ງຄ່າທີ່ຂີ້ຮ້າຍຫຼາຍແລະບໍ່ເຫມາະສົມສໍາລັບກໍລະນີທີ່ cluster ມີການໂຫຼດຄົງທີ່. ແຕ່ຖ້າຫາກວ່າທ່ານມີຄໍາຮ້ອງຂໍສັ້ນ, bursty ທີ່ສໍາຄັນ, ແລະ cluster ສ່ວນຫຼາຍແມ່ນບໍ່ມີການເຄື່ອນໄຫວ, ການຕັ້ງຄ່ານີ້ແມ່ນເຫມາະສົມ.

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

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

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

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

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

ມັນເປັນໄປໄດ້ທີ່ຈະໃຫ້ຜົນໄດ້ຮັບຂອງການສອບຖາມຫນຶ່ງໃຫ້ກັບລູກຄ້າສິບຄົນ?

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

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

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

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

ມີການແກ້ໄຂທາງເລືອກທີ່ວາງໄວ້ເປັນ sidecar ຖັດຈາກ ClickHouse - ClickHouse Proxy.

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

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

ຈະເປັນແນວໃດກ່ຽວກັບການດໍາເນີນງານ asynchronous ແລະ views materialized?

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

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

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

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

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

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

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

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

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

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

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

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

ClickHouse ມີຫຼາຍບັນທຶກ. ຂ້ອຍຈະເຫັນທຸກສິ່ງທີ່ເກີດຂຶ້ນກັບເຊີບເວີໄດ້ແນວໃດ?

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

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

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

ເພື່ອນຮ່ວມງານຂອງຂ້ອຍຈາກ Metrica ມີ dashboard ຂອງຕົນເອງໃນ Grafana, ແລະຂ້ອຍມີຂອງຂ້ອຍສໍາລັບກຸ່ມຂອງພວກເຂົາ. ຂ້ອຍກໍາລັງເບິ່ງສິ່ງຕ່າງໆເຊັ່ນ cache hit ສໍາລັບ cache serif. ແລະເຖິງແມ່ນວ່າມີຄວາມຫຍຸ້ງຍາກຫຼາຍແມ່ນພວກເຮົາໃຊ້ເຄື່ອງມືທີ່ແຕກຕ່າງກັນ. ຂ້ອຍສ້າງ dashboard ຂອງຂ້ອຍໂດຍໃຊ້ເຄື່ອງມືເກົ່າຫຼາຍທີ່ເອີ້ນວ່າ Graphite-web. ລາວຂີ້ຄ້ານໝົດ. ແລະຂ້ອຍຍັງໃຊ້ວິທີນີ້, ເຖິງແມ່ນວ່າ Grafana ອາດຈະສະດວກແລະສວຍງາມກວ່າ.

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

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

ຂ້ອຍຂີ່ລົດຖີບເອງ. ແຕ່ຂ້ອຍມີຄໍາຖາມ - ຖ້າມັນເປັນມາດຕະຖານທັງຫມົດ, ແລະ Grafana ຖືກໃຊ້ໂດຍທຸກຄົນ, ເປັນຫຍັງ Yandex ບໍ່ມີ dashboard ທີ່ເປັນທາງການ?

Kirill Shvakov: ໃນຄວາມເປັນຈິງ, ແຫຼ່ງຂໍ້ມູນທີ່ໄປຫາ ClickHouse ໃນປັດຈຸບັນສະຫນັບສະຫນູນ Altinity. ແລະຂ້າພະເຈົ້າພຽງແຕ່ຕ້ອງການໃຫ້ vector ຂອງບ່ອນທີ່ຈະຂຸດແລະຜູ້ທີ່ຈະຍູ້. ທ່ານສາມາດຖາມພວກເຂົາໄດ້, ເພາະວ່າ Yandex ຍັງສ້າງ ClickHouse, ແລະບໍ່ແມ່ນເລື່ອງທີ່ອ້ອມຮອບມັນ. Altinity ແມ່ນບໍລິສັດຕົ້ນຕໍທີ່ສົ່ງເສີມ ClickHouse. ພວກເຂົາ​ຈະ​ບໍ່​ປະຖິ້ມ​ລາວ, ແຕ່​ຈະ​ສະໜັບສະໜູນ​ລາວ. ເນື່ອງຈາກວ່າ, ໃນຫຼັກການ, ເພື່ອອັບໂຫລດ dashboard ໄປຫາເວັບໄຊທ໌ Grafana, ທ່ານພຽງແຕ່ຕ້ອງການລົງທະບຽນແລະອັບໂຫລດມັນ - ບໍ່ມີບັນຫາພິເສດ.

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

ຂ້າພະເຈົ້າປາດຖະຫນາວ່າມີເຄື່ອງມືທີ່ພຽງແຕ່ເວົ້າວ່າ, ນີ້ແມ່ນຄໍາຖາມທີ່ຫນັກແຫນ້ນຂອງທ່ານ, ຈັດກຸ່ມໂດຍຫ້ອງຮຽນແບບສອບຖາມ. ຂ້າ​ພະ​ເຈົ້າ​ກົດ​ດັນ​ຫນຶ່ງ​, ແລະ​ເຂົາ​ເຈົ້າ​ຈະ​ບອກ​ຂ້າ​ພະ​ເຈົ້າ​ວ່າ​ເປັນ​ຫຍັງ​ມັນ​ເປັນ​ຫນັກ​. ບໍ່ມີການແກ້ໄຂດັ່ງກ່າວໃນປັດຈຸບັນ. ແລະມັນກໍ່ເປັນເລື່ອງແປກທີ່ເມື່ອຄົນຖາມຂ້ອຍວ່າ: "ບອກຂ້ອຍ, ມີ dashboards ກຽມພ້ອມສໍາລັບ Grafana ບໍ?", ຂ້ອຍເວົ້າວ່າ: "ໄປຫາເວັບໄຊທ໌ Grafana, ມີຊຸມຊົນ "Dashboards", ແລະມີ dashboard. ຈາກ Dimka, ມີ dashboard ຈາກ Kostyan. ຂ້ອຍບໍ່ຮູ້ວ່າມັນແມ່ນຫຍັງ, ຂ້ອຍບໍ່ໄດ້ໃຊ້ມັນເອງ.”

ວິທີການມີອິດທິພົນຕໍ່ການປະສົມປະສານເພື່ອໃຫ້ເຄື່ອງແມ່ຂ່າຍບໍ່ crash ເຂົ້າໄປໃນ OOM?

ຂ້າ​ພະ​ເຈົ້າ​ມີ​ຕາ​ຕະ​ລາງ​, ມີ​ພຽງ​ແຕ່​ຫນຶ່ງ​ການ​ແບ່ງ​ປັນ​ໃນ​ຕາ​ຕະ​ລາງ​, ມັນ​ແມ່ນ ReplaceingMergeTree​. ຂ້ອຍໄດ້ຂຽນຂໍ້ມູນໃສ່ມັນເປັນເວລາສີ່ປີແລ້ວ. ຂ້ອຍຈໍາເປັນຕ້ອງໄດ້ແກ້ໄຂມັນແລະລຶບຂໍ້ມູນບາງຢ່າງ.

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

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

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

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

Vladimir Kolobaev: ດີ. ໃນປັດຈຸບັນນີ້ແມ່ນວ່າຫຼັງຈາກ bug ໄດ້ຖືກແກ້ໄຂແລ້ວ, ຂ້າພະເຈົ້າໄດ້ດາວໂຫລດເວີຊັນໃຫມ່ສໍາລັບຕົວຂ້ອຍເອງ, ແລະໃນຕາຕະລາງອື່ນ, ຂະຫນາດນ້ອຍກວ່າ, ບ່ອນທີ່ມີຫຼາຍການແບ່ງປັນ, ຂ້າພະເຈົ້າໄດ້ດໍາເນີນການທີ່ຄ້າຍຄືກັນ. ແລະໃນລະຫວ່າງການຜະສົມຜະສານ, ປະມານ 100 GB ຂອງ RAM ໄດ້ຖືກໄຟໄຫມ້ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ. ຂ້ອຍມີ 150 ຄອບຄອງ, 100 ກິນ, ແລະປ່ອງຢ້ຽມ 50 GB ຊ້າຍ, ດັ່ງນັ້ນຂ້ອຍບໍ່ໄດ້ຕົກຢູ່ໃນ OOM.

ໃນປັດຈຸບັນສິ່ງທີ່ປ້ອງກັນຂ້ອຍຈາກການຕົກຢູ່ໃນ OOM ຖ້າມັນໃຊ້ RAM 100 GB ແທ້ໆ? ເຮັດແນວໃດຖ້າທັນທີທັນໃດ RAM ໃນການປະສົມປະສານຫມົດ?

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

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

ໄດເວີ Golang ສໍາລັບ ClickHouse ຈະຖືກພັດທະນາແນວໃດ?

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

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

ຂ້ອຍມີສອງຄໍາຖາມ. ໃນປັດຈຸບັນຄົນຂັບ Golang ຂອງ Kirill ແມ່ນເກືອບເປັນວິທີເລີ່ມຕົ້ນໃນການສື່ສານຈາກ Golang ກັບ ClickHouse. ເວັ້ນເສຍແຕ່ວ່າຜູ້ໃດຜູ້ຫນຶ່ງຍັງຕິດຕໍ່ສື່ສານຜ່ານອິນເຕີເຟດ http ເພາະວ່າລາວມັກມັນແບບນັ້ນ. ການ​ພັດ​ທະ​ນາ​ຂອງ​ຜູ້​ຂັບ​ລົດ​ນີ້​ຈະ​ດໍາ​ເນີນ​ໄປ​ແນວ​ໃດ​? ມັນຈະຖືກ synchronized ກັບການປ່ຽນແປງທີ່ແຕກຫັກໃດໆໃນ repository ຕົວຂອງມັນເອງ? ແລະຂັ້ນຕອນການພິຈາລະນາບັນຫາແມ່ນຫຍັງ?

Kirill Shvakov: ທໍາອິດແມ່ນວິທີການຈັດລະບຽບ bureaucratically. ຈຸດນີ້ບໍ່ໄດ້ຖືກປຶກສາຫາລື, ສະນັ້ນຂ້ອຍບໍ່ມີຫຍັງຕອບ.

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

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

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

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

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

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

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

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

ວັດຈະນານຸກົມພາຍນອກບໍ່ໂຫຼດຫຼັງຈາກປິດເປີດຄືນໃໝ່ດ້ວຍການຕັ້ງຄ່າ lazy_load ເປີດໃຊ້ງານ. ຈະເຮັດແນວໃດ?

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

ບາງທີພວກເຮົາມີເວີຊັນເກົ່າຂອງ ClickHouse, ດັ່ງນັ້ນວັດຈະນານຸກົມບໍ່ໄດ້ໂຫລດອັດຕະໂນມັດ. ນີ້ອາດຈະເປັນກໍລະນີບໍ?

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

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

ຄໍາຕອບຂອງຄໍາຖາມສຸດທ້າຍແມ່ນສະບັບເກົ່າຫຼືມັນຈໍາເປັນຕ້ອງໄດ້ຮັບການແກ້ໄຂ.

ຈະເຮັດແນວໃດກັບຄວາມຈິງທີ່ວ່າວັດຈະນານຸກົມການໂຫຼດຄືນລະບົບບໍ່ໂຫຼດວັດຈະນານຸກົມໃດນຶ່ງໃນຫຼາຍໆວັດຈະນານຸກົມ ຖ້າຢ່າງໜ້ອຍນຶ່ງໃນນັ້ນເກີດຄວາມຜິດພາດ?

ມີຄຳຖາມອີກຢ່າງໜຶ່ງກ່ຽວກັບວັດຈະນານຸກົມການໂຫຼດຄືນໃໝ່ຂອງລະບົບ. ພວກເຮົາມີວັດຈະນານຸກົມສອງອັນ - ອັນໜຶ່ງບໍ່ໄດ້ໂຫລດ, ອັນທີສອງຖືກໂຫຼດ. ໃນ​ກໍ​ລະ​ນີ​ນີ້, System reload Dictionaries ບໍ່ໄດ້ໂຫລດວັດຈະນານຸກົມໃດນຶ່ງ, ແລະທ່ານຕ້ອງເອົາວັດຈະນານຸກົມການໂຫຼດແບບຊີ້ໄປຈຸດໃດໜຶ່ງໂດຍຊື່ຂອງມັນໂດຍໃຊ້ວັດຈະນານຸກົມລະບົບ reload. ນີ້ຍັງກ່ຽວຂ້ອງກັບສະບັບ ClickHouse ບໍ?

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

ມີວິທີການກໍານົດລາຍລະອຽດໃນ ClickHouse config, ແຕ່ບໍ່ສະແດງພວກມັນໃນກໍລະນີທີ່ມີຂໍ້ຜິດພາດບໍ?

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

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

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

ໂບນັດ: ພື້ນຫຼັງສຳລັບການຊູມຈາກການຊຸມນຸມ

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

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