🥇ClickHouse + Graphite: carane nyuda konsumsi ruang disk kanthi signifikan

Sugeng rawuh, habr.

Yen wong eksploitasi sistem grafit-web lan nemoni masalah kinerja panyimpenan bisikna (IO, spasi disk migunakaken), banjur kasempatan sing ClickHouse dibuwang minangka panggantos ngirim kathah siji. Pernyataan iki nuduhake yen implementasi pihak katelu wis digunakake minangka metrik panampa daemon, contone. panulis karbon utawa go-karbon.

ClickHouse ngrampungake masalah sing diterangake kanthi apik. Contone, sawise nransfer 2TiB data saka whisper, padha pas menyang 300GiB. Aku ora bakal mikir babagan perbandingan kanthi rinci; ana akeh artikel babagan topik iki. Kajaba iku, nganti saiki, ora kabeh sampurna karo panyimpenan ClickHouse kita.

Masalah karo papan sing dikonsumsi

Ing kawitan marketing, kabeh kudu bisa uga. Nderek dokumentasi, nggawe konfigurasi kanggo skema panyimpenan metrik (luwih retention), banjur gawe tabel miturut rekomendasi backend sing dipilih kanggo graphite-web: karbon-clickhouse+grafit-clickhouse utawa graphouse, gumantung ing tumpukan sing digunakake. Lan... bom wektu mati.

Kanggo ngerti sing endi, sampeyan kudu ngerti cara kerjane sisipan lan jalur urip data luwih lanjut ing tabel mesin kulawarga *MergeTree ClickHouse (grafik dijupuk saka presentasi Alexey Zatelepin):

Dilebokake блок data. Ing kasus kita, iku metrik sing teka.
Saben blok kasebut diurutake miturut kunci sadurunge ditulis menyang disk. ORDER BYditemtokake nalika nggawe tabel.
Sawise diurutake, кусок (part) data ditulis menyang disk.
Server ngawasi ing latar mburi supaya ora akeh potongan kasebut, lan miwiti latar mburi слияния (merge, salajengipun gabung).
Server mandheg mlaku merges dhewe sanalika data mandheg aktif mili menyang партицию (partition), nanging sampeyan bisa miwiti proses kanthi manual nganggo printah OPTIMIZE.
Yen mung ana siji potong ing partisi, sampeyan ora bakal bisa mbukak gabungan nggunakake printah biasanipun; sampeyan kudu nggunakake OPTIMIZE ... FINAL

Dadi, metrik pisanan teka. Lan padha njupuk sawetara papan. Acara sakteruse bisa beda-beda gumantung saka akeh faktor:

Tombol partisi bisa dadi cilik banget (sedina) utawa gedhe banget (sawetara sasi).
Konfigurasi retensi bisa uga cocog karo sawetara ambang agregasi data sing signifikan ing partisi aktif (ing ngendi metrik dicathet), utawa bisa uga ora.
Yen ana akeh data, mula potongan paling awal, sing amarga latar mburi gabung bisa uga ageng (yen sampeyan milih kunci pemisahan sing ora optimal), ora bakal gabung karo potongan cilik sing seger.

Lan tansah ends padha. Spasi sing dikuwasani dening metrik ing ClickHouse mung mundhak yen:

ora nglamar OPTIMIZE ... FINAL kanthi manual utawa
aja nglebokake data menyang kabeh partisi kanthi terus-terusan, supaya cepet utawa mengko gabungan latar mburi bakal diwiwiti

Cara kapindho katon paling gampang kanggo dileksanakake lan mulane ora bener lan dicoba dhisik.
Aku nulis skrip python sing cukup prasaja sing ngirim metrik dummy kanggo saben dina suwene 4 taun kepungkur lan mlayu cron saben jam.
Wiwit kabeh operasi ClickHouse DBMS adhedhasar kasunyatan sing sistem iki cepet utawa mengko bakal nindakake kabeh karya latar mburi, nanging ora dikenal nalika, Aku ora bisa ngenteni wayahe nalika bêsik ageng lawas deign kanggo miwiti gabung karo. anyar cilik. Dadi jelas yen kita kudu golek cara kanggo ngotomatisasi optimasi paksa.

Informasi ing tabel sistem ClickHouse

Ayo ndeleng struktur meja sistem.bagean. Iki minangka informasi lengkap babagan saben potongan kabeh tabel ing server ClickHouse. Ngandhut, antara liya, kolom ing ngisor iki:

jeneng db (database);
jeneng meja (table);
jeneng partisi lan ID (partition & partition_id);
nalika potongan kasebut digawe (modification_time);
tanggal minimal lan maksimum ing sepotong (pemisahan ditindakake saben dina) (min_date & max_date);

Ana uga meja system.graphite_retentions, kanthi lapangan menarik ing ngisor iki:

jeneng db (Tables.database);
jeneng meja (Tables.table);
umur metrik nalika agregasi sabanjure kudu ditrapake (age);

Dadi:

Kita duwe tabel potongan lan tabel aturan agregasi.
Kita gabungke persimpangan lan entuk kabeh tabel *GraphiteMergeTree.
We are looking for kabeh partisi kang:
- luwih saka siji potong
- utawa wektu wis teka kanggo aplikasi aturan panggabungan sabanjuré, lan modification_time luwih tuwa tinimbang wayahe iki.

Реализация

panjalukan iki

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

ngasilake saben partisi tabel *GraphiteMergeTree sing gabung kudu mbebasake ruang disk. Siji-sijine perkara sing kudu ditindakake yaiku ngliwati kabeh kanthi panjaluk OPTIMIZE ... FINAL. Implementasi pungkasan uga nyathet kasunyatan manawa ora perlu ndemek partisi kanthi rekaman aktif.

Iki persis apa sing ditindakake proyek kasebut graphite-ch-optimizer. Mantan kolega saka Yandex.Market nyoba ing produksi, asil karya bisa dideleng ing ngisor iki.

Yen sampeyan mbukak program ing server karo ClickHouse, iku mung bakal miwiti digunakake ing mode daemon. Sawise jam panjaluk bakal dileksanakake, mriksa manawa partisi anyar sing luwih lawas saka telung dina wis katon sing bisa dioptimalake.

Rencana langsung kita nyedhiyakake paling ora paket deb, lan yen bisa uga rpm.

Tinimbang kesimpulan

Swara 9+ sasi kepungkur aku wis nang perusahaan innogames ngginakaken akèh wektu tinkering ing persimpangan ClickHouse lan grafit-web. Iku pengalaman sing apik, sing nyebabake transisi cepet saka bisik menyang ClickHouse minangka panyimpenan metrik. Muga-muga artikel iki minangka wiwitan saka seri babagan dandan apa sing wis ditindakake ing macem-macem bagean tumpukan iki, lan apa sing bakal ditindakake ing mangsa ngarep.

Sawetara liter bir lan dina admin digunakake kanggo ngembangake panyuwunan kasebut, bebarengan karo v0 setan, ingkang kula aturaken agunging panuwun dhumateng panjenenganipun. Lan uga kanggo mriksa artikel iki.

Kaca proyek ing github

Source: www.habr.com

ClickHouse + Graphite: carane nyuda konsumsi ruang disk kanthi signifikan

Masalah karo papan sing dikonsumsi

Informasi ing tabel sistem ClickHouse

Реализация

Tinimbang kesimpulan

Add a comment Отменить ответ