ທິດສະດີແລະການປະຕິບັດຂອງການນໍາໃຊ້ ClickHouse ໃນຄໍາຮ້ອງສະຫມັກທີ່ແທ້ຈິງ. Alexander Zaitsev (2018)

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

ລາຍງານຈາກ BackEnd Conf 2018 ແລະມັນຖືກເຜີຍແຜ່ດ້ວຍການອະນຸຍາດຈາກຜູ້ເວົ້າ.

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

ແລະຂ້ອຍບໍ່ແມ່ນນ້ອງຊາຍຂອງ Petya Zaitsev. ຂ້ອຍມັກຈະຖືກຖາມກ່ຽວກັບເລື່ອງນີ້. ບໍ່, ພວກເຮົາບໍ່ແມ່ນອ້າຍນ້ອງ.

"ທຸກຄົນຮູ້" ວ່າ ClickHouse:

• ໄວ​ຫຼາຍ​,
• ສະດວກສະບາຍຫຼາຍ
• ໃຊ້ໃນ Yandex.

ຫນ້ອຍທີ່ຮູ້ຈັກໃນບໍລິສັດໃດແລະວິທີການນໍາໃຊ້ມັນ.

ຂ້ອຍຈະບອກເຈົ້າວ່າເປັນຫຍັງ, ບ່ອນໃດແລະວິທີການໃຊ້ ClickHouse, ຍົກເວັ້ນ Yandex.

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

ຂ້າພະເຈົ້າໄດ້ເລືອກເອົາສາມຕົວຢ່າງທີ່ສະແດງໃຫ້ເຫັນ ClickHouse ຈາກມຸມທີ່ແຕກຕ່າງກັນ. ຂ້າພະເຈົ້າຄິດວ່າມັນຈະຫນ້າສົນໃຈ.

ຄໍາຖາມທໍາອິດແມ່ນ: "ເປັນຫຍັງພວກເຮົາຕ້ອງການ ClickHouse?". ມັນເບິ່ງຄືວ່າເປັນຄໍາຖາມທີ່ຊັດເຈນ, ແຕ່ມີຫຼາຍກວ່າຫນຶ່ງຄໍາຕອບຕໍ່ມັນ.

• ຄໍາຕອບທໍາອິດແມ່ນສໍາລັບການປະຕິບັດ. ClickHouse ແມ່ນໄວຫຼາຍ. ການວິເຄາະໃນ ClickHouse ຍັງໄວຫຼາຍ. ມັນມັກຈະຖືກນໍາໃຊ້ໃນບ່ອນທີ່ມີອັນອື່ນຊ້າຫຼາຍຫຼືບໍ່ດີຫຼາຍ.
• ຄໍາຕອບທີສອງແມ່ນຄ່າໃຊ້ຈ່າຍ. ແລະທໍາອິດຂອງການທັງຫມົດ, ຄ່າໃຊ້ຈ່າຍຂອງຂະຫນາດ. ຕົວຢ່າງ, Vertica ເປັນຖານຂໍ້ມູນທີ່ຍິ່ງໃຫຍ່ຢ່າງແທ້ຈິງ. ມັນເຮັດວຽກໄດ້ດີຫຼາຍຖ້າທ່ານບໍ່ມີຂໍ້ມູນຫຼາຍ terabytes. ແຕ່ເມື່ອມັນມາຮອດຫຼາຍຮ້ອຍ terabytes ຫຼື petabytes, ຄ່າໃຊ້ຈ່າຍຂອງໃບອະນຸຍາດແລະການສະຫນັບສະຫນູນເຂົ້າໄປໃນຈໍານວນທີ່ຂ້ອນຂ້າງຫຼາຍ. ແລະມັນແພງ. ແລະ ClickHouse ແມ່ນບໍ່ເສຍຄ່າ.
• ຄໍາຕອບທີສາມແມ່ນຄ່າໃຊ້ຈ່າຍໃນການດໍາເນີນງານ. ນີ້ແມ່ນວິທີການທີ່ແຕກຕ່າງກັນເລັກນ້ອຍ. RedShift ແມ່ນການປຽບທຽບທີ່ດີ. ໃນ RedShift, ທ່ານສາມາດຕັດສິນໃຈໄດ້ໄວຫຼາຍ. ມັນຈະເຮັດວຽກໄດ້ດີ, ແຕ່ໃນເວລາດຽວກັນ, ທຸກໆຊົ່ວໂມງ, ທຸກໆມື້, ແລະທຸກໆເດືອນ, ທ່ານຈະຈ່າຍ Amazon ຂ້ອນຂ້າງຫຼາຍ, ເພາະວ່ານີ້ແມ່ນການບໍລິການທີ່ມີລາຄາແພງຫຼາຍ. Google BigQuery ຄືກັນ. ຖ້າມີຄົນໃຊ້ມັນ, ລາວຮູ້ວ່າຢູ່ທີ່ນັ້ນທ່ານສາມາດດໍາເນີນການຮ້ອງຂໍຫຼາຍຄັ້ງແລະໄດ້ຮັບໃບເກັບເງິນຫຼາຍຮ້ອຍໂດລາໃນທັນທີທັນໃດ.

