ການນໍາໃຊ້ Clickhouse ເປັນການທົດແທນສໍາລັບ ELK, Big Query ແລະ TimescaleDB

clickhouse ເປັນລະບົບການຄຸ້ມຄອງຖານຂໍ້ມູນ columnar open source ສໍາລັບການປະມວນຜົນແບບສອບຖາມການວິເຄາະອອນໄລນ໌ (OLAP), ສ້າງໂດຍ Yandex. ມັນຖືກນໍາໃຊ້ໂດຍ Yandex, CloudFlare, VK.com, Badoo ແລະບໍລິການອື່ນໆໃນທົ່ວໂລກເພື່ອເກັບຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍ (ໃສ່ຫລາຍພັນແຖວຕໍ່ວິນາທີຫຼື petabytes ຂອງຂໍ້ມູນທີ່ເກັບໄວ້ໃນແຜ່ນ).

ໃນແບບປົກກະຕິ, "string" DBMS, ຕົວຢ່າງຂອງ MySQL, Postgres, MS SQL Server, ຂໍ້ມູນຖືກເກັບໄວ້ໃນຄໍາສັ່ງນີ້:

ໃນ​ກໍ​ລະ​ນີ​ນີ້, ຄ່າ​ທີ່​ກ່ຽວ​ຂ້ອງ​ກັບ​ແຖວ​ດຽວ​ກັນ​ແມ່ນ​ໄດ້​ຖືກ​ເກັບ​ໄວ້​ທາງ​ດ້ານ​ຮ່າງ​ກາຍ. ໃນຖັນ DBMS, ຄ່າຈາກຖັນທີ່ແຕກຕ່າງກັນຖືກເກັບໄວ້ແຍກຕ່າງຫາກ, ແລະຂໍ້ມູນຂອງຖັນຫນຶ່ງຈະຖືກເກັບໄວ້ຮ່ວມກັນ:

ຕົວຢ່າງຂອງ columnar DBMSs ແມ່ນ Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.

ບໍລິສັດເປັນຜູ້ສົ່ງຕໍ່ທາງໄປສະນີ ຄິວຕີ້ ຂ້ອຍເລີ່ມໃຊ້ Clickhouse ໃນປີ 2018 ສໍາລັບການລາຍງານແລະມີຄວາມປະທັບໃຈຫຼາຍກັບຄວາມງ່າຍດາຍ, ການຂະຫຍາຍ, ການສະຫນັບສະຫນູນ SQL ແລະຄວາມໄວຂອງມັນ. ຄວາມໄວຂອງ DBMS ນີ້ຕິດກັບ magic.

ຄວາມສະດວກ

Clickhouse ຕິດຕັ້ງໃນ Ubuntu ດ້ວຍຄໍາສັ່ງດຽວ. ຖ້າທ່ານຮູ້ SQL, ທ່ານທັນທີສາມາດເລີ່ມຕົ້ນການນໍາໃຊ້ Clickhouse ສໍາລັບຄວາມຕ້ອງການຂອງທ່ານ. ຢ່າງໃດກໍ່ຕາມ, ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າທ່ານສາມາດ "ສະແດງຕາຕະລາງສ້າງ" ໃນ MySQL ແລະຄັດລອກ SQL ໃນ Clickhouse.

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

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

ຜະລິດຕະພັນ

• ດັດຊະນີ ການປຽບທຽບ Clickhouse ກັບ Vertica ແລະ MySQL ໃນການຕັ້ງຄ່າເຊີບເວີ: ສອງຊັອກເກັດ Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; RAM 128 GiB; md RAID-5 ເທິງ 8 6TB SATA HDD, ext4.
• ດັດຊະນີ ການປຽບທຽບ Clickhouse ກັບ Amazon RedShift cloud storage.
• ບົດຄັດຫຍໍ້ຂອງ blog Cloudflare ກ່ຽວກັບການປະຕິບັດ Clickhouse:

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

