ພວກເຮົາກຳລັງພັດທະນາການໂຕ້ຕອບທີ່ສະດວກທີ່ສຸດໃນໂລກ* ສຳລັບການເບິ່ງບັນທຶກ

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

* ອີງຕາມຄວາມຄິດເຫັນສ່ວນຕົວຂອງຜູ້ໃຊ້ habra ເຈົ້າROCK

ພົບກັບ logscli

ຂ້ອຍບໍ່ໄດ້ມາກັບຊື່ສໍາລັບການໂຕ້ຕອບຂອງຂ້ອຍ, ແລະ, ດ້ວຍຄວາມຊື່ສັດ, ມັນມີຢູ່ໃນຮູບແບບຂອງຕົ້ນແບບ, ແຕ່ຖ້າທ່ານຕ້ອງການເບິ່ງລະຫັດແຫຼ່ງທັນທີ, ທ່ານຍິນດີຕ້ອນຮັບ: https://github.com/YuriyNasretdinov/logscli (350 ແຖວຂອງລະຫັດ Go ທີ່ເລືອກ).

ຄຸນນະສົມບັດ

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

1. ເບິ່ງບັນທຶກທັງໝົດ, ໂດຍບໍ່ມີການກັ່ນຕອງ.
2. ປ່ອຍໃຫ້ແຖວທີ່ມີສາຍຍ່ອຍຄົງທີ່ (ທຸງ -F у grep).
3. ອອກຈາກເສັ້ນທີ່ກົງກັບການສະແດງຜົນປົກກະຕິ (ທຸງ -E у grep).
4. ໂດຍຄ່າເລີ່ມຕົ້ນ, ການເບິ່ງຢູ່ໃນລໍາດັບເຫດການແບບປີ້ນກັບກັນ, ເພາະວ່າບັນທຶກທີ່ຜ່ານມາຫຼາຍທີ່ສຸດມັກຈະມີຄວາມສົນໃຈກ່ອນ.
5. ສະແດງບໍລິບົດຖັດຈາກແຕ່ລະແຖວ (ຕົວເລືອກ -A, -B и -C у grep, ການພິມ N ເສັ້ນກ່ອນ, ຫຼັງຈາກ, ແລະປະມານແຕ່ລະເສັ້ນທີ່ກົງກັນ, ຕາມລໍາດັບ).
6. ເບິ່ງບັນທຶກທີ່ເຂົ້າມາໃນເວລາຈິງ, ມີຫຼືບໍ່ມີການກັ່ນຕອງ (ໂດຍຈໍາເປັນ tail -f | grep).
7. ການໂຕ້ຕອບຕ້ອງເຂົ້າກັນໄດ້ກັບ less, head, tail ແລະອື່ນໆ - ໂດຍຄ່າເລີ່ມຕົ້ນ, ຜົນໄດ້ຮັບຄວນຈະຖືກສົ່ງຄືນໂດຍບໍ່ມີຂໍ້ຈໍາກັດກ່ຽວກັບຈໍານວນຂອງພວກເຂົາ; ສາຍຖືກພິມອອກເປັນສາຍນ້ໍາຕາບໃດທີ່ຜູ້ໃຊ້ມີຄວາມສົນໃຈທີ່ຈະໄດ້ຮັບພວກມັນ; ສັນຍານ SIGPIPE ຄວນຂັດຂວາງການຖ່າຍທອດບັນທຶກຢ່າງງຽບໆ, ຄືກັນກັບພວກເຂົາ tail, grep ແລະອຸປະກອນອື່ນໆຂອງ UNIX.

Реализация

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

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

ນັ້ນແມ່ນ, ພວກເຮົາຕ້ອງການປະມານໂຄງການຕາຕະລາງຕໍ່ໄປນີ້:

CREATE TABLE logs(
    category LowCardinality(String), -- категория логов (опционально)
    time DateTime, -- время события
    millis UInt16, -- миллисекунды (могут быть и микросекунды, и т.д.): рекомендуется хранить, если событий много, чтобы было легче различать события между собой
    ..., -- ваши собственные поля, например имя сервера, уровень логирования, и так далее
    message String -- текст сообщения
) ENGINE=MergeTree()
ORDER BY (category, time, millis)

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

ຄໍາແນະນໍາສໍາລັບການອັບໂຫລດການທົບທວນຄືນ Amazon ກັບ ClickHouse

ມາສ້າງຕາຕະລາງ:

CREATE TABLE amazon(
   review_date Date,
   time DateTime DEFAULT toDateTime(toUInt32(review_date) * 86400 + rand() % 86400),
   millis UInt16 DEFAULT rand() % 1000,
   marketplace LowCardinality(String),
   customer_id Int64,
   review_id String,
   product_id LowCardinality(String),
   product_parent Int64,
   product_title String,
   product_category LowCardinality(String),
   star_rating UInt8,
   helpful_votes UInt32,
   total_votes UInt32,
   vine FixedString(1),
   verified_purchase FixedString(1),
   review_headline String,
   review_body String
)
ENGINE=MergeTree()
ORDER BY (time, millis)
SETTINGS index_granularity=8192

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

ທ່ານບໍ່ຈໍາເປັນຕ້ອງດາວໂຫລດໄຟລ໌ tsv ທັງຫມົດແລະຈໍາກັດຕົວທ່ານເອງຢູ່ທີ່ ~ 10-20 ທໍາອິດເພື່ອໃຫ້ໄດ້ຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່ພໍສົມຄວນທີ່ຈະບໍ່ເຫມາະສົມກັບ 16 GB ຂອງ RAM. ເພື່ອອັບໂຫລດໄຟລ໌ TSV ຂ້ອຍໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

for i in *.tsv; do
    echo $i;
    tail -n +2 $i | pv |
    clickhouse-client --input_format_allow_errors_ratio 0.5 --query='INSERT INTO amazon(marketplace,customer_id,review_id,product_id,product_parent,product_title,product_category,star_rating,helpful_votes,total_votes,vine,verified_purchase,review_headline,review_body,review_date) FORMAT TabSeparated'
done

ໃນ Disk Persistent ມາດຕະຖານ (ເຊິ່ງເປັນ HDD) ໃນ Google Cloud ທີ່ມີຂະຫນາດ 1000 GB (ຂ້ອຍເອົາຂະຫນາດນີ້ສ່ວນໃຫຍ່ເພື່ອໃຫ້ຄວາມໄວສູງກວ່າເລັກນ້ອຍ, ເຖິງແມ່ນວ່າບາງທີ SSD ຂອງຂະຫນາດທີ່ຕ້ອງການຈະມີລາຄາຖືກກວ່າ) ການອັບໂຫລດ ຄວາມໄວແມ່ນປະມານ ~ 75 MB / ວິນາທີໃນ 4 ແກນ.

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

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

ສະແດງຄວາມຄືບໜ້າການສະແກນຂໍ້ມູນ

ເນື່ອງຈາກວ່າໃນ ClickHouse ພວກເຮົາຈະໃຊ້ການສະແກນເຕັມຢູ່ໃນຕາຕະລາງທີ່ມີບັນທຶກ, ແລະການດໍາເນີນງານນີ້ສາມາດໃຊ້ເວລາຢ່າງຫຼວງຫຼາຍແລະອາດຈະບໍ່ມີຜົນໃດໆສໍາລັບເວລາດົນນານຖ້າພົບສອງສາມຄໍາ, ແນະນໍາໃຫ້ສາມາດສະແດງຜົນໄດ້. ຄວາມຄືບຫນ້າຂອງການສອບຖາມຈົນກ່ວາແຖວທໍາອິດທີ່ມີຜົນໄດ້ຮັບແມ່ນໄດ້ຮັບ. ເພື່ອເຮັດສິ່ງນີ້, ມີຕົວກໍານົດການໃນການໂຕ້ຕອບ HTTP ທີ່ອະນຸຍາດໃຫ້ທ່ານສົ່ງຄວາມຄືບຫນ້າໃນສ່ວນຫົວ HTTP: send_progress_in_http_headers=1. ແຕ່ຫນ້າເສຍດາຍ, ຫ້ອງສະຫມຸດ Go ມາດຕະຖານບໍ່ສາມາດອ່ານ headers ຍ້ອນວ່າພວກເຂົາໄດ້ຮັບ, ແຕ່ HTTP 1.0 interface (ບໍ່ຄວນສັບສົນກັບ 1.1!) ສະຫນັບສະຫນູນໂດຍ ClickHouse, ດັ່ງນັ້ນທ່ານສາມາດເປີດການເຊື່ອມຕໍ່ TCP ດິບກັບ ClickHouse ແລະສົ່ງໄປທີ່ນັ້ນ. GET /?query=... HTTP/1.0nn ແລະໄດ້ຮັບສ່ວນຫົວການຕອບສະ ໜອງ ແລະຮ່າງກາຍໂດຍບໍ່ມີການຫລົບຫນີຫຼືການເຂົ້າລະຫັດ, ດັ່ງນັ້ນໃນກໍລະນີນີ້ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງໃຊ້ຫ້ອງສະຫມຸດມາດຕະຖານ.

ບັນທຶກການຖ່າຍທອດຈາກ ClickHouse

ClickHouse ມີການເພີ່ມປະສິດທິພາບສໍາລັບການສອບຖາມກັບ ORDER BY ສໍາລັບເວລາດົນນານ (ນັບຕັ້ງແຕ່ 2019?), ດັ່ງນັ້ນການສອບຖາມເຊັ່ນ:

SELECT time, millis, message
FROM logs
WHERE message LIKE '%something%'
ORDER BY time DESC, millis DESC

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

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

ການຈັດການ SIGPIPE ທີ່ຖືກຕ້ອງໃນ Go