ClickHouse ບໍ່ມີບັນຫາເຫຼົ່ານີ້.

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

• ກ່ອນອື່ນ ໝົດ, ນີ້ແມ່ນການວິເຄາະໂປແກຼມເວັບ, i.e. ນີ້ແມ່ນກໍລະນີທີ່ໃຊ້ທີ່ມາຈາກ Yandex.
• ບໍລິສັດ AdTech ຫຼາຍຄົນໃຊ້ ClickHouse.
• ບໍລິສັດຈໍານວນຫລາຍທີ່ຕ້ອງການວິເຄາະບັນທຶກການເຮັດທຸລະກໍາຈາກແຫຼ່ງຕ່າງໆ.
• ບໍລິສັດຈໍານວນຫນຶ່ງໃຊ້ ClickHouse ເພື່ອຕິດຕາມບັນທຶກຄວາມປອດໄພ. ພວກເຂົາອັບໂຫລດພວກເຂົາໄປທີ່ ClickHouse, ເຮັດບົດລາຍງານ, ແລະໄດ້ຮັບຜົນທີ່ພວກເຂົາຕ້ອງການ.
• ບໍລິສັດກໍາລັງເລີ່ມໃຊ້ມັນໃນການວິເຄາະທາງດ້ານການເງິນ, i.e. ຄ່ອຍໆທຸລະກິດຂະຫນາດໃຫຍ່ຍັງເຂົ້າຫາ ClickHouse.
• cloudflare. ຖ້າໃຜຜູ້ຫນຶ່ງຕິດຕາມ ClickHouse, ພວກເຂົາອາດຈະໄດ້ຍິນຊື່ຂອງບໍລິສັດນີ້. ນີ້ແມ່ນ ໜຶ່ງ ໃນຜູ້ປະກອບສ່ວນທີ່ ຈຳ ເປັນຈາກຊຸມຊົນ. ແລະພວກເຂົາມີການຕິດຕັ້ງ ClickHouse ທີ່ຮຸນແຮງຫຼາຍ. ຕົວຢ່າງ, ພວກເຂົາເຮັດເຄື່ອງຈັກ Kafka ສໍາລັບ ClickHouse.
• ບໍລິສັດໂທລະຄົມເລີ່ມນໍາໃຊ້. ຫຼາຍບໍລິສັດໃຊ້ ClickHouse ເປັນຫຼັກຖານສະແດງແນວຄວາມຄິດຫຼືໃນການຜະລິດແລ້ວ.
• ບໍລິສັດຫນຶ່ງໃຊ້ ClickHouse ເພື່ອຕິດຕາມຂະບວນການຜະລິດ. ພວກເຂົາເຈົ້າທົດສອບ microcircuits, ຂຽນອອກຊໍ່ຂອງຕົວກໍານົດການ, ມີປະມານ 2 ລັກສະນະ. ແລະຫຼັງຈາກນັ້ນພວກເຂົາວິເຄາະວ່າເກມແມ່ນດີຫຼືບໍ່ດີ.
• ການວິເຄາະ Blockchain. ມີບໍລິສັດລັດເຊຍເຊັ່ນ Bloxy.info. ນີ້ແມ່ນການວິເຄາະຂອງເຄືອຂ່າຍ ethereum. ພວກເຂົາເຈົ້າຍັງໄດ້ເຮັດສິ່ງນີ້ໃນ ClickHouse.

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

ແລະຖ້າທ່ານເບິ່ງບັນທຶກ, ຫຼັງຈາກນັ້ນ:

• Yandex: 500+ ເຊີບເວີ, ພວກເຂົາເກັບບັນທຶກ 25 ພັນລ້ານຕໍ່ມື້ຢູ່ທີ່ນັ້ນ.
• LifeStreet: 60 ເຊີບເວີ, ປະມານ 75 ຕື້ບັນທຶກຕໍ່ມື້. ມີເຄື່ອງແມ່ຂ່າຍຫນ້ອຍ, ບັນທຶກຫຼາຍກ່ວາໃນ Yandex.
• CloudFlare: 36 ເຊີບເວີ, ພວກເຂົາຊ່ວຍປະຢັດ 200 ຕື້ບັນທຶກຕໍ່ມື້. ພວກເຂົາເຈົ້າມີເຄື່ອງແມ່ຂ່າຍຫນ້ອຍລົງແລະເກັບຮັກສາຂໍ້ມູນຫຼາຍກວ່າເກົ່າ.
• Bloomberg: 102 ເຊີບເວີ, ປະມານນຶ່ງພັນຕື້ລາຍການຕໍ່ມື້. ເຈົ້າຂອງບັນທຶກ.

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

