🥇ClickHouse + Grafitoa: nola murriztu diskoko espazioaren kontsumoa nabarmen

Agurrak, habr.

Norbaitek sistema ustiatzen badu grafito-web eta biltegiratze-errendimendu-arazo bat aurkitu duzu xuxurla (IO, diskoko espazioa kontsumituta), orduan ClickHouse ordezko gisa botatzeko aukerak bat izan beharko luke. Adierazpen honek esan nahi du hirugarrenen inplementazioa dagoeneko erabiltzen dela neurgailuak jasotzen dituen deabru gisa, adibidez karbono-idazlea edo joan-karbonoa.

ClickHouse-k ondo konpontzen ditu deskribatutako arazoak. Adibidez, whisper-etik 2TiB datu transferitu ondoren, 300GiB-ra sartzen dira. Ez naiz konparazioan zehatz-mehatz luzatuko; gai honi buruzko artikulu ugari daude. Gainera, duela gutxi arte, dena ez zen perfektua gure ClickHouse biltegiarekin.

Kontsumitutako espazioarekin arazoak

Lehen begiratuan, dena ondo funtzionatu beharko luke. Jarraian dokumentazioa, sortu konfigurazio bat metrikak biltegiratzeko eskemarako (gehiago retention), ondoren sortu taula bat grafito-web-erako hautatutako backendaren gomendioaren arabera: karbono-clickhouse+grafito-clickhouse edo grafikoa, zein pila erabiltzen den arabera. Eta... erloju-bonba pizten da.

Zein ulertzeko, txertatzeek nola funtzionatzen duten eta datuen bizi-ibilbidea * familiako motor tauletan nola funtzionatzen duten jakin behar duzu.MergeTree ClickHouse (diagramatik ateratakoak презентации Alexey Zatelepin):

Txertatuta блок datuak. Gure kasuan, neurketak izan ziren iritsi zirenak.
Bloke bakoitza gakoaren arabera ordenatzen da diskoan idatzi aurretik. ORDER BYtaula sortzean zehaztuta.
Sailkatu ondoren, кусок (part) datuak diskoan idazten dira.
Zerbitzariak atzeko planoan kontrolatzen du, horrelako pieza asko ez egon daitezen, eta atzeko planoa abiarazten du слияния (merge, aurrerantzean batu).
Zerbitzariak bere kabuz konbinazioak exekutatzeari uzten dio datuak aktiboki isurtzeari uzten dioten bezain laster партицию (partition), baina prozesua eskuz has dezakezu komandoarekin OPTIMIZE.
Partizioan pieza bakarra geratzen bada, ezin izango duzu batuketa exekutatu ohiko komandoa erabiliz; erabili behar duzu OPTIMIZE ... FINAL

Beraz, lehenengo neurketak iristen dira. Eta leku pixka bat hartzen dute. Ondorengo gertaerak zertxobait alda daitezke faktore askoren arabera:

Partizio-gakoa oso txikia (egun bat) edo oso handia (hainbat hilabete) izan daiteke.
Atxikipen konfigurazioa partizio aktiboaren barruan (neurriak erregistratzen diren tokian) hainbat datu-agregazio atalase esanguratsu egokitzea izan daiteke edo agian ez.
Datu asko baldin badaude, lehen zatiak, atzeko planoan batzea dela eta dagoeneko handiak izan daitezke (partizio-gako ez-optimoa aukeratzen baduzu), ez dira zati txiki berriekin batuko.

Eta beti berdin bukatzen da. ClickHouse-n metrikek hartzen duten espazioa soilik handitzen da:

ez aplikatu OPTIMIZE ... FINAL eskuz edo
ez txertatu datuak partizio guztietan etengabe, lehenago edo beranduago atzeko planoko batuketa bat hasiko da

Bigarren metodoa ezartzeko errazena dela dirudi eta, beraz, okerra da eta lehen probatu zen.
Python script nahiko sinple bat idatzi nuen, azken 4 urteetan egunero-egunero metrika bidaltzen zituena eta orduro cron exekutatzen zuen.
ClickHouse DBMSren funtzionamendu osoa sistema honek lehenago edo beranduago atzeko lan guztiak egingo dituelako oinarrian dagoenez, baina ez dakigu noiz, ezin izan nuen itxaron pieza erraldoi zaharrak bateratzen hasteko momentua. txiki berriak. Argi geratu zen behartutako optimizazioak automatizatzeko modua bilatu behar genuela.

ClickHouse sistema-tauletako informazioa

Ikus dezagun taularen egiturari sistema.zatiak. Hau ClickHouse zerbitzariko taula guztien zati bakoitzari buruzko informazio osoa da. Besteak beste, zutabe hauek ditu:

db izena (database);
taularen izena (table);
partizioaren izena eta ID (partition & partition_id);
pieza sortu zenean (modification_time);
gutxieneko eta gehienezko data pieza batean (banaketa egunez egiten da) (min_date & max_date);

Mahai bat ere badago sistema.grafito_erretentzioak, eremu interesgarri hauekin:

db izena (Tables.database);
taularen izena (Tables.table);
hurrengo agregazioa aplikatu behar den adin metrikoa (age);

Beraz:

Zati-taula eta agregazio-arauen taula ditugu.
Haien elkargunea konbinatzen dugu eta taula guztiak *GraphiteMergeTree lortzen ditugu.
Partizio guztiak bilatzen ari gara, zeinetan:
- pieza bat baino gehiago
- edo hurrengo batuketa-araua aplikatzeko garaia heldu da, eta modification_time une hau baino zaharragoa.

Inplementazioa

Eskaera hau

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 taula-partizioetako bakoitza itzultzen du, zeinen bateratzeak diskoko lekua askatu beharko lukeen. Egin beharreko gauza bakarra denak eskaera batekin pasatzea da OPTIMIZE ... FINAL. Azken inplementazioak ere kontuan hartzen du ez dagoela partizioak ukitu beharrik grabaketa aktiboarekin.

Hori da, hain zuzen, proiektuak egiten duena grafito-ch-optimizatzailea. Yandex.Market-eko lankide ohiek ekoizpenean probatu zuten, lanaren emaitza behean ikus daiteke.

Programa ClickHouse-rekin zerbitzari batean exekutatzen baduzu, deabru moduan lanean hasiko da. Ordubetean eskaera bat exekutatuko da, optimizatu daitezkeen hiru egun baino zaharragoak diren partizio berriak agertu diren egiaztatuz.

Gure berehalako planak gutxienez deb paketeak eskaintzea da, eta ahal bada rpm ere.

Horren ordez Ondorio baten

Azken 9 hilabeteetan nire enpresan egon naiz innogames denbora asko eman zuen ClickHouse eta grafito-web-en elkargunean txukuntzen. Esperientzia ona izan zen, eta horrek xuxurlatutik ClickHouserako trantsizio azkarra ekarri zuen metrika biltegiratze gisa. Espero dut artikulu hau pila honen hainbat ataletan egin ditugun hobekuntzak eta etorkizunean zer egingo den serie baten hasierako zerbait izatea.

Hainbat litro garagardo eta administrazio-egun eman ziren eskaera garatzen, batera v0devil, eta horregatik nire esker ona adierazi nahi diot. Eta baita artikulu hau berrikusteagatik.

Proiektuaren orria github-en

Iturria: www.habr.com

ClickHouse + Grafitoa: nola murriztu diskoko espazioaren kontsumoa nabarmen

Kontsumitutako espazioarekin arazoak

ClickHouse sistema-tauletako informazioa

Inplementazioa

Horren ordez Ondorio baten

Gehitu iruzkin berria Idatzi