ProHoster > Blog > Administrim > ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe

ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe

ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe

Përshëndetje, habr.

Nëse dikush shfrytëzon sistemin graphite-web dhe ka hasur në probleme me performancën e depozitës whisper (IO, hapësira e përdorur në disk), atëherë probabiliteti që të jetë hedhur një sy në ClickHouse si zëvendësim duhet të jetë afër njësi. Ky pohim nënkupton se si demon metrikash përdoret tashmë një implementim i palës së tretë, për shembull carbonwriter ose go-carbon.

ClickHouse mirë zgjidh problemet e përmendura. Për shembull, pas transferimit të 2TiB të të dhënave nga whisper, ato u përshtatën në 300GiB. Nuk do të ndalem tek krahasimi në detaje, ka mjaft artikuj mbi këtë temë. Gjithashtu, deri kohët e fundit, me depozitën tonë ClickHouse nuk ishte gjithçka perfekte.

Problemet me hapësirën e përdorur

Në shikim të parë, gjithçka duhet të funksionojë mirë. Duke ndjekur dokumentacionin, krijojmë një konfigurim për skemën e ruajtjes së metrike (më pas retention), pastaj krijojmë një tabelë sipas rekomandimeve të backend-it të zgjedhur për graphite-web: carbon-clickhouse+graphite-clickhouse ose graphouse, varësisht nga staku që përdoret. Dhe... aktivizohet një bombë me vonesë.

Për të kuptuar se cila, duhet të dimë si funksionojnë inserimet dhe rruga e mëtejshme e jetës së të dhënave në tabelat e motorëve të familjes *MergeTree ClickHouse (diagramet janë marrë nga prezentimi Aleksandr Zatelepina):

  • Injetohet njĂ« bllok tĂ« dhĂ«nash. NĂ« rastin tonĂ«, kĂ«to janĂ« metrikat qĂ« kanĂ« mb arrive.
    ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe
  • Çdo bllok i tillĂ« para se tĂ« shkruhet nĂ« disk renditet sipas çelĂ«sit ORDER BY, i specifikuar kur krijohet tabela.
  • Pasi tĂ« renditet, njĂ« copĂ« (part) tĂ« dhĂ«nash shkruhet nĂ« disk.
    ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe
  • Serveri monitoron nĂ« sfond qĂ« tĂ« mos ketĂ« shumĂ« copĂ«za tĂ« tilla, dhe aktivizon proceset e shkrirjes (merge, mĂ« vonĂ« quhen mĂ«rgĂ«.)
    ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe
    ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe
  • Serveri ndalon tĂ« aktivizojĂ« mĂ«rgĂ« automatikisht sa herĂ« qĂ« tĂ« dhĂ«nat ndalojnĂ« sĂ« ardhuri aktivisht nĂ« particion (partition), por mund tĂ« aktivizoni procesin manualisht me komandĂ«n OPTIMIZE.
  • NĂ«se nĂ« particion ka mbetur vetĂ«m njĂ« copĂ«, atĂ«herĂ« nuk do tĂ« jetĂ« e mundur tĂ« aktivizohet njĂ« mĂ«rgĂ« me komandĂ«n e zakonshme, nevojitet tĂ« pĂ«rdoret OPTIMIZE ... FINAL

Pra, metrikat e para mbërrijnë. Dhe ato shfrytëzojnë ndonjë hapësirë. Eventet e ardhshme mund të variojnë pak në varësi të shumë faktorëve:

  • ÇelĂ«si i partitizimit mund tĂ« jetĂ« shumĂ« i vogĂ«l (njĂ« ditĂ«), si dhe shumĂ« i madh (pĂ«r disa muaj).
  • Konfigurimi i retention mund tĂ« pĂ«rmbajĂ« disa pragje tĂ« rĂ«ndĂ«sishme tĂ« agregimit tĂ« tĂ« dhĂ«nave brenda njĂ« partie aktive (ku shkruhen metrikat), ose ndoshta jo.
  • NĂ«se tĂ« dhĂ«nat janĂ« shumĂ« tĂ« shumta, copat mĂ« tĂ« vjetra, tĂ« cilat pĂ«r shkak tĂ« mergimeve pasive mund tĂ« jenĂ« tashmĂ« shumĂ« tĂ« mĂ«dha (kur zgjidhet njĂ« çelĂ«s jo optimal pĂ«r ndarjen), nuk do tĂ« bashkohen vetĂ« me copat e reja tĂ« vogla.

Dhe gjithmonë përfundon gjithçka në të njëjtën mënyrë. Hapsira e zënë nga metrikat në ClickHouse vetëm rritet, nëse:

  • nuk aplikohet OPTIMIZE ... FINAL duke ndihmuar manualisht ose
  • nuk futen tĂ« dhĂ«na nĂ« tĂ« gjitha partitĂ« nĂ« njĂ« bazĂ« tĂ« qĂ«ndrueshme, nĂ« mĂ«nyrĂ« qĂ« vonĂ« ose mĂ« vonĂ« tĂ« fillohet njĂ« mergim pasiv.