ນີ້ແມ່ນການວິເຄາະປຽບທຽບ, ບໍ່ຈໍາເປັນຕ້ອງຊອກຫາຕົວເລກຢ່າງແທ້ຈິງ. ນີ້ແມ່ນການວິເຄາະຂອງນັກທ່ອງທ່ຽວທີ່ອ່ານເອກະສານພາສາອັງກິດຢູ່ໃນເວັບໄຊທ໌ Altinity, ເພາະວ່າບໍ່ມີຄົນເວົ້າພາສາລັດເຊຍຢູ່ທີ່ນັ້ນ. ແລະລັດເຊຍ, Ukraine, Belarus, i.e. ພາກສ່ວນທີ່ເວົ້າພາສາລັດເຊຍຂອງຊຸມຊົນ, ເຫຼົ່ານີ້ແມ່ນຜູ້ໃຊ້ຈໍານວນຫລາຍທີ່ສຸດ. ຫຼັງຈາກນັ້ນມາສະຫະລັດແລະການາດາ. ຈີນ​ຈັບ​ໄດ້​ຫຼາຍ. ເກືອບ​ວ່າ​ບໍ່​ມີ​ຈີນ​ຢູ່​ໃນ​ຫົກ​ເດືອນ​ກ່ອນ, ປະຈຸ​ບັນ, ຈີນ​ໄດ້​ເອົາ​ຊະນະ​ເອີ​ລົບ​ແລ້ວ​ແລະ​ສືບ​ຕໍ່​ເຕີບ​ໂຕ. ເອີຣົບເກົ່າຍັງບໍ່ໄກ, ແລະຜູ້ນໍາໃນການນໍາໃຊ້ ClickHouse ແມ່ນ, oddly ພຽງພໍ, ປະເທດຝຣັ່ງ.

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

ເຫຼົ່ານີ້ແມ່ນຕົວຢ່າງຂອງການນໍາໃຊ້ ClickHouse ທີ່ແທ້ຈິງໃນບໍລິສັດຈໍານວນຫນຶ່ງ.

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

• LifeStreet ແມ່ນບໍລິສັດ Ad Tech ທີ່ມີເຕັກໂນໂລຢີທັງຫມົດທີ່ມາພ້ອມກັບເຄືອຂ່າຍໂຄສະນາ.
• ນາງມີສ່ວນຮ່ວມໃນການເພີ່ມປະສິດທິພາບການໂຄສະນາ, ການປະມູນແບບໂປຼແກຼມ.
• ຂໍ້ມູນຈໍານວນຫລາຍ: ປະມານ 10 ຕື້ເຫດການຕໍ່ມື້. ໃນເວລາດຽວກັນ, ເຫດການສາມາດແບ່ງອອກເປັນຫຼາຍເຫດການຍ່ອຍ.
• ມີລູກຄ້າຈໍານວນຫຼາຍຂອງຂໍ້ມູນນີ້, ແລະເຫຼົ່ານີ້ແມ່ນບໍ່ພຽງແຕ່ປະຊາຊົນ, ມີຫຼາຍ - ເຫຼົ່ານີ້ແມ່ນ algorithms ຕ່າງໆທີ່ມີການປະມູນໂຄງການ.

ບໍລິສັດໄດ້ມາໃນເສັ້ນທາງຍາວແລະ thorny. ແລະຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບມັນຢູ່ໃນ HighLoad. ຫນ້າທໍາອິດ, LifeStreet ໄດ້ຍ້າຍຈາກ MySQL (ດ້ວຍການຢຸດສັ້ນຢູ່ທີ່ Oracle) ໄປ Vertica. ແລະທ່ານສາມາດຊອກຫາເລື່ອງກ່ຽວກັບມັນ.

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

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

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

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

ແລະບໍ່ມີຫຍັງທີ່ຈະສົມທົບການທີ່ດີທີ່ມີຢູ່ໃນຖານຂໍ້ມູນການຄ້າແລະທັງຫມົດທີ່ບໍ່ເສຍຄ່າທີ່ມີຢູ່ໃນແຫຼ່ງເປີດ.

ບໍ່ມີຫຍັງຈົນກ່ວາ, ໂດຍບໍ່ຄາດຄິດ, Yandex ໄດ້ດຶງ ClickHouse, ຄືກັບ magician ຈາກຫມວກ, ຄືກັບກະຕ່າຍ. ແລະມັນເປັນການຕັດສິນໃຈທີ່ບໍ່ຄາດຄິດ, ພວກເຂົາຍັງຖາມຄໍາຖາມ: "ເປັນຫຍັງ?", ແຕ່ຢ່າງໃດກໍ່ຕາມ.

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

ຂ້າພະເຈົ້າບໍ່ຂີ້ກຽດເກີນໄປແລະເບິ່ງການທົດສອບ Yandex ໃນມື້ອື່ນ. ມັນຄືກັນຢູ່ທີ່ນັ້ນ: ClickHouse ແມ່ນສອງເທົ່າໄວກວ່າ Vertica, ດັ່ງນັ້ນພວກເຂົາມັກຈະເວົ້າກ່ຽວກັບມັນ.

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

ແລະໄດ້ຮັບຜົນການທົດສອບ, ແລະເບິ່ງມັນຈາກມຸມທີ່ແຕກຕ່າງກັນ, LifeStreet ໄດ້ໄປຫາ ClickHouse.

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

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

ຜົນໄດ້ຮັບແມ່ນ:

• ການເຄື່ອນຍ້າຍສົບຜົນສໍາເລັດແລະຫຼາຍກວ່າຫນຶ່ງປີລະບົບກໍາລັງເຮັດວຽກຢູ່ໃນການຜະລິດ.
• ຜົນຜະລິດແລະຄວາມຍືດຫຍຸ່ນໄດ້ເພີ່ມຂຶ້ນ. ໃນຈໍານວນ 10 ພັນລ້ານບັນທຶກທີ່ພວກເຮົາສາມາດເກັບໄດ້ຕໍ່ມື້ແລະຫຼັງຈາກນັ້ນເປັນເວລາສັ້ນໆ, LifeStreet ປະຈຸບັນເກັບຮັກສາ 75 ຕື້ບັນທຶກຕໍ່ມື້ແລະສາມາດເຮັດສິ່ງນີ້ໄດ້ເປັນເວລາ 3 ເດືອນຫຼືຫຼາຍກວ່ານັ້ນ. ຖ້າທ່ານນັບຢູ່ໃນຈຸດສູງສຸດ, ນີ້ແມ່ນສູງເຖິງຫນຶ່ງລ້ານເຫດການຕໍ່ວິນາທີ. ຫຼາຍກວ່າຫນຶ່ງລ້ານຄໍາຖາມ SQL ຕໍ່ມື້ມາຮອດລະບົບນີ້, ສ່ວນໃຫຍ່ແມ່ນມາຈາກຫຸ່ນຍົນທີ່ແຕກຕ່າງກັນ.
• ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າເຄື່ອງແມ່ຂ່າຍຫຼາຍໄດ້ຖືກນໍາໃຊ້ສໍາລັບ ClickHouse ກ່ວາ Vertica, ພວກເຂົາຍັງປະຫຍັດຮາດແວ, ເພາະວ່າແຜ່ນ SAS ລາຄາແພງຫຼາຍແມ່ນໃຊ້ໃນ Vertica. ClickHouse ໃຊ້ SATA. ແລະ​ເປັນ​ຫຍັງ​ຈຶ່ງ? ເນື່ອງຈາກວ່າໃນ Vertica insert ແມ່ນ synchronous. ແລະ synchronization ຮຽກຮ້ອງໃຫ້ແຜ່ນບໍ່ຊ້າລົງຫຼາຍ, ແລະຍັງວ່າເຄືອຂ່າຍບໍ່ຊ້າລົງເກີນໄປ, ນັ້ນແມ່ນ, ການດໍາເນີນງານລາຄາແພງຫຼາຍ. ແລະໃນ ClickHouse insert ແມ່ນ asynchronous. ຍິ່ງໄປກວ່ານັ້ນ, ທ່ານສາມາດຂຽນທຸກສິ່ງທຸກຢ່າງຢູ່ໃນທ້ອງຖິ່ນສະເຫມີ, ບໍ່ມີຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມສໍາລັບການນີ້, ດັ່ງນັ້ນຂໍ້ມູນສາມາດຖືກໃສ່ເຂົ້າໄປໃນ ClickHouse ໄວກວ່າເຂົ້າໄປໃນ Vertika, ເຖິງແມ່ນວ່າຢູ່ໃນໄດທີ່ຊ້າກວ່າ. ແລະການອ່ານແມ່ນກ່ຽວກັບການດຽວກັນ. ການອ່ານ SATA, ຖ້າພວກເຂົາຢູ່ໃນ RAID, ນີ້ແມ່ນໄວພຽງພໍ.
• ບໍ່ຈໍາກັດໂດຍໃບອະນຸຍາດ, i.e. 3 petabytes ຂອງຂໍ້ມູນໃນ 60 ເຄື່ອງແມ່ຂ່າຍ (20 ເຄື່ອງແມ່ຂ່າຍແມ່ນຫນຶ່ງ replica) ແລະ 6 ພັນຕື້ບັນທຶກໃນຄວາມເປັນຈິງແລະການລວບລວມ. ບໍ່ມີຫຍັງແບບນີ້ສາມາດຈ່າຍໄດ້ຢູ່ Vertica.

ຕອນນີ້ຂ້ອຍຫັນໄປຫາສິ່ງທີ່ປະຕິບັດໄດ້ໃນຕົວຢ່າງນີ້.

• ທໍາອິດແມ່ນໂຄງການທີ່ມີປະສິດທິພາບ. ຫຼາຍຂື້ນກັບ schema.
• ອັນທີສອງແມ່ນການຜະລິດ SQL ທີ່ມີປະສິດທິພາບ.