ClickHouse ບໍ່ສະຫນັບສະຫນູນການຮັບຂໍ້ມູນໂດຍກົງຈາກ Kafka, ຍ້ອນວ່າມັນເປັນພຽງແຕ່ຖານຂໍ້ມູນ, ດັ່ງນັ້ນພວກເຮົາໄດ້ຂຽນບໍລິການອະແດບເຕີຂອງພວກເຮົາເອງໃນ Go. ມັນອ່ານຂໍ້ຄວາມທີ່ເຂົ້າລະຫັດ Cap'n Proto ຈາກ Kafka, ປ່ຽນພວກມັນເປັນ TSV, ແລະໃສ່ພວກມັນເຂົ້າໄປໃນ ClickHouse ໃນຊຸດຜ່ານອິນເຕີເຟດ HTTP. ຕໍ່ມາພວກເຮົາໄດ້ຂຽນຄືນການບໍລິການນີ້ເພື່ອໃຊ້ຫ້ອງສະໝຸດ Go ໂດຍສົມທົບກັບອິນເຕີເຟດ ClickHouse ຂອງພວກເຮົາເອງເພື່ອປັບປຸງປະສິດທິພາບ. ໃນເວລາທີ່ການປະເມີນການປະຕິບັດການຮັບຊອງ, ພວກເຮົາໄດ້ຄົ້ນພົບສິ່ງທີ່ສໍາຄັນ - ມັນໄດ້ຫັນອອກວ່າສໍາລັບ ClickHouse ການປະຕິບັດນີ້ແມ່ນຂຶ້ນກັບຂະຫນາດຂອງແພັກເກັດ, ນັ້ນແມ່ນ, ຈໍານວນແຖວທີ່ຖືກໃສ່ໃນເວລາດຽວກັນ. ເພື່ອເຂົ້າໃຈວ່າເປັນຫຍັງມັນເກີດຂຶ້ນ, ພວກເຮົາໄດ້ສຶກສາວິທີການ ClickHouse ເກັບຂໍ້ມູນ.

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

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

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

ເນື່ອງຈາກຖັນທັງໝົດຖືກຈັດຮຽງໂດຍ "ກະແຈຫຼັກ", ໄຟລ໌ດັດສະນີພຽງແຕ່ມີປ້າຍກຳກັບ (ແຖວທີ່ຈັບໄດ້) ຂອງທຸກໆແຖວ Nth, ເພື່ອໃຫ້ສາມາດເກັບພວກມັນໄວ້ໃນຄວາມຊົງຈຳໄດ້ ແມ້ແຕ່ຕາຕະລາງໃຫຍ່ຫຼາຍ. ສໍາລັບຕົວຢ່າງ, ທ່ານສາມາດກໍານົດຄ່າເລີ່ມຕົ້ນເປັນ "ຫມາຍທຸກແຖວທີ 8192", ຫຼັງຈາກນັ້ນ "ຫນ້ອຍ" ດັດສະນີຕາຕະລາງທີ່ມີ 1 ພັນຕື້. ເສັ້ນທີ່ເຫມາະກັບຄວາມຊົງຈໍາໄດ້ຢ່າງງ່າຍດາຍຈະໃຊ້ເວລາພຽງແຕ່ 122 ຕົວອັກສອນ.

ການພັດທະນາລະບົບ

ການພັດທະນາແລະການປັບປຸງ Clickhouse ສາມາດຕິດຕາມໄດ້ Github repos ແລະໃຫ້ແນ່ໃຈວ່າຂະບວນການ "ເຕີບໃຫຍ່" ເກີດຂື້ນໃນຈັງຫວະທີ່ຫນ້າປະທັບໃຈ.

ຄວາມນິຍົມ

