ClickHouse + Graphite: jinsi ya kupunguza kwa kiasi kikubwa matumizi ya nafasi ya diski

Salamu, habr.

Ikiwa mtu anatumia mfumo vibaya mtandao wa grafiti na kukumbana na tatizo la utendakazi wa hifadhi whisper (IO, nafasi ya diski inayotumiwa), basi nafasi ya kwamba ClickHouse ilitupwa kama mbadala inapaswa kuwa moja. Taarifa hii ina maana kwamba utekelezaji wa wahusika wengine tayari unatumika kama vipimo vya kupokea daemon, kwa mfano. mwandishi wa kaboni au kwenda-kaboni.

ClickHouse hutatua shida zilizoelezewa vizuri. Kwa mfano, baada ya kuhamisha 2TiB ya data kutoka kwa kunong'ona, zinafaa kwenye 300GiB. Sitakaa juu ya kulinganisha kwa undani; kuna nakala nyingi juu ya mada hii. Kwa kuongeza, hadi hivi karibuni, sio kila kitu kilikuwa kamili na hifadhi yetu ya ClickHouse.

Matatizo na nafasi inayotumiwa

Kwa mtazamo wa kwanza, kila kitu kinapaswa kufanya kazi vizuri. Kufuatia nyaraka, unda usanidi wa mpango wa uhifadhi wa vipimo (zaidi retention), kisha unda jedwali kulingana na pendekezo la sehemu ya nyuma iliyochaguliwa ya wavuti ya grafiti: kaboni-clickhouse+graphite-clickhouse au nyumba ya grafu, kulingana na stack ambayo hutumiwa. Na ... wakati bomu huenda.

Ili kuelewa ni ipi, unahitaji kujua jinsi kuingiza hufanya kazi na njia zaidi ya maisha ya data kwenye jedwali la injini za familia *MergeTree ClickHouse (chati zilizochukuliwa kutoka mawasilisho Alexey Zatelepin):

• imeingizwa блок data. Kwa upande wetu, ilikuwa vipimo vilivyofika.
  
• Kila kizuizi kama hicho hupangwa kulingana na ufunguo kabla ya kuandikwa kwa diski. ORDER BYmaalum wakati wa kuunda meza.
• Baada ya kupanga, кусок (part) data imeandikwa kwa diski.
  
• Seva inafuatilia kwa nyuma ili hakuna vipande vingi kama hivyo, na kuzindua mandharinyuma слияния (merge, unganisha baadaye).
  
  
• Seva itaacha kufanya kazi muunganisho yenyewe mara tu data inapoacha kutiririka kikamilifu kwenye faili ya партицию (partition), lakini unaweza kuanza mchakato kwa mikono na amri OPTIMIZE.
• Ikiwa kuna kipande kimoja tu kilichobaki kwenye kizigeu, basi hautaweza kuendesha unganisho kwa kutumia amri ya kawaida; lazima utumie OPTIMIZE ... FINAL

Kwa hivyo, vipimo vya kwanza vinafika. Na wanachukua nafasi fulani. Matukio yanayofuata yanaweza kutofautiana kwa kiasi fulani kulingana na mambo mengi:

• Kitufe cha kugawa kinaweza kuwa kidogo sana (siku) au kikubwa sana (miezi kadhaa).
• Mipangilio ya kubaki inaweza kutoshea vizingiti kadhaa muhimu vya ujumlishaji wa data ndani ya kizigeu kinachotumika (ambapo vipimo vimerekodiwa), au labda sivyo.
• Ikiwa kuna data nyingi, basi vipande vya mapema zaidi, ambavyo kwa sababu ya uunganisho wa mandharinyuma vinaweza kuwa vikubwa (ikiwa utachagua ufunguo usio wa kugawanya usio bora), hautajiunganisha na vipande vidogo vidogo.

Na daima huisha sawa. Nafasi inayokaliwa na vipimo katika ClickHouse huongezeka tu ikiwa:

• usitumie OPTIMIZE ... FINAL kwa mikono au
• usiingize data katika sehemu zote kwa msingi unaoendelea, ili mapema au baadaye uunganisho wa usuli utaanza