ການສອບຖາມ OLAP ປົກກະຕິແມ່ນການເລືອກ. ບາງຖັນໄປຫາກຸ່ມໂດຍ, ບາງຖັນໄປຫາໜ້າທີ່ລວມ. ມີບ່ອນທີ່, ຊຶ່ງສາມາດເປັນຕົວແທນເປັນ slice ຂອງ cube ໄດ້. ກຸ່ມທັງໝົດສາມາດຄິດໄດ້ວ່າເປັນການຄາດຄະເນ. ແລະນັ້ນແມ່ນເຫດຜົນທີ່ມັນເອີ້ນວ່າການວິເຄາະຂໍ້ມູນຫຼາຍຕົວແປ.

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

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

ແຕ່ມັນບໍ່ດີໃນ ClickHouse. ມີສອງເຫດຜົນ:

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

ແລະມີທາງອອກຈາກນີ້ຢູ່ໃນ ClickHouse. ເຖິງແມ່ນວ່າສອງ:

• ທໍາອິດແມ່ນການນໍາໃຊ້ວັດຈະນານຸກົມ. ວັດຈະນານຸກົມພາຍນອກແມ່ນສິ່ງທີ່ຊ່ວຍໃຫ້ 99% ແກ້ໄຂບັນຫາກັບ star-schema, ມີການປັບປຸງແລະອື່ນໆ.
• ອັນທີສອງແມ່ນການໃຊ້ arrays. Arrays ຍັງຊ່ວຍກໍາຈັດການຮ່ວມແລະບັນຫາກັບການປົກກະຕິ.

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

• ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງເຂົ້າຮ່ວມ.
• ນີ້ແມ່ນຕົວແທນຂະໜາດນ້ອຍ 1 ຫາຫຼາຍ.
• ແລະໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, arrays ແມ່ນເຮັດສໍາລັບ geeks. ເຫຼົ່ານີ້ແມ່ນຫນ້າທີ່ lambda ແລະອື່ນໆ.

ນີ້ບໍ່ແມ່ນສໍາລັບຄໍາສີແດງ. ນີ້​ແມ່ນ​ເປັນ​ຫນ້າ​ທີ່​ທີ່​ມີ​ອໍາ​ນາດ​ຫຼາຍ​ທີ່​ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ​ເຮັດ​ສິ່ງ​ຈໍາ​ນວນ​ຫຼາຍ​ໃນ​ວິ​ທີ​ການ​ທີ່​ງ່າຍ​ດາຍ​ແລະ elegant ຫຼາຍ​.

ຕົວຢ່າງທົ່ວໄປທີ່ຊ່ວຍແກ້ໄຂ arrays. ຕົວຢ່າງເຫຼົ່ານີ້ແມ່ນງ່າຍດາຍແລະຈະແຈ້ງພຽງພໍ:

• ຄົ້ນຫາໂດຍ tags. ຖ້າທ່ານມີ hashtags ຢູ່ທີ່ນັ້ນແລະຕ້ອງການຊອກຫາບາງຂໍ້ຄວາມໂດຍ hashtag.
• ຄົ້ນຫາໂດຍຄູ່ຄີ-ຄ່າ. ຍັງມີຄຸນລັກສະນະບາງຢ່າງທີ່ມີມູນຄ່າ.
• ການເກັບຮັກສາລາຍຊື່ຂອງກະແຈທີ່ທ່ານຕ້ອງການແປເປັນອັນອື່ນ.

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

ແລະໃນ ClickHouse, ທ່ານບໍ່ຈໍາເປັນຕ້ອງເຮັດຫຍັງ, ມັນພຽງພໍທີ່ຈະອະທິບາຍ string array ສໍາລັບ hashtags ຫຼືສ້າງໂຄງສ້າງທີ່ຊ້ອນກັນສໍາລັບລະບົບ key-value.

ໂຄງສ້າງ Nested ອາດຈະບໍ່ແມ່ນຊື່ທີ່ດີທີ່ສຸດ. ເຫຼົ່ານີ້ແມ່ນສອງ array ທີ່ມີສ່ວນທົ່ວໄປໃນຊື່ແລະບາງລັກສະນະທີ່ກ່ຽວຂ້ອງ.

ແລະມັນງ່າຍຫຼາຍທີ່ຈະຄົ້ນຫາໂດຍແທັກ. ມີຫນ້າທີ່ has, ເຊິ່ງກວດເບິ່ງວ່າ array ມີອົງປະກອບ. ທຸກຄົນ, ໄດ້ພົບເຫັນລາຍການທັງໝົດທີ່ກ່ຽວຂ້ອງກັບກອງປະຊຸມຂອງພວກເຮົາ.

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

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

ຕົວຢ່າງອື່ນ. ທ່ານມີ array ບ່ອນທີ່ທ່ານເກັບຮັກສາ ID ໄດ້. ແລະທ່ານສາມາດແປໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນຊື່. ຟັງຊັນ arrayMap. ນີ້ແມ່ນຟັງຊັນ lambda ປົກກະຕິ. ທ່ານຜ່ານການສະແດງອອກຂອງ lambda ຢູ່ທີ່ນັ້ນ. ແລະນາງດຶງເອົາມູນຄ່າຂອງຊື່ສໍາລັບແຕ່ລະ ID ຈາກວັດຈະນານຸກົມ.

