🥇ClickHouse + Graffit: sut i leihau'r defnydd o le ar ddisg yn sylweddol

Cyfarchion habr.

Os oes rhywun yn gweithredu'r system gwe graffit ac aeth ymlaen i fater perfformiad storio sibrwd (IO, lle disg a ddefnyddiwyd), yna dylai'r siawns yr edrychwyd ar ClickHouse fel un newydd fod yn agos at un. Mae'r datganiad hwn yn awgrymu bod gweithrediad trydydd parti eisoes yn cael ei ddefnyddio fel yr ellyll derbyn, er enghraifft awdur carbon neu mynd carbon.

Mae ClickHouse yn datrys y problemau a ddisgrifir yn dda. Er enghraifft, ar ôl arllwys 2TiB o ddata o sibrwd, maent yn ffitio i mewn i 300GiB. Ni fyddaf yn aros ar y gymhariaeth yn fanwl, mae digon o erthyglau ar y pwnc hwn. Yn ogystal, tan yn ddiweddar, nid oedd popeth yn berffaith gyda'n storfa ClickHouse.

Materion Gofod Defnydd

Ar yr olwg gyntaf, dylai popeth weithio'n dda. Yn dilyn dogfennaeth, creu ffurfwedd ar gyfer y cynllun storio metrigau (o hyn ymlaen retention), yna creu tabl yn unol ag argymhelliad yr ôl-wyneb gwe graffit a ddewiswyd: carbon-clicws+graffit-clichouse neu graffws, yn dibynnu ar ba stac sy'n cael ei ddefnyddio. A… bom amser yn cael ei actifadu.

Er mwyn deall pa un, mae angen i chi wybod sut mae mewnosodiadau'n gweithio a llwybr bywyd pellach data mewn tablau o beiriannau teulu *MergeTree ClickHouse (diagramau wedi'u cymryd o cyflwyniadau Alexey Zatelepin):

Mewnosodwyd блок data. Yn ein hachos ni, metrigau yw'r rhain.
Mae pob bloc o'r fath yn cael ei ddidoli yn ôl yr allwedd cyn ei ysgrifennu i ddisg. ORDER BYY pennwyd pryd y crëwyd y tabl.
Ar ôl didoli, кусок (part) bod data wedi'i ysgrifennu ar ddisg.
Mae'r gweinydd yn monitro yn y cefndir fel nad oes llawer o ddarnau o'r fath, ac yn lansio cefndir слияния (merge, yna uno).
Mae'r gweinydd yn rhoi'r gorau i lansio uno ar ei ben ei hun cyn gynted ag y bydd y data'n stopio llifo i mewn партицию (partition), ond gallwch chi gychwyn y broses â llaw gyda'r gorchymyn OPTIMIZE.
Os mai dim ond un darn sydd ar ôl yn y rhaniad, yna ni fyddwch yn gallu cychwyn yr uno gyda'r gorchymyn arferol, rhaid i chi ddefnyddio OPTIMIZE ... FINAL

Felly, mae'r metrigau cyntaf yn cyrraedd. Ac maen nhw'n cymryd rhywfaint o le. Gall digwyddiadau dilynol amrywio rhywfaint yn dibynnu ar lawer o ffactorau:

