ClickHouse + Graphite: кантип диск мейкиндигин керектөөнү олуттуу кыскартуу керек

Салам, хабр.

Эгер кимдир бирөө системаны пайдаланса графит желе жана сактагычтын иштеши көйгөйүнө туш болду шыбыроо (IO, диск мейкиндиги сарпталат), андан кийин ClickHouse-ну алмаштыруу мүмкүнчүлүгү бир болушу керек. Бул билдирүү үчүнчү тараптын ишке ашыруусу мурунтан эле демонду кабыл алуучу метрика катары колдонулганын билдирет, мисалы carbonwriter же көмүртек.

ClickHouse сүрөттөлгөн көйгөйлөрдү жакшы чечет. Мисалы, 2TiB маалыматтарды шыбыраштан өткөрүп бергенден кийин, алар 300GiBга туура келет. Мен майда-чүйдөсүнө чейин салыштырууга токтолбойм, бул тема боюнча макалалар көп. Мындан тышкары, жакынкы убакка чейин биздин ClickHouse сактагычыбызда баары идеалдуу болгон эмес.

керектелүүчү мейкиндик менен көйгөйлөр

Бир караганда, баары жакшы иштеши керек. Кийинки документтер, метрикаларды сактоо схемасы үчүн конфигурацияны түзүңүз (мындан ары retention), андан кийин graphite-web үчүн тандалган сервердин сунушуна ылайык таблицаны түзүңүз: carbon-clickhouse+graphite-clickhouse же графа, кайсы стек колдонулганына жараша. Жана... саат бомбасы жанды.

Кайсынысын түшүнүү үчүн, сиз * үй-бүлөсүнүн кыймылдаткычтарынын таблицаларындагы кошумчалар кантип иштээрин жана маалыматтардын мындан аркы жашоо жолун билишиңиз керек.MergeTree ClickHouse (диаграммалар тапшырмалары Алексей Зателепин):

• киргизилген блок маалыматтар. Биздин учурда, бул келген метрикалар болгон.
  
• Ар бир мындай блок дискке жазылганга чейин ачкычка жараша сорттолот. ORDER BYтаблицаны түзүүдө көрсөтүлгөн.
• сорттоо кийин, кусок (part) маалыматтар дискке жазылат.
  
• Сервер фондо көзөмөлдөйт, мындай бөлүктөр көп болбошу үчүн жана фонду ишке киргизет слияния (merge, мындан ары бириктирүү).
  
  
• Берилиштер жигердүү агып кирбей калганда сервер өз алдынча бириктирүүнү токтотот партицию (partition), бирок сиз буйрук менен процессти кол менен баштасаңыз болот OPTIMIZE.
• Бөлүмдө бир гана бөлүк калса, анда сиз биригүүнү кадимки буйрукту иштете албайсыз; колдонушуңуз керек OPTIMIZE ... FINAL

Ошентип, биринчи көрсөткүчтөр келет. Жана алар бир аз орун ээлейт. Кийинки окуялар көптөгөн факторлорго жараша бир аз өзгөрүшү мүмкүн:

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

Ал ар дайым бир эле бүтөт. ClickHouse ичиндеги көрсөткүчтөр ээлеген мейкиндик төмөнкү учурларда гана көбөйөт:

• кайрылбаңыз OPTIMIZE ... FINAL кол менен же
• бардык бөлүмдөргө маалыматтарды дайыма киргизбеңиз, андыктан эртеби-кечпи фондо бириктирүү башталат

Экинчи ыкманы ишке ашыруу эң оңой окшойт, демек, ал туура эмес жана биринчи жолу аракет кылынган.
Мен акыркы 4 жыл ичинде ар бир күн үчүн жасалма метрика жөнөткөн жана ар бир саат сайын cron иштеткен абдан жөнөкөй питон сценарийин жаздым.
ClickHouse DBMSтин бүтүндөй иштеши бул система эртеби-кечпи бардык фонддук иштерди аткара турганына негизделген, бирок качан белгисиз, мен эски чоң бөлүкчөлөр биригип баштоону каалаган учурду күтө албадым. жаңы кичинекейлер. Мажбурлап оптималдаштырууну автоматташтыруунун жолун издөө керек экени айкын болду.

ClickHouse тутумдук таблицаларындагы маалымат

Келгиле, столдун түзүлүшүн карап көрөлү система.бөлүктөрү. Бул ClickHouse сервериндеги бардык таблицалардын ар бир бөлүгү жөнүндө толук маалымат. Башка нерселер менен катар төмөнкү тилкелерди камтыйт:

• db аты (database);
• столдун аталышы (table);
• бөлүмдүн аты жана ID (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 менен серверде иштетсеңиз, ал жөн гана демон режиминде иштей баштайт. Саатына бир жолу өтүнүч аткарылып, оптималдаштырыла турган үч күндөн ашкан жаңы бөлүмдөрдүн пайда болгонун текшерет.

Биздин жакынкы пландарыбыз жок дегенде деб пакеттерин жана мүмкүн болсо rpm менен камсыз кылуу.

Ордуна корутундусу

Акыркы 9+ айдын ичинде мен өзүмдүн компаниямдын ичинде болдум innogames ClickHouse жана graphite-web кесилишинде көп убакыт өткөрдү. Бул жакшы тажрыйба болду, натыйжада шыбырдан метрика сактагычы катары ClickHouseга тез өтүү болду. Бул макала биз бул стектин ар кандай бөлүктөрүн кандай жакшыртууларды жасагандыгыбыз жана келечекте эмнелер жасала тургандыгы тууралуу сериянын башталышы деп үмүттөнөм.

менен бирге, бир нече литр сыра жана админ күн өтүнүчтү иштеп чыгуу үчүн жумшалган v0devil, бул үчүн мен ага ыраазычылыгымды билдиргим келет. Жана ошондой эле бул макаланы карап чыгуу үчүн.

github боюнча долбоордун бети

Source: www.habr.com