ການຄົ້ນຫາສາມາດເຮັດໄດ້ໃນລັກສະນະດຽວກັນ. ຟັງຊັນ predicate ແມ່ນຜ່ານການກວດສອບສິ່ງທີ່ອົງປະກອບທີ່ກົງກັນ.

ສິ່ງເຫຼົ່ານີ້ເຮັດໃຫ້ວົງຈອນງ່າຍດາຍຫຼາຍແລະແກ້ໄຂບັນຫາຫຼາຍ.

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

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

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

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

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

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

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

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

ຂໍໃຫ້ກ້າວໄປສູ່ຕົວຢ່າງຕໍ່ໄປ. ບໍລິສັດ X ຈາກສະຫະລັດ. ລາວ​ກໍາ​ລັງ​ເຮັດ​ຫຍັງ?

ມີໜ້າວຽກ:

• ການເຊື່ອມໂຍງແບບອອບໄລນ໌ຂອງທຸລະກໍາການໂຄສະນາ.
• ການສ້າງແບບຈໍາລອງການຜູກມັດທີ່ແຕກຕ່າງກັນ.

ສະຖານະການແມ່ນຫຍັງ?

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

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

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

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

ມີຫຼາຍຕົວແບບຜູກມັດ.

ທີ່ນິຍົມຫຼາຍທີ່ສຸດແມ່ນ:

• ການໂຕ້ຕອບຫຼ້າສຸດ, ບ່ອນທີ່ການໂຕ້ຕອບແມ່ນການຄລິກຫຼືການປະທັບໃຈ.
• ການໂຕ້ຕອບຄັ້ງທໍາອິດ, i.e. ສິ່ງທໍາອິດທີ່ນໍາຄົນໄປຫາເວັບໄຊທ໌.
• ການປະສົມປະສານເສັ້ນ - ທັງຫມົດເທົ່າທຽມກັນ.
• ການຫຼຸດໜ້ອຍຖອຍລົງ.
• ແລະອື່ນໆ.

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

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

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

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

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

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

ນັ້ນແມ່ນ, ຊຸດຂອງ antipatterns.

ແຕ່ຢ່າງໃດກໍ່ຕາມມັນໄດ້ຫັນອອກເພື່ອເຮັດໃຫ້ລະບົບທີ່ເຮັດວຽກໄດ້ດີຫຼາຍ.

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

ມັນແມ່ນຢູ່ໃນຮູບແບບນີ້ທີ່ມັນບໍ່ໄດ້ເຮັດວຽກດີຫຼາຍ. ແລະເພື່ອເຮັດໃຫ້ມັນງ່າຍຂຶ້ນສໍາລັບ ClickHouse, ເມື່ອມີການຮ້ອງຂໍໂດຍ id ການຢ້ຽມຢາມ, ພວກເຂົາເຈົ້າຈັດກຸ່ມການຮ້ອງຂໍເຫຼົ່ານີ້ເຂົ້າໄປໃນຕັນຂອງ 1-000 visit ids ແລະດຶງອອກທຸລະກໍາທັງຫມົດສໍາລັບ 2-000 ຄົນ. ແລະຫຼັງຈາກນັ້ນມັນທັງຫມົດເຮັດວຽກ.

ຖ້າທ່ານເບິ່ງພາຍໃນ ClickHouse, ຫຼັງຈາກນັ້ນມີພຽງແຕ່ 3 ຕາຕະລາງຕົ້ນຕໍທີ່ໃຫ້ບໍລິການທັງຫມົດນີ້.

ຕາຕະລາງທໍາອິດທີ່ບັນທຶກຖືກອັບໂຫລດ, ແລະບັນທຶກໄດ້ຖືກອັບໂຫລດເກືອບໂດຍບໍ່ມີການປຸງແຕ່ງ.

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

ນີ້ແມ່ນຂໍ້ຄວາມທີ່ຂຽນໃນ SQL. ຂ້າພະເຈົ້າຢາກຈະສະແດງຄວາມຄິດເຫັນກ່ຽວກັບສິ່ງທີ່ສໍາຄັນຈໍານວນຫນຶ່ງໃນນັ້ນ.

ສິ່ງທີ່ສໍາຄັນທໍາອິດແມ່ນຄວາມສາມາດໃນການດຶງຄໍລໍາແລະພາກສະຫນາມຈາກ json ໃນ ClickHouse. ນັ້ນແມ່ນ, ClickHouse ມີບາງວິທີການເຮັດວຽກກັບ json. ພວກເຂົາເຈົ້າແມ່ນຫຼາຍ, primitive ຫຼາຍ.