Gall allwedd y rhaniad fod naill ai'n fach iawn (diwrnod) neu'n fawr iawn (sawl mis).
Gall y cyfluniad cadw ffitio sawl trothwy agregu data sylweddol y tu mewn i'r rhaniad gweithredol (lle mae'r metrigau wedi'u hysgrifennu), neu efallai ddim.
Os oes llawer o ddata, yna ni fydd y talpiau cynharaf, a all fod yn enfawr eisoes oherwydd uno cefndirol (wrth ddewis allwedd rhannu nad yw'n optimaidd), yn uno eu hunain â thapiau bach ffres.

Ac mae bob amser yn dod i ben yr un peth. Dim ond os:

peidiwch â gwneud cais OPTIMIZE ... FINAL â llaw neu
peidiwch â mewnosod data ym mhob rhaniad yn barhaus er mwyn dechrau uno cefndirol yn hwyr neu'n hwyrach

Ymddengys mai'r ail ddull yw'r hawsaf i'w weithredu ac, felly, mae'n anghywir ac fe'i profwyd yn y lle cyntaf.
Ysgrifennais sgript python eithaf syml sy'n anfon metrigau ffug am bob dydd am y 4 blynedd diwethaf ac yn rhedeg bob awr gyda cron.
Gan fod holl waith ClickHouse DBMS yn seiliedig ar y ffaith y bydd y system hon yn gwneud yr holl waith cefndir yn hwyr neu'n hwyrach, ond nid yw'n hysbys pryd, ni lwyddais i aros am y foment pan fydd yr hen ddarnau enfawr yn dylunio i ddechrau uno. gyda rhai bach newydd. Daeth yn amlwg bod angen i ni ddod o hyd i ffordd i awtomeiddio optimeiddiadau gorfodol.

Gwybodaeth yn nhablau system ClickHouse

Gadewch i ni edrych ar strwythur y bwrdd system.parts. Mae hon yn wybodaeth gynhwysfawr am bob darn o'r holl dablau ar weinydd ClickHouse. Yn cynnwys, ymhlith pethau eraill, y colofnau canlynol:

enw cronfa ddata (database);
enw tabl (table);
enw ac ID rhaniad (partition & partition_id);
pan gafodd y darn ei greu (modification_time);
dyddiad lleiaf ac uchafswm yn y darn (mae rhaniad fesul dydd) (min_date & max_date);

Mae bwrdd hefyd system.graphite_retentions, gyda'r meysydd diddorol canlynol:

enw cronfa ddata (Tables.database);
enw tabl (Tables.table);
oedran y metrig pryd y dylid defnyddio'r agregiad nesaf (age);

Felly:

Mae gennym dabl o dalpiau a thabl o reolau cydgasglu.
Rydym yn cyfuno eu croestoriad ac yn cael yr holl dablau *GraphiteMergeTree.
Rydym yn chwilio am bob rhaniad lle mae:
- mwy nag un darn
- neu yr amser wedi dyfod i gymhwyso y rheol gydgasglu nesaf, a modification_time hŷn na'r foment hon.

Gweithredu

Y cais hwn

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

yn dychwelyd pob un o'r rhaniadau tabl *GraphiteMergeTree y dylid eu huno i ryddhau lle ar y ddisg. Nid yw yn aros ond am bethau bychain : ewch trwyddynt oll gyda chais OPTIMIZE ... FINAL. Roedd y gweithrediad terfynol hefyd yn cymryd i ystyriaeth y ffaith nad oes angen cyffwrdd rhaniadau gyda chofnod gweithredol.

Dyma beth mae'r prosiect yn ei wneud. graffit-ch-optimizer. Profodd cyn-gydweithwyr o Yandex.Market ef wrth gynhyrchu, gellir gweld canlyniad y gwaith isod.

Os ydych chi'n rhedeg y rhaglen ar weinydd gyda ClickHouse, bydd yn dechrau gweithio yn y modd daemon. Unwaith yr awr, bydd ymholiad yn cael ei weithredu, gan wirio a oes rhaniadau newydd yn hŷn na thri diwrnod y gellir eu hoptimeiddio.

Yn y dyfodol agos - i ddarparu o leiaf pecynnau deb, ac os yn bosibl - hefyd rpm.

Yn hytrach na i gasgliad

Am y 9+ mis diwethaf, rwyf wedi bod yn fy nghwmni Gemau Inno treulio llawer o amser yn coginio ar gyffordd ClickHouse a graffit-web. Roedd yn brofiad da, a arweiniodd at drawsnewidiad cyflym o sibrwd i ClickHouse fel ystorfa o fetrigau. Rwy’n gobeithio bod yr erthygl hon yn rhywbeth tebyg i ddechrau cylch am ba welliannau rydym wedi’u gwneud i wahanol rannau o’r pentwr hwn, a beth fydd yn cael ei wneud yn y dyfodol.

Treuliwyd sawl litr o gwrw a diwrnodau gweinyddol ar ddatblygu'r cais, ynghyd â v0 diafolyr wyf am fynegi fy niolch iddo am hynny. A hefyd am adolygu'r erthygl hon.

Tudalen prosiect ar github

Ffynhonnell: hab.com

ClickHouse + Graffit: Sut i Leihau'n Sylweddol y Gofod Disg sy'n cael ei Ddefnyddio

Materion Gofod Defnydd

Gwybodaeth yn nhablau system ClickHouse

Gweithredu

Yn hytrach na i gasgliad

Ychwanegu sylw Diddymu ateb