ໃນເວລາທີ່ທ່ານປະຕິບັດ, ເວົ້າວ່າ, ຄໍາສັ່ງ some_cmd | head -n 10, ແທ້ວິທີການຄໍາສັ່ງ some_cmd ຢຸດການປະຕິບັດເມື່ອ head ລົບ 10 ແຖວ? ຄໍາຕອບແມ່ນງ່າຍດາຍ: ເມື່ອ head ສິ້ນສຸດ, ທໍ່ປິດ, ແລະ stdout ຂອງຄໍາສັ່ງ some_cmd ເລີ່ມຕົ້ນທີ່ຈະຊີ້, ຕາມເງື່ອນໄຂ, "ໄປໃສ". ເມື່ອ​ໃດ​ some_cmd ພະຍາຍາມຂຽນໃສ່ທໍ່ປິດ, ມັນ​ໄດ້​ຮັບ​ສັນ​ຍານ SIGPIPE​, ເຊິ່ງ silently terminates ໂຄງ​ການ​ໂດຍ​ການ​ເລີ່ມ​ຕົ້ນ​.

ໃນ Go ນີ້ຍັງເກີດຂື້ນໂດຍຄ່າເລີ່ມຕົ້ນ, ແຕ່ຕົວຈັດການສັນຍານ SIGPIPE ຍັງພິມ "ສັນຍານ: SIGPIPE" ຫຼືຂໍ້ຄວາມທີ່ຄ້າຍຄືກັນໃນຕອນທ້າຍຂອງຂໍ້ຄວາມນີ້, ພວກເຮົາພຽງແຕ່ຕ້ອງການຈັດການ SIGPIPE ຕົວເອງໃນແບບທີ່ພວກເຮົາຕ້ອງການ, ນັ້ນແມ່ນ, ພຽງແຕ່ງຽບໆ. ອອກ:

ch := make(chan os.Signal)
signal.Notify(ch, syscall.SIGPIPE)
go func() {
    <-ch
    os.Exit(0)
}()

ສະແດງບໍລິບົດຂອງຂໍ້ຄວາມ

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

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

SELECT time,millis,review_body FROM amazon
WHERE (time = 'ВРЕМЯ_СОБЫТИЯ' AND millis < МИЛЛИСЕКУНДЫ_СОБЫТИЯ) OR (time < 'ВРЕМЯ_СОБЫТИЯ')
ORDER BY time DESC, millis DESC
LIMIT КОЛИЧЕСТВО_СТРОК_КОНТЕКСТА
SETTINGS max_threads=1

ເນື່ອງຈາກຄໍາຮ້ອງຂໍຖືກສົ່ງເກືອບທັນທີຫຼັງຈາກທີ່ ClickHouse ສົ່ງຄືນສາຍທີ່ສອດຄ້ອງກັນ, ມັນສິ້ນສຸດລົງໃນ cache ແລະໂດຍທົ່ວໄປແລ້ວຄໍາຮ້ອງຂໍຖືກປະຕິບັດຢ່າງໄວວາແລະໃຊ້ CPU ເລັກນ້ອຍ (ປົກກະຕິແລ້ວຄໍາຮ້ອງຂໍໃຊ້ເວລາປະມານ ~ 6 ms ໃນເຄື່ອງ virtual ຂອງຂ້ອຍ).

ສະແດງຂໍ້ຄວາມໃໝ່ໃນເວລາຈິງ

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

ຕົວຢ່າງຄໍາສັ່ງ

ຄໍາສັ່ງ logscli ປົກກະຕິມີລັກສະນະແນວໃດໃນການປະຕິບັດ?

ຖ້າທ່ານດາວໂຫລດຊຸດຂໍ້ມູນ Amazon ທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວເຖິງໃນຕອນຕົ້ນຂອງບົດຄວາມ, ທ່ານສາມາດດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້:

# Показать строки, где встречается слово walmart
$ logscli -F 'walmart' | less

# Показать самые свежие 10 строк, где встречается "terrible"
$ logscli -F terrible -limit 10

# То же самое без -limit:
$ logscli -F terrible | head -n 10

# Показать все строки, подходящие под /times [0-9]/, написанные для vine и у которых высокий рейтинг
$ logscli -E 'times [0-9]' -where="vine='Y' AND star_rating>4" | less

# Показать все строки со словом "panic" и 3 строки контекста вокруг
$ logscli -F 'panic' -C 3 | less

# Непрерывно показывать новые строки со словом "5-star"
$ logscli -F '5-star' -tailf

ເອກະສານ

ລະຫັດຜົນປະໂຫຍດ (ໂດຍບໍ່ມີເອກະສານ) ແມ່ນມີຢູ່ໃນ github ທີ່ https://github.com/YuriyNasretdinov/logscli. ຂ້ອຍຈະດີໃຈທີ່ຈະໄດ້ຍິນຄວາມຄິດຂອງເຈົ້າກ່ຽວກັບຄວາມຄິດຂອງຂ້ອຍສໍາລັບການໂຕ້ຕອບ console ສໍາລັບການເບິ່ງບັນທຶກໂດຍອີງໃສ່ ClickHouse.

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