ClickHouse + Graphite: дискілік кеңістікті тұтынуды қалай айтарлықтай азайтуға болады

Сәлем, хабр.

Егер біреу жүйені пайдаланса графит-тор және сақтау өнімділігі мәселесіне тап болды пышақ (IO, диск кеңістігі тұтынылады), содан кейін ClickHouse-ның ауыстыру ретінде шығарылу мүмкіндігі біреуге бейім болуы керек. Бұл мәлімдеме үшінші тараптың іске асырылуы метрикаларды қабылдайтын демон ретінде бұрыннан қолданылғанын білдіреді, мысалы көміртекші немесе көміртек.

ClickHouse сипатталған мәселелерді жақсы шешеді. Мысалы, сыбырлаудан 2ТиБ деректерді тасымалдағаннан кейін олар 300ГиБ-қа сәйкес келеді. Мен салыстыруға егжей-тегжейлі тоқталмаймын, бұл тақырып бойынша көптеген мақалалар бар. Бұған қоса, соңғы уақытқа дейін біздің ClickHouse қоймасында бәрі тамаша болған жоқ.

Тұтынылатын кеңістікке қатысты мәселелер

Бір қарағанда, бәрі жақсы жұмыс істеуі керек. Бақылау құжаттама, метриканы сақтау схемасы үшін конфигурация жасаңыз (бұдан әрі retention), содан кейін graphite-web үшін таңдалған сервердің ұсынысына сәйкес кесте жасаңыз: көміртек үйі+графит-кликхаус немесе графство, қай стек пайдаланылатынына байланысты. Ал... сағаттық бомба жарылады.

Қайсысын түсіну үшін кірістірулер қалай жұмыс істейтінін және * отбасы қозғалтқыштарының кестелеріндегі деректердің одан әрі өмір сүру жолын білу керек.MergeTree ClickHouse (диаграммалар презентациялар Алексей Зателепин):

• Енгізілді блок деректер. Біздің жағдайда бұл метрикалар келді.
  
• Әрбір мұндай блок дискіге жазылмас бұрын кілтке сәйкес сұрыпталады. ORDER BYкестені құру кезінде көрсетіледі.
• Сұрыптаудан кейін, кусок (part) деректер дискіге жазылады.
  
• Сервер фондық режимде мұндай бөліктер көп болмайтындай бақылайды және фондық режимді іске қосады слияния (merge, бұдан әрі біріктіру).
  
  
• Деректер файлға белсенді түрде түсуін тоқтатқан кезде сервер біріктірулерді іске қосуды тоқтатады партицию (partition), бірақ процесті пәрмен арқылы қолмен бастауға болады OPTIMIZE.
• Бөлімде бір ғана бөлік қалса, біріктіруді әдеттегі пәрменді пайдаланып іске қоса алмайсыз, оны пайдалану керек. OPTIMIZE ... FINAL

Сонымен, алғашқы көрсеткіштер келеді. Және олар біраз орын алады. Кейінгі оқиғалар көптеген факторларға байланысты біршама өзгеруі мүмкін:

• Бөлу кілті өте кішкентай (күн) немесе өте үлкен (бірнеше ай) болуы мүмкін.
• Сақтау конфигурациясы белсенді бөлімдегі (метрикалар жазылған) бірнеше маңызды деректерді біріктіру шектеріне сәйкес келуі мүмкін немесе болмауы мүмкін.
• Егер деректер көп болса, фондық біріктіру салдарынан әлдеқашан үлкен болуы мүмкін (егер сіз оңтайлы емес бөлу кілтін таңдасаңыз) ең алғашқы бөліктер жаңа шағын бөліктермен біріктірілмейді.

Және ол әрқашан бірдей аяқталады. ClickHouse ішіндегі көрсеткіштердің орны тек келесі жағдайларда ғана артады:

• қолданбаңыз OPTIMIZE ... FINAL қолмен немесе
• ерте ме, кеш пе фондық біріктіру басталады деп барлық бөлімдерге деректерді тұрақты түрде кірістірмеңіз

Екінші әдісті іске асыру ең оңай болып көрінеді, сондықтан ол дұрыс емес және бірінші рет қолданылған.
Мен өте қарапайым питон сценарийін жаздым, ол соңғы 4 жыл бойы күн сайын жалған метрика жіберіп, сағат сайын cron іске қосылды.
ClickHouse ДҚБЖ-ның бүкіл жұмысы бұл жүйе ерте ме, кеш пе барлық фондық жұмысты орындайтынына негізделгендіктен, бірақ қашан екені белгісіз, мен ескі үлкен бөліктердің бірігуге дайын болған сәтін күте алмадым. жаңа кішкентайлар. Біз мәжбүрлі оңтайландыруларды автоматтандырудың жолын іздеуіміз керек екені белгілі болды.

ClickHouse жүйелік кестелеріндегі ақпарат

Кесте құрылымын қарастырайық жүйе.бөліктер. Бұл ClickHouse серверіндегі барлық кестелердің әрбір бөлігі туралы толық ақпарат. Басқа нәрселермен қатар келесі бағандарды қамтиды:

• db атауы (database);
• кесте атауы (table);
• бөлім атауы және идентификаторы (partition & partition_id);
• шығарма жасалған кезде (modification_time);
• бөліктегі ең аз және максималды күн (бөлу күні бойынша орындалады) (min_date & max_date);

Үстел де бар system.graphite_retentions, келесі қызықты өрістермен:

• db атауы (Tables.database);
• кесте атауы (Tables.table);
• келесі жинақтауды қолдану керек метрикалық жас (age);

Мәселен:

1. Бізде бөліктер кестесі және біріктіру ережелерінің кестесі бар.
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. Соңғы іске асыру сонымен қатар белсенді жазбасы бар бөлімдерге қол тигізудің қажеті жоқ екенін ескереді.

Бұл жоба дәл осылай жасайды графит-х-оптимизатор. Яндекс.Маркеттегі бұрынғы әріптестер оны өндірісте сынап көрді, жұмыстың нәтижесін төменде көруге болады.

Бағдарламаны ClickHouse серверінде іске қоссаңыз, ол жай ғана демон режимінде жұмыс істей бастайды. Сағатына бір рет оңтайландыруға болатын үш күннен асқан жаңа бөлімдердің пайда болуын тексеретін сұрау орындалады.

Біздің жақын арада жоспарларымыз - кем дегенде deb пакеттерін және мүмкін болса, айналым жылдамдығын қамтамасыз ету.

Орнына жасасу

Соңғы 9+ айда мен өз компаниямның ішінде болдым инно ойындар ClickHouse және graphite-web қиылысында көп уақыт жұмсады. Бұл жақсы тәжірибе болды, соның нәтижесінде метрика қоймасы ретінде сыбырлаудан ClickHouse-қа жылдам ауысу болды. Бұл мақала осы стектің әртүрлі бөліктеріне қандай жақсартулар жасағанымыз және болашақта не істейтіні туралы серияның басы деп үміттенемін.

Бірнеше литр сыра және әкімші күндері сұранысты әзірлеуге жұмсалды v0devil, бұл үшін мен оған алғысымды білдіргім келеді. Сондай-ақ осы мақаланы қарау үшін.

Github сайтындағы жоба беті

Ақпарат көзі: www.habr.com