visitParamExtractInt ອະນຸຍາດໃຫ້ທ່ານສາມາດສະກັດຄຸນລັກສະນະຈາກ json, i.e. hit ທໍາອິດເຮັດວຽກ. ແລະວິທີນີ້ທ່ານສາມາດດຶງ id ທຸລະກໍາຫຼືໄປຢ້ຽມຢາມ id. ຄັ້ງ​ນີ້.

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

ໃນ​ກໍ​ລະ​ນີ​ນີ້, materialized view is for raw row . ແລະຕາຕະລາງທໍາອິດທີ່ມີໄມ້ທ່ອນດິບແມ່ນຖືກນໍາໃຊ້ພຽງແຕ່. ແລະລາວເຮັດຫຍັງ? ກ່ອນອື່ນ ໝົດ, ມັນປ່ຽນການຈັດລຽງ, i.e. ການຈັດຮຽງດຽວນີ້ໄປໂດຍ id ການຢ້ຽມຢາມ, ເພາະວ່າພວກເຮົາຕ້ອງການດຶງການເຮັດທຸລະກໍາຂອງລາວຢ່າງໄວວາສໍາລັບບຸກຄົນສະເພາະ.

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

Snapshot ຍັງໃຊ້ຄຸນສົມບັດ ClickHouse ທີ່ຫນ້າສົນໃຈອື່ນໆ.

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

• ການຜູກມັດແມ່ນ "decoupled" ຈາກ Runtime.
• ເຖິງ 3 ຕື້ທຸລະກໍາຕໍ່ເດືອນຖືກເກັບຮັກສາແລະປຸງແຕ່ງ. ນີ້ແມ່ນຄໍາສັ່ງຂອງຂະຫນາດຫຼາຍກ່ວາມັນຢູ່ໃນ Cassandra, i.e. ໃນລະບົບການເຮັດທຸລະກໍາປົກກະຕິ.
• ກຸ່ມຂອງເຊີບເວີ ClickHouse 2x5. 5 ເຊີບເວີແລະແຕ່ລະເຄື່ອງແມ່ຂ່າຍມີ replica. ນີ້ແມ່ນຫນ້ອຍກວ່າທີ່ມັນຢູ່ໃນ Cassandra ເພື່ອເຮັດການລະບຸເຫດຜົນຄລິກ, ແລະໃນທີ່ນີ້ພວກເຮົາມີຄວາມປະທັບໃຈໂດຍອີງໃສ່. ນັ້ນແມ່ນ, ແທນທີ່ຈະເພີ່ມຈໍານວນເຄື່ອງແມ່ຂ່າຍໂດຍ 30 ເທື່ອ, ພວກເຂົາເຈົ້າໄດ້ຈັດການຫຼຸດຜ່ອນພວກມັນ.

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

ແລະ​ວຽກ​ງານ​ແມ່ນ​:

• ມີປະມານ 5 ຮຸ້ນ.
• ວົງຢືມທຸກໆ 100 milliseconds ແມ່ນເປັນທີ່ຮູ້ຈັກ.
• ຂໍ້ມູນໄດ້ຖືກສະສົມຫຼາຍກວ່າ 10 ປີ. ປາກົດຂື້ນ, ສໍາລັບບາງບໍລິສັດຫຼາຍ, ສໍາລັບບາງຫນ້ອຍ.
• ມີທັງໝົດປະມານ 100 ຕື້ແຖວ.

ແລະມັນຈໍາເປັນຕ້ອງຄິດໄລ່ຄວາມກ່ຽວຂ້ອງຂອງການປ່ຽນແປງ.

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

ການວິເຄາະການປ່ຽນແປງເຊິ່ງກັນແລະກັນເຫຼົ່ານີ້, ຫນຶ່ງສາມາດເຮັດໃຫ້ການຄາດຄະເນໃນຕະຫຼາດການເງິນ.

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

ແລະຫຼັງຈາກນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງຄິດໄລ່ຄວາມກ່ຽວຂ້ອງກັນ, ແລະຄວາມສໍາພັນຕ້ອງໄດ້ຮັບການຄິດໄລ່ສໍາລັບແຕ່ລະຄູ່. ສໍາລັບ 5 ຮຸ້ນ, ຄູ່ແມ່ນ 000 ລ້ານ. ແລະນີ້ແມ່ນຫຼາຍ, i.e. 12,5 ເທື່ອ, ມັນຈໍາເປັນຕ້ອງຄິດໄລ່ພຽງແຕ່ຫນ້າທີ່ທີ່ກ່ຽວຂ້ອງກັນ.

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

ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະມີເວລາຢ່າງຫນ້ອຍ somehow, ເພາະວ່າທັງຫມົດນີ້ເຮັດວຽກຫຼາຍ, ຊ້າຫຼາຍກ່ອນທີ່ ClickHouse ມາ.

ພວກເຂົາເຈົ້າພະຍາຍາມຄິດໄລ່ມັນຢູ່ໃນ Hadoop, ໃນ Spark, ໃນ Greenplum. ແລະທັງຫມົດນີ້ແມ່ນຊ້າຫຼາຍຫຼືລາຄາແພງ. ນັ້ນແມ່ນ, ມັນເປັນໄປໄດ້ທີ່ຈະຄິດໄລ່ບາງຢ່າງ, ແຕ່ຫຼັງຈາກນັ້ນມັນມີລາຄາແພງ.

ແລະຫຼັງຈາກນັ້ນ ClickHouse ມາພ້ອມແລະສິ່ງຕ່າງໆໄດ້ດີຂຶ້ນຫຼາຍ.

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

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

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

ຫຼັງຈາກນັ້ນ, ມັນສາມາດ replicated. ຕົວອັກສອນ "r" ຫມາຍຄວາມວ່າພວກເຮົາເຮັດຊ້ໍາຂໍ້ມູນນີ້. ນັ້ນແມ່ນ, ພວກເຮົາມີຂໍ້ມູນດຽວກັນຢູ່ໃນທັງສາມເຄື່ອງແມ່ຂ່າຍ - ເຫຼົ່ານີ້ແມ່ນ arrays.

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

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

ໃນຫຼັກຖານສະແດງແນວຄວາມຄິດ, ວຽກງານແມ່ນວຽກງານຍ່ອຍ, i.e., ຂໍ້ມູນຫນ້ອຍຖືກປະຕິບັດ. ແລະພຽງແຕ່ສາມເຄື່ອງແມ່ຂ່າຍ.

ສອງຂັ້ນຕອນທໍາອິດເຫຼົ່ານີ້: ການຄິດໄລ່ Log_return ແລະການຫໍ່ຢູ່ໃນ arrays ໃຊ້ເວລາປະມານຫນຶ່ງຊົ່ວໂມງ.

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

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

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

ແລະສະຫຼຸບຄໍາເວົ້າສັ້ນໆນີ້, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າໃນປັດຈຸບັນ ClickHouse ໄດ້ຍຶດຫມັ້ນຢູ່ໃນອານາເຂດຂອງທັງຖານຂໍ້ມູນການຄ້າແລະຖານຂໍ້ມູນ open source, i.e. ໂດຍສະເພາະສໍາລັບການວິເຄາະ. ລາວເຫມາະກັບພູມສັນຖານນີ້ຢ່າງສົມບູນ. ແລະສິ່ງທີ່ຫຼາຍກວ່ານັ້ນ, ມັນຊ້າໆເລີ່ມຝູງຄົນອື່ນ, ເພາະວ່າເມື່ອທ່ານມີ ClickHouse, ທ່ານບໍ່ຕ້ອງການ InfiniDB. Vertika ອາດຈະບໍ່ຕ້ອງການໃນໄວໆນີ້ຖ້າພວກເຂົາເຮັດການສະຫນັບສະຫນູນ SQL ປົກກະຕິ. ມ່ວນ!

-ຂອບໃຈສໍາລັບບົດລາຍງານ! ຫນ້າສົນໃຈຫຼາຍ! ມີການປຽບທຽບກັບ Apache Phoenix ບໍ?

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

• (Aleksey Milovidov) Apache Phoenix ແມ່ນເຄື່ອງຈັກ SQL ທີ່ຂັບເຄື່ອນໂດຍ Hbase. Hbase ສ່ວນໃຫຍ່ແມ່ນສໍາລັບສະຖານະການເຮັດວຽກທີ່ສໍາຄັນ. ຢູ່ທີ່ນັ້ນ, ໃນແຕ່ລະແຖວ, ສາມາດມີຈໍານວນຄໍລໍາທີ່ມີຊື່ທີ່ມັກ. ນີ້ສາມາດເວົ້າກ່ຽວກັບລະບົບເຊັ່ນ Hbase, Cassandra. ແລະມັນແມ່ນການສອບຖາມການວິເຄາະຢ່າງຮຸນແຮງທີ່ຊັດເຈນທີ່ຈະບໍ່ເຮັດວຽກປົກກະຕິສໍາລັບພວກເຂົາ. ຫຼືທ່ານອາດຈະຄິດວ່າພວກມັນເຮັດວຽກໄດ້ດີຖ້າທ່ານບໍ່ມີປະສົບການໃດໆກັບ ClickHouse.

• Спасибо

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

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

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

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

ມັນ​ເປັນ​ທີ່​ຈະ​ແຈ້ງ. ທ່ານເວົ້າວ່າ 50 ຊົ່ວໂມງໄດ້ຖືກປຸງແຕ່ງ. ມັນແມ່ນຕັ້ງແຕ່ເລີ່ມຕົ້ນ, ທ່ານໄດ້ໂຫລດຂໍ້ມູນຫຼືໄດ້ຮັບຜົນໄດ້ຮັບຈາກເວລາໃດ?

ແມ່ນແລ້ວ.

OK ຂອບໃຈຫຼາຍໆ.

ນີ້ແມ່ນຢູ່ໃນ 3 ກຸ່ມເຊີບເວີ.

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

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

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

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

ຂໍຂອບໃຈທ່ານ.

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