Mënyra e dytë duket si më e thjeshta për t'u zbatuar dhe, pra, është e gabuar dhe u provua e para.
Shkrova një skenar mjaft të thjeshtë në python, i cili dërgonte metrika fiktive për çdo ditë për katër vitet e fundit dhe ekzekutohej çdo orë nga cron.
Duke qenë se gjithë puna e sistemit ClickHouse DBMS është e ndërtuar mbi faktin se ky sistem do të bëjë gjithë punën e pasme përfundimisht, por nuk dihet kur, nuk e kam arritur dot të pres momentin kur copat e vjetra të mëdha do të kishin filluar të bashkoheshin me copat e reja të vogla. U bë e qartë se duhet të kërkoja mënyra për të automatizuar optimizimet përkatëse.

ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe

Informacioni në tabelat sistemore të ClickHouse

Le të shohim strukturën e tabelës system.parts. Ky është informacioni gjithëpërfshirës për çdo copë të të gjitha tabelave në serverin ClickHouse. Përmban, përfshirë, kolonat e mëposhtme:

  • emri i DB (database);
  • emri i tabelĂ«s (table);
  • emri dhe ID e partisĂ« (partition & partition_id);
  • kur u krijua copĂ«za (modification_time);
  • data minimale dhe maksimale nĂ« copĂ« (ndarja bĂ«het sipas ditĂ«ve) (min_date & max_date);

Gjithashtu ka një tabelë system.graphite_retentions, me fushat e mëposhtme të interesit:

  • emri i DB (Tables.database);
  • emri i tabelĂ«s (Tables.table);
  • mosha e metrikĂ«s, kur duhet tĂ« aplikohet agregimi i ardhshĂ«m (age);

Pra:

  1. Kemi një tabelë copash dhe një tabelë rregullash agregimi.
  2. Bashkojmë ndërprerjen e tyre dhe marrim të gjitha tabelat *GraphiteMergeTree.
  3. Kërkojmë të gjitha partitë, ku:
    • mĂ« shumĂ« se njĂ« copĂ«
    • ose ka ardhur momenti pĂ«r tĂ« aplikuar rregullin e ardhshĂ«m tĂ« agregimit, dhe modification_time Ă«shtĂ« mĂ« e vjetĂ«r se ky moment.

Implementimi

Ky kërkesë

SELEKTO
    concat(p.database, '.', p.table) AS table,
    p.partition_id AS partition_id,
    p.partition AS partition,
    -- Rregulli më "i vjetër", që mund të aplikohet për
    -- particionin, por jo në të ardhmen, shiko (*)
    max(g.age) AS age,
    -- Numri i pjesëve në particion
    countDistinct(p.name) AS parts,
    -- Metri më i vjetër në particion pranohet 00:00:00 e ditës së ardhshme
    toDateTime(max(p.max_date + 1)) AS max_time,
    -- Kur particiones duhet të optimizohet
    max_time + age AS rollup_time,
    -- Kur pjesa më e vjetër në particion është përditësuar
    min(p.modification_time) AS modified_at
FROM system.parts AS p
INNER JOIN
(
    -- Të gjitha rregullat për të gjitha tabelat *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
    -- Vetëm pjesët aktive
    p.active
    -- (*) Dhe vetëm rreshtat, ku rregullat e agregatimit tashmë duhet të aplikohen
    AND ((toDateTime(p.max_date + 1) + g.age) < now())
GROUP BY
    table,
    partition
HAVING
    -- Vetëm particionet që janë më të rinj se momenti i optimizimit
    (modified_at  1)
ORDER BY
    table ASC,
    partition ASC,
    age ASC

kthen çdo nga partitë e tabelave *GraphiteMergeTree, të cilat duhet të bashkohen për të liruar hapësirën në disk. E vetmja gjë që mbetet është të kalosh nëpër to të gjitha me një kërkesë OPTIMIZE ... FINAL. Në implementimin përfundimtar është marrë parasysh gjithashtu fakti se nuk ka nevojë të prekësh partitë me shkrim aktiv.

Kjo është ajo që bën projekti graphite-ch-optimizer. Koleget e mia të vjetra nga Yandex.Market e provuan atë në prodhim, rezultatin e punës mund ta shihni më poshtë.

ClickHouse + Graphite: si si reduktojmë ndjeshëm hapësirën e përdorur në disqe

Nëse e nisni programin në një server me ClickHouse, ai do të fillojë të punojë thjesht në modin demon. Njëherë në orë do të ekzekutohet një kërkesë që kontrollon nëse ka partitë të reja më të vjetra se tre ditë që mund të optimizohen.

Në planet e afërta është të ofrohet, të paktën, paketat deb, dhe, sa më shumë të jetë e mundur, gjithashtu rpm.

Në përfundim

Në 9 muajt e kaluar kam kaluar shumë kohë brenda kompanisë sime InnoGames duke u marrë me ClickHouse dhe graphite-web. Ky ishte një përvojë e mirë, rezultati i së cilës e bëri kalimin e shpejtë nga whisper në ClickHouse si një depo për metrikat e mundshëm. Shpresoj që ky artikull të jetë një lloj fillimi i një cikli mbi përmirësimet që kemi bërë në pjesë të ndryshme të këtij stivi, dhe se çfarë do të bëhet në të ardhmen.

Për zhvillimin e kërkesës u shpenzuan disa litra birrë dhe ditë administratori së bashku me v0devil, për të cilin do të doja të shprehja mirënjohjen time. Po ashtu për rishikimin e këtij artikulli.

Faqja e projektit në github

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster