ClickHouse + Graphite: ວິທີການຫຼຸດຜ່ອນການບໍລິໂພກພື້ນທີ່ດິດຢ່າງຫຼວງຫຼາຍ

ຊົມເຊີຍ, habr.

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

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

ບັນຫາກັບພື້ນທີ່ບໍລິໂພກ

ຢູ່ glance ທໍາອິດ, ທຸກສິ່ງທຸກຢ່າງຄວນຈະເຮັດວຽກໄດ້ດີ. ຕິດຕາມ ເອກະສານ, ສ້າງ config ສໍາລັບຮູບແບບການເກັບຮັກສາ metrics (ເພີ່ມເຕີມ retention), ຫຼັງຈາກນັ້ນສ້າງຕາຕະລາງຕາມຄໍາແນະນໍາຂອງ backend ທີ່ເລືອກສໍາລັບ graphite-web: carbon-clickhouse+graphite-clickhouse ຫຼື graphous, ຂຶ້ນກັບວ່າ stack ໃດຖືກນໍາໃຊ້. ແລະ... ລູກລະເບີດເວລາກໍ່ດັບໄປ.

ເພື່ອເຂົ້າໃຈວ່າອັນໃດ, ທ່ານ ຈຳ ເປັນຕ້ອງຮູ້ວິທີການເຮັດວຽກແລະເສັ້ນທາງຊີວິດຕໍ່ໄປຂອງຂໍ້ມູນໃນຕາຕະລາງເຄື່ອງຈັກຂອງຄອບຄົວ *.MergeTree ClickHouse (ຕາຕະລາງເອົາມາຈາກ ບົດ ນຳ ສະ ເໜີ Alexey Zatelpin):

• ແຊກ блок ຂໍ້ມູນ. ໃນກໍລະນີຂອງພວກເຮົາ, ມັນແມ່ນຕົວຊີ້ວັດທີ່ມາຮອດ.
  
• ແຕ່ລະບລັອກດັ່ງກ່າວຖືກຈັດຮຽງຕາມລະຫັດກ່ອນທີ່ຈະຖືກຂຽນໃສ່ແຜ່ນ. ORDER BYລະບຸໃນເວລາສ້າງຕາຕະລາງ.
• ຫຼັງ​ຈາກ​ການ​ຄັດ​ເລືອກ​, кусок (part) ຂໍ້ມູນຖືກຂຽນໃສ່ແຜ່ນ.
  
• ເຊີບເວີກວດສອບໃນພື້ນຫຼັງເພື່ອບໍ່ໃຫ້ມີຊິ້ນສ່ວນດັ່ງກ່າວຫຼາຍ, ແລະເປີດພື້ນຫຼັງ слияния (merge, ຕໍ່​ໄປ​ນີ້ merge).
  
  
• ເຊີບເວີຢຸດການເຮັດວຽກການລວມຕົວຂອງມັນເອງທັນທີທີ່ຂໍ້ມູນຢຸດເຊົາການໄຫຼເຂົ້າຢ່າງຈິງຈັງ партицию (partition), ແຕ່ທ່ານສາມາດເລີ່ມຕົ້ນຂະບວນການດ້ວຍຕົນເອງດ້ວຍຄໍາສັ່ງ OPTIMIZE.
• ຖ້າ​ຫາກ​ວ່າ​ມີ​ພຽງ​ແຕ່​ຫນຶ່ງ​ສິ້ນ​ໃນ​ການ​ແບ່ງ​ປັນ​, ຫຼັງ​ຈາກ​ນັ້ນ​ທ່ານ​ຈະ​ບໍ່​ສາ​ມາດ​ດໍາ​ເນີນ​ການ merge ໂດຍ​ນໍາ​ໃຊ້​ຄໍາ​ສັ່ງ​ປົກ​ກະ​ຕິ​ໄດ້​; OPTIMIZE ... FINAL

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

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

ແລະມັນສະເຫມີສິ້ນສຸດລົງຄືກັນ. ພື້ນທີ່ທີ່ຖືກຄອບຄອງໂດຍ metrics ໃນ ClickHouse ພຽງແຕ່ເພີ່ມຂຶ້ນຖ້າ:

• ບໍ່ສະຫມັກ OPTIMIZE ... FINAL ດ້ວຍຕົນເອງຫຼື
• ຢ່າໃສ່ຂໍ້ມູນເຂົ້າໄປໃນພາທິຊັນທັງຫມົດຢ່າງຕໍ່ເນື່ອງ, ດັ່ງນັ້ນໄວຫຼືຫຼັງຈາກນັ້ນການລວມພື້ນຫລັງຈະເລີ່ມຕົ້ນ.

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

ຂໍ້ມູນໃນຕາຕະລາງລະບົບ ClickHouse

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

• ຊື່ db (database);
• ຊື່​ຕາ​ຕະ​ລາງ (table);
• ຊື່ພາທິຊັນ ແລະ ID (partition & partition_id);
• ເມື່ອສິ້ນໄດ້ຖືກສ້າງຂື້ນ (modification_time);
• ວັນ​ທີ​ຕໍາ​່​ສຸດ​ທີ່​ແລະ​ສູງ​ສຸດ​ໃນ​ສິ້ນ (ການ​ແບ່ງ​ປັນ​ແມ່ນ​ເຮັດ​ໄດ້​ໂດຍ​ມື້​) (min_date & max_date);

ນອກນັ້ນຍັງມີຕາຕະລາງ system.graphite_retentions, ມີ​ພາກ​ສະ​ຫນາມ​ທີ່​ຫນ້າ​ສົນ​ໃຈ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• ຊື່ db (Tables.database);
• ຊື່​ຕາ​ຕະ​ລາງ (Tables.table);
• metric age ໃນເວລາທີ່ການລວບລວມຕໍ່ໄປຄວນຈະຖືກນໍາໃຊ້ (age);

ດັ່ງນັ້ນ:

1. ພວກເຮົາມີຕາຕະລາງຂອງ chunks ແລະຕາຕະລາງຂອງກົດລະບຽບການລວບລວມ.
2. ພວກ​ເຮົາ​ສົມ​ທົບ​ການ​ຕັດ​ກັນ​ຂອງ​ເຂົາ​ເຈົ້າ​ແລະ​ໄດ້​ຮັບ​ຕາ​ຕະ​ລາງ​ທັງ​ຫມົດ *GraphiteMergeTree​.
3. ພວກ​ເຮົາ​ກໍາ​ລັງ​ຊອກ​ຫາ​ການ​ແບ່ງ​ປັນ​ທັງ​ຫມົດ​ທີ່​:
   • ຫຼາຍກວ່າຫນຶ່ງຊິ້ນ
   • ຫຼືເຖິງເວລາທີ່ຈະນໍາໃຊ້ກົດລະບຽບການລວບລວມຕໍ່ໄປ, ແລະ modification_time ແກ່ກວ່າເວລານີ້.

Реализация

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

SELECT
    concat(p.database, '.', p.table) AS table,
    p.partition_id AS partition_id,
    p.partition AS partition,
    -- Самое "старое" правило, которое может быть применено для
    -- партиции, но не в будущем, см (*)
    max(g.age) AS age,
    -- Количество кусков в партиции
    countDistinct(p.name) AS parts,
    -- За самую старшую метрику в партиции принимается 00:00:00 следующего дня
    toDateTime(max(p.max_date + 1)) AS max_time,
    -- Когда партиция должна быть оптимизированна
    max_time + age AS rollup_time,
    -- Когда самый старый кусок в партиции был обновлён
    min(p.modification_time) AS modified_at
FROM system.parts AS p
INNER JOIN
(
    -- Все правила для всех таблиц *GraphiteMergeTree
    SELECT
        Tables.database AS database,
        Tables.table AS table,
        age
    FROM system.graphite_retentions
    ARRAY JOIN Tables
    GROUP BY
        database,
        table,
        age
) AS g ON
    (p.table = g.table)
    AND (p.database = g.database)
WHERE
    -- Только активные куски
    p.active
    -- (*) И только строки, где правила аггрегации уже должны быть применены
    AND ((toDateTime(p.max_date + 1) + g.age) < now())
GROUP BY
    table,
    partition
HAVING
    -- Только партиции, которые младше момента оптимизации
    (modified_at < rollup_time)
    -- Или с несколькими кусками
    OR (parts > 1)
ORDER BY
    table ASC,
    partition ASC,
    age ASC

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

ນີ້ແມ່ນສິ່ງທີ່ໂຄງການເຮັດ graphite-ch-optimizer. ອະດີດເພື່ອນຮ່ວມງານຈາກ Yandex.Market ໄດ້ພະຍາຍາມມັນໃນການຜະລິດ, ຜົນໄດ້ຮັບຂອງການເຮັດວຽກສາມາດເຫັນໄດ້ຂ້າງລຸ່ມນີ້.

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

ແຜນການທັນທີຂອງພວກເຮົາແມ່ນເພື່ອສະຫນອງຢ່າງຫນ້ອຍ deb packages, ແລະຖ້າເປັນໄປໄດ້ຍັງ rpm.

ແທນທີ່ຈະເປັນການສະຫລຸບໄດ້

ໃນໄລຍະ 9+ ເດືອນທີ່ຜ່ານມາຂ້ອຍໄດ້ຢູ່ໃນບໍລິສັດຂອງຂ້ອຍ innogames ໄດ້ໃຊ້ເວລາຫຼາຍ tinkering ຢູ່ຈຸດຕັດກັນຂອງ ClickHouse ແລະ graphite-web. ມັນເປັນປະສົບການທີ່ດີ, ເຊິ່ງເຮັດໃຫ້ການຫັນປ່ຽນຢ່າງໄວວາຈາກສຽງກະຊິບໄປຫາ ClickHouse ເປັນການເກັບຮັກສາ metrics. ຂ້າພະເຈົ້າຫວັງວ່າບົດຄວາມນີ້ແມ່ນບາງສິ່ງບາງຢ່າງຂອງການເລີ່ມຕົ້ນຂອງຊຸດກ່ຽວກັບການປັບປຸງສິ່ງທີ່ພວກເຮົາໄດ້ເຮັດກັບພາກສ່ວນຕ່າງໆຂອງ stack ນີ້, ແລະສິ່ງທີ່ຈະເຮັດໃນອະນາຄົດ.

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

ຫນ້າໂຄງການໃນ github

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