Njia ya pili inaonekana kuwa rahisi zaidi kutekeleza na, kwa hiyo, si sahihi na ilijaribiwa kwanza.
Niliandika hati rahisi ya python ambayo ilituma metrics za dummy kwa kila siku kwa miaka 4 iliyopita na kukimbia cron kila saa.
Kwa kuwa operesheni nzima ya ClickHouse DBMS inategemea ukweli kwamba mfumo huu utafanya kazi yote ya nyuma mapema au baadaye, lakini haijulikani ni lini, sikuweza kungojea wakati vipande vikubwa vya zamani vitaanza kuunganishwa na. mpya ndogo. Ilionekana wazi kuwa tulihitaji kutafuta njia ya kubinafsisha uboreshaji wa kulazimishwa.

Taarifa katika majedwali ya mfumo wa ClickHouse

Wacha tuangalie muundo wa meza mfumo.sehemu. Hii ni habari ya kina kuhusu kila kipande cha majedwali yote kwenye seva ya ClickHouse. Ina, kati ya mambo mengine, safu zifuatazo:

• db jina (database);
• jina la meza (table);
• jina la sehemu na kitambulisho (partition & partition_id);
• wakati kipande kilipoundwa (modification_time);
• tarehe ya chini na ya juu katika kipande (kugawa hufanywa kwa siku) (min_date & max_date);

Pia kuna meza mfumo.uhifadhi_wa_graphite, pamoja na nyanja zifuatazo za kuvutia:

• db jina (Tables.database);
• jina la meza (Tables.table);
• umri wa kipimo ambapo muunganisho unaofuata unapaswa kutumika (age);

Hivyo:

1. Tunayo jedwali la vipande na jedwali la sheria za kujumlisha.
2. Tunaunganisha makutano yao na kupata meza zote *GraphiteMergeTree.
3. Tunatafuta sehemu zote ambazo:
   • zaidi ya kipande kimoja
   • au wakati umefika wa kutumia kanuni inayofuata ya ujumlisho, na modification_time mzee kuliko wakati huu.

Utekelezaji

Ombi hili

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

hurejesha kila sehemu ya jedwali la *GraphiteMergeTree ambalo uunganishaji wake unapaswa kutoa nafasi ya diski. Kitu pekee kilichobaki kufanya ni kuwapitia wote kwa ombi OPTIMIZE ... FINAL. Utekelezaji wa mwisho pia unazingatia ukweli kwamba hakuna haja ya kugusa partitions na kurekodi kazi.

Hivi ndivyo mradi unavyofanya graphite-ch-optimizer. Wenzake wa zamani kutoka Yandex.Market walijaribu katika uzalishaji, matokeo ya kazi yanaweza kuonekana hapa chini.

Ikiwa utaendesha programu kwenye seva na ClickHouse, itaanza kufanya kazi katika hali ya daemon. Mara moja kwa saa ombi litatekelezwa, kuangalia kama sehemu mpya za zamani zaidi ya siku tatu zimeonekana ambazo zinaweza kuboreshwa.

Mipango yetu ya haraka ni kutoa angalau vifurushi vya deni, na ikiwezekana pia rpm.

Badala ya hitimisho

Zaidi ya miezi 9+ iliyopita nimekuwa ndani ya kampuni yangu innogames alitumia muda mwingi kuchezea kwenye makutano ya ClickHouse na grafiti-web. Ilikuwa ni uzoefu mzuri, ambao ulisababisha mabadiliko ya haraka kutoka kwa whisper hadi ClickHouse kama hifadhi ya vipimo. Natumai nakala hii ni mwanzo wa mfululizo kuhusu maboresho ambayo tumefanya kwa sehemu mbalimbali za rundo hili, na nini kitafanywa katika siku zijazo.

Lita kadhaa za siku za bia na msimamizi zilitumika kuunda ombi, pamoja na v0 shetani, ambayo ninataka kutoa shukrani zangu kwake. Na pia kwa kukagua nakala hii.

Ukurasa wa mradi kwenye github

Chanzo: mapenzi.com