ມັນເບິ່ງຄືວ່າຄວາມນິຍົມຂອງ Clickhouse ກໍາລັງເຕີບໃຫຍ່ຂຶ້ນ, ໂດຍສະເພາະໃນຊຸມຊົນທີ່ເວົ້າພາສາລັດເຊຍ. ກອງປະຊຸມການໂຫຼດສູງ 2018 ປີທີ່ຜ່ານມາ (ມອດໂກ, ວັນທີ 8-9 ພະຈິກ 2018) ໄດ້ສະແດງໃຫ້ເຫັນວ່າ monsters ເຊັ່ນ vk.com ແລະ Badoo ໃຊ້ Clickhouse, ເຊິ່ງໃສ່ຂໍ້ມູນ (ຕົວຢ່າງ, ບັນທຶກ) ຈາກຫລາຍສິບພັນເຄື່ອງແມ່ຂ່າຍພ້ອມໆກັນ. ໃນວິດີໂອ 40 ນາທີ Yuri Nasretdinov ຈາກທີມງານ VKontakte ເວົ້າກ່ຽວກັບວິທີທີ່ມັນເຮັດໄດ້. ໄວໆນີ້ພວກເຮົາຈະປະກາດບົດບັນທຶກກ່ຽວກັບ Habr ເພື່ອຄວາມສະດວກໃນການເຮັດວຽກກັບວັດສະດຸ.

ຄໍາຮ້ອງສະຫມັກ

ຫຼັງຈາກໃຊ້ເວລາໃນການຄົ້ນຄວ້າ, ຂ້າພະເຈົ້າຄິດວ່າມີພື້ນທີ່ທີ່ ClickHouse ສາມາດເປັນປະໂຫຍດຫຼືສາມາດທົດແທນການແກ້ໄຂແບບດັ້ງເດີມແລະທີ່ນິຍົມອື່ນໆເຊັ່ນ MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot ແລະ. Druid. ຕໍ່ໄປນີ້ແມ່ນລາຍລະອຽດຂອງການໃຊ້ ClickHouse ເພື່ອຍົກລະດັບຫຼືປ່ຽນແທນ DBMS ຂ້າງເທິງ.

ຂະຫຍາຍ MySQL ແລະ PostgreSQL

ບໍ່ດົນມານີ້, ພວກເຮົາໄດ້ປ່ຽນບາງສ່ວນ MySQL ດ້ວຍ ClickHouse ສໍາລັບເວທີຈົດຫມາຍຂ່າວ ຈົດໝາຍຂ່າວ Mautic. ບັນຫາແມ່ນວ່າ MySQL ເນື່ອງຈາກການອອກແບບທີ່ບໍ່ດີໄດ້ບັນທຶກທຸກອີເມວທີ່ສົ່ງແລະທຸກໆການເຊື່ອມຕໍ່ໃນອີເມວນັ້ນດ້ວຍ base64 hash, ສ້າງຕາຕະລາງ MySQL ຂະຫນາດໃຫຍ່ (email_stats). ຫຼັງຈາກສົ່ງອີເມວພຽງແຕ່ 10 ລ້ານກັບຜູ້ຈອງບໍລິການ, ຕາຕະລາງນີ້ຄອບຄອງພື້ນທີ່ໄຟລ໌ 150 GB, ແລະ MySQL ເລີ່ມ "ໂງ່" ໃນການສອບຖາມງ່າຍໆ. ເພື່ອແກ້ໄຂບັນຫາພື້ນທີ່ໄຟລ໌, ພວກເຮົາປະສົບຜົນສໍາເລັດໃນການບີບອັດຕາຕະລາງ InnoDB, ເຊິ່ງຫຼຸດລົງມັນໂດຍປັດໃຈ 4. ຢ່າງໃດກໍ່ຕາມ, ມັນຍັງບໍ່ມີຄວາມຫມາຍທີ່ຈະເກັບຮັກສາຫຼາຍກວ່າ 20-30 ລ້ານອີເມວໃນ MySQL ພຽງແຕ່ສໍາລັບ sake ຂອງປະຫວັດສາດການອ່ານ, ຍ້ອນວ່າການສອບຖາມງ່າຍໆທີ່ສໍາລັບບາງເຫດຜົນຕ້ອງໄດ້ເຮັດການສະແກນຢ່າງເຕັມທີ່ໃນການແລກປ່ຽນແລະ I / O ຫນັກ. overhead, ທີ່ພວກເຮົາໄດ້ຮັບຄໍາເຕືອນຈາກ Zabbix ເປັນປະຈໍາ.

Clickhouse ໃຊ້ສອງລະບົບການບີບອັດທີ່ຫຼຸດລົງຈໍານວນຂໍ້ມູນປະມານ 3-4 ເທື່ອ, ແຕ່ໃນກໍລະນີນີ້, ຂໍ້ມູນໂດຍສະເພາະແມ່ນ "ບີບອັດ".

ການທົດແທນ ELK

ອີງຕາມປະສົບການຂອງຂ້ອຍເອງ, ELK stack (ElasticSearch, Logstash ແລະ Kibana, ໃນກໍລະນີນີ້ໂດຍສະເພາະ ElasticSearch) ຕ້ອງການຊັບພະຍາກອນຫຼາຍທີ່ຈະດໍາເນີນການຫຼາຍກ່ວາຄວາມຈໍາເປັນເພື່ອເກັບບັນທຶກ. ElasticSearch ເປັນເຄື່ອງຈັກທີ່ດີຖ້າທ່ານຕ້ອງການການຄົ້ນຫາບັນທຶກຂໍ້ຄວາມເຕັມທີ່ດີ (ທີ່ຂ້ອຍບໍ່ຄິດວ່າທ່ານຕ້ອງການແທ້ໆ), ແຕ່ຂ້ອຍສົງໄສວ່າເປັນຫຍັງມັນຈຶ່ງກາຍເປັນເຄື່ອງຈັກບັນທຶກມາດຕະຖານ de facto. ປະສິດທິພາບ ingest ຂອງມັນບວກກັບ Logstash ໄດ້ໃຫ້ບັນຫາພວກເຮົາເຖິງແມ່ນວ່າພາຍໃຕ້ການໂຫຼດແສງສະຫວ່າງພໍສົມຄວນແລະຮຽກຮ້ອງໃຫ້ພວກເຮົາເພີ່ມ RAM ແລະພື້ນທີ່ດິດຫຼາຍ. ເປັນຖານຂໍ້ມູນ, Clickhouse ແມ່ນດີກ່ວາ ElasticSearch ສໍາລັບເຫດຜົນດັ່ງຕໍ່ໄປນີ້:

• SQL ພາສາສະຫນັບສະຫນູນ;
• ລະດັບທີ່ດີທີ່ສຸດຂອງການບີບອັດຂອງຂໍ້ມູນທີ່ເກັບໄວ້;
• ສະຫນັບສະຫນູນການຄົ້ນຫາແບບປົກກະຕິ Regex ແທນທີ່ຈະຊອກຫາຂໍ້ຄວາມເຕັມ;
• ປັບປຸງການຈັດຕາຕະລາງການສອບຖາມ ແລະປະສິດທິພາບໂດຍລວມທີ່ດີກວ່າ.

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

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

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

ການທົດແທນຂອງ Google Big Query ແລະ Amazon RedShift (ການແກ້ໄຂສໍາລັບບໍລິສັດຂະຫນາດໃຫຍ່)

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

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

ໃນບົດຄວາມໂດຍ Alexander Zaitsev, ຜູ້ຮ່ວມກໍ່ຕັ້ງຂອງ Altinity "ຍ້າຍໄປ ClickHouse" ອະທິບາຍຜົນປະໂຫຍດຂອງການຍົກຍ້າຍ DBMS ດັ່ງກ່າວ.

ການທົດແທນ TimescaleDB

TimescaleDB ແມ່ນການຂະຫຍາຍ PostgreSQL ທີ່ເພີ່ມປະສິດທິພາບການເຮັດວຽກກັບຊຸດເວລາຂອງເວລາໃນຖານຂໍ້ມູນປົກກະຕິ (https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

ເຖິງແມ່ນວ່າ ClickHouse ບໍ່ແມ່ນຄູ່ແຂ່ງທີ່ຮ້າຍແຮງໃນ niche ຊຸດເວລາ, ແຕ່ໃນແງ່ຂອງໂຄງສ້າງຄໍລໍາແລະການປະຕິບັດການສອບຖາມ vector, ມັນໄວກວ່າ TimescaleDB ໃນກໍລະນີຫຼາຍທີ່ສຸດຂອງການດໍາເນີນການສອບຖາມການວິເຄາະ. ໃນເວລາດຽວກັນ, ການປະຕິບັດການຮັບຂໍ້ມູນແພັກເກັດ ClickHouse ແມ່ນສູງກວ່າ 3 ເທົ່າ, ນອກຈາກນັ້ນ, ມັນໃຊ້ພື້ນທີ່ດິດຫນ້ອຍລົງ 20 ເທົ່າ, ເຊິ່ງເປັນສິ່ງສໍາຄັນແທ້ໆສໍາລັບການປະມວນຜົນຂໍ້ມູນປະຫວັດສາດທີ່ມີປະລິມານຫຼາຍ: 
https://www.altinity.com/blog/ClickHouse-for-time-series.

ບໍ່ເຫມືອນກັບ ClickHouse, ວິທີດຽວທີ່ຈະຊ່ວຍປະຢັດພື້ນທີ່ດິດໃນ TimescaleDB ແມ່ນການນໍາໃຊ້ ZFS ຫຼືລະບົບໄຟລ໌ທີ່ຄ້າຍຄືກັນ.

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

• ການຕິດຕັ້ງຂະຫນາດນ້ອຍທີ່ມີ RAM ຫນ້ອຍຫຼາຍ (<3 GB);
• ຈໍານວນຂະຫນາດໃຫຍ່ຂອງ INSERTs ຂະຫນາດນ້ອຍທີ່ທ່ານບໍ່ຕ້ອງການທີ່ຈະ buffer ເປັນ fragments ໃຫຍ່;
• ຄວາມສອດຄ່ອງ, ຄວາມສອດຄ່ອງ ແລະຄວາມຕ້ອງການ ACID ທີ່ດີຂຶ້ນ;
• ສະຫນັບສະຫນູນ PostGIS;
• ຜະສົມຜະສານກັບຕາຕະລາງ PostgreSQL ທີ່ມີຢູ່ແລ້ວ, ນັບຕັ້ງແຕ່ Timescale DB ເປັນສິ່ງຈໍາເປັນ PostgreSQL.

ການແຂ່ງຂັນກັບລະບົບ Hadoop ແລະ MapReduce

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

ການແຂ່ງຂັນກັບ Pinot ແລະ Druid

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

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

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

Druid ແລະ Pinot ແມ່ນໂຄງການ incubator Apache, ເຊິ່ງມີຄວາມຄືບຫນ້າໃນລາຍລະອຽດໂດຍ Apache ໃນຫນ້າໂຄງການ GitHub ຂອງມັນ. Pinot ປາກົດຢູ່ໃນຫ້ອງອົບໃນເດືອນຕຸລາ 2018, ແລະ Druid ເກີດ 8 ເດືອນກ່ອນຫນ້ານີ້ - ໃນເດືອນກຸມພາ.

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

ຂໍ້ເສຍຂອງ ClickHouse

ຄວາມບໍ່ເຕັມທີ່: ແນ່ນອນ, ນີ້ຍັງເປັນເທກໂນໂລຍີທີ່ຫນ້າເບື່ອ, ແຕ່ໃນກໍລະນີໃດກໍ່ຕາມ, ບໍ່ມີຫຍັງຄ້າຍຄືນີ້ຖືກເຫັນຢູ່ໃນຖັນ DBMS ອື່ນໆ.

ແຊກຂະໜາດນ້ອຍເຮັດບໍ່ໄດ້ດີໃນຄວາມໄວສູງ: ແຜ່ນແຊກຕ້ອງຖືກແບ່ງອອກເປັນຕ່ອນໃຫຍ່ກວ່າ ເພາະວ່າການໃສ່ແຜ່ນນ້ອຍໆຈະຫຼຸດອັດຕາສ່ວນກັບຈຳນວນຖັນໃນແຕ່ລະແຖວ. ນີ້ແມ່ນວິທີທີ່ ClickHouse ເກັບຂໍ້ມູນໃນແຜ່ນ - ແຕ່ລະຄໍລໍາເປັນຕົວແທນຂອງ 1 ໄຟລ໌ຫຼືຫຼາຍກວ່ານັ້ນ, ດັ່ງນັ້ນເພື່ອໃສ່ 1 ແຖວທີ່ມີ 100 ຖັນ, ທ່ານຈໍາເປັນຕ້ອງເປີດແລະຂຽນຢ່າງຫນ້ອຍ 100 ໄຟລ໌. ນີ້ແມ່ນເຫດຜົນທີ່ buffering inserts ຕ້ອງການຄົນກາງ (ເວັ້ນເສຍແຕ່ວ່າລູກຄ້າເອງສະຫນອງ buffering) - ປົກກະຕິແລ້ວ Kafka ຫຼືບາງປະເພດຂອງລະບົບການຈັດການແຖວ. ທ່ານຍັງສາມາດໃຊ້ເຄື່ອງຈັກຕາຕະລາງ Buffer ເພື່ອຄັດລອກຂໍ້ມູນຈໍານວນຫລາຍເຂົ້າໄປໃນຕາຕະລາງ MergeTree.

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

ການຄົ້ນພົບ

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

ບາງໂຄສະນາ🙂

ຂອບໃຈສໍາລັບການຢູ່ກັບພວກເຮົາ. ເຈົ້າມັກບົດຄວາມຂອງພວກເຮົາບໍ? ຕ້ອງການເບິ່ງເນື້ອຫາທີ່ຫນ້າສົນໃຈຫຼາຍບໍ? ສະຫນັບສະຫນູນພວກເຮົາໂດຍການວາງຄໍາສັ່ງຫຼືແນະນໍາໃຫ້ຫມູ່ເພື່ອນ, cloud VPS ສໍາລັບນັກພັດທະນາຈາກ $4.99, ການປຽບທຽບທີ່ເປັນເອກະລັກຂອງເຊີບເວີລະດັບເຂົ້າ, ເຊິ່ງຖືກປະດິດໂດຍພວກເຮົາສໍາລັບທ່ານ: ຄວາມຈິງທັງໝົດກ່ຽວກັບ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ຈາກ $19 ຫຼືວິທີການແບ່ງປັນເຄື່ອງແມ່ຂ່າຍ? (ສາມາດໃຊ້ໄດ້ກັບ RAID1 ແລະ RAID10, ສູງສຸດ 24 cores ແລະສູງສຸດ 40GB DDR4).

Dell R730xd 2x ລາຄາຖືກກວ່າຢູ່ໃນສູນຂໍ້ມູນ Equinix Tier IV ໃນ Amsterdam? ທີ່ນີ້ເທົ່ານັ້ນ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ຈາກ $199 ໃນປະເທດເນເທີແລນ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ຈາກ $99! ອ່ານກ່ຽວກັບ ວິທີການສ້າງໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດ. ຫ້ອງຮຽນທີ່ມີການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍຂອງ Dell R730xd E5-2650 v4 ມູນຄ່າ 9000 ເອີໂຣສໍາລັບເງິນບໍ?

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