ClickHouse + Graphite: bagaimana untuk mengurangkan penggunaan ruang cakera dengan ketara

Salam, habr.

Jika seseorang mengeksploitasi sistem grafit-web dan menghadapi masalah prestasi storan bisikan (IO, ruang cakera digunakan), maka peluang bahawa ClickHouse dilemparkan sebagai pengganti sepatutnya cenderung kepada satu. Pernyataan ini menunjukkan bahawa pelaksanaan pihak ketiga telah digunakan sebagai metrik penerima daemon, contohnya penulis karbon atau pergi-karbon.

ClickHouse menyelesaikan masalah yang diterangkan dengan baik. Sebagai contoh, selepas memindahkan 2TiB data daripada bisikan, ia masuk ke dalam 300GiB. Saya tidak akan memikirkan perbandingan secara terperinci; terdapat banyak artikel mengenai topik ini. Di samping itu, sehingga baru-baru ini, tidak semuanya sempurna dengan storan ClickHouse kami.

Masalah dengan ruang yang digunakan

Pada pandangan pertama, semuanya harus berfungsi dengan baik. Mengikuti dokumentasi, buat konfigurasi untuk skema storan metrik (selanjutnya retention), kemudian buat jadual mengikut cadangan hujung belakang yang dipilih untuk graphite-web: rumah klik karbon+graphite-clickhouse atau rumah graf, bergantung pada tindanan yang digunakan. Dan... bom masa meledak.

Untuk memahami yang mana satu, anda perlu tahu cara sisipan berfungsi dan laluan hayat selanjutnya data dalam jadual enjin keluarga *MergeTree ClickHouse (carta diambil daripada pembentangan Alexey Zatelepin):

• Disisipkan блок data. Dalam kes kami, metrik yang tiba.
  
• Setiap blok tersebut diisih mengikut kekunci sebelum ditulis ke cakera. ORDER BYdinyatakan semasa membuat jadual.
• Selepas menyusun, кусок (part) data ditulis ke cakera.
  
• Pelayan memantau di latar belakang supaya tidak terdapat banyak bahagian seperti itu, dan melancarkan latar belakang слияния (merge, selepas ini bergabung).
  
  
• Pelayan berhenti berjalan bergabung dengan sendirinya sebaik sahaja data berhenti mengalir secara aktif ke dalam партицию (partition), tetapi anda boleh memulakan proses secara manual dengan arahan OPTIMIZE.
• Jika hanya tinggal satu bahagian dalam partition, maka anda tidak akan dapat menjalankan gabungan menggunakan arahan biasa; anda mesti menggunakan OPTIMIZE ... FINAL

Jadi, metrik pertama tiba. Dan mereka mengambil sedikit ruang. Peristiwa seterusnya mungkin agak berbeza bergantung pada banyak faktor:

• Kunci pembahagian boleh sama ada sangat kecil (sehari) atau sangat besar (beberapa bulan).
• Konfigurasi pengekalan mungkin sesuai dengan beberapa ambang pengagregatan data yang ketara dalam partition aktif (tempat metrik direkodkan), atau mungkin tidak.
• Jika terdapat banyak data, maka ketulan terawal, yang disebabkan penggabungan latar belakang mungkin sudah besar (jika anda memilih kekunci pembahagian yang tidak optimum), tidak akan bergabung dengan ketulan kecil yang baru.

Dan ia sentiasa berakhir sama. Ruang yang diduduki oleh metrik dalam ClickHouse hanya meningkat jika:

• jangan memohon OPTIMIZE ... FINAL secara manual atau
• jangan masukkan data ke dalam semua partition secara berterusan, supaya lambat laun gabungan latar belakang akan bermula

Kaedah kedua nampaknya paling mudah untuk dilaksanakan dan, oleh itu, ia tidak betul dan telah dicuba terlebih dahulu.
Saya menulis skrip python yang agak mudah yang menghantar metrik tiruan untuk setiap hari selama 4 tahun yang lalu dan menjalankan cron setiap jam.
Oleh kerana keseluruhan operasi ClickHouse DBMS adalah berdasarkan fakta bahawa sistem ini lambat laun akan melakukan semua kerja latar belakang, tetapi tidak diketahui bila, saya tidak dapat menunggu saat apabila kepingan besar lama berkenan untuk mula bergabung dengan yang baru kecil. Ia menjadi jelas bahawa kami perlu mencari cara untuk mengautomasikan pengoptimuman paksa.

Maklumat dalam jadual sistem ClickHouse

Mari kita lihat struktur jadual sistem.bahagian. Ini adalah maklumat komprehensif tentang setiap bahagian semua jadual pada pelayan ClickHouse. Mengandungi, antara lain, lajur berikut:

• nama db (database);
• nama jadual (table);
• nama partition dan ID (partition & partition_id);
• apabila sekeping itu dicipta (modification_time);
• tarikh minimum dan maksimum dalam sekeping (pembahagian dilakukan mengikut hari) (min_date & max_date);

Terdapat juga meja sistem.pengekalan_grafit, dengan medan menarik berikut:

• nama db (Tables.database);
• nama jadual (Tables.table);
• umur metrik apabila pengagregatan seterusnya harus digunakan (age);

Jadi:

1. Kami mempunyai jadual ketulan dan jadual peraturan pengagregatan.
2. Kami menggabungkan persimpangan mereka dan mendapatkan semua jadual *GraphiteMergeTree.
3. Kami sedang mencari semua partition di mana:
   • lebih daripada sehelai
   • atau sudah tiba masanya untuk menggunakan peraturan pengagregatan seterusnya, dan modification_time lebih tua daripada saat ini.

Реализация

permintaan ini

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

mengembalikan setiap sekatan jadual *GraphiteMergeTree yang penggabungannya akan mengosongkan ruang cakera. Satu-satunya perkara yang perlu dilakukan ialah melalui mereka semua dengan permintaan OPTIMIZE ... FINAL. Pelaksanaan akhir juga mengambil kira hakikat bahawa tidak perlu menyentuh partition dengan rakaman aktif.

Inilah yang dilakukan oleh projek itu pengoptimum grafit-ch. Bekas rakan sekerja dari Yandex.Market mencubanya dalam pengeluaran, hasil kerja dapat dilihat di bawah.

Jika anda menjalankan program pada pelayan dengan ClickHouse, ia hanya akan mula berfungsi dalam mod daemon. Sekali sejam permintaan akan dilaksanakan, menyemak sama ada partition baharu yang lebih lama daripada tiga hari telah muncul yang boleh dioptimumkan.

Rancangan segera kami adalah untuk menyediakan sekurang-kurangnya pakej deb, dan jika boleh juga rpm.

Daripada kesimpulan

Sepanjang 9+ bulan yang lalu saya telah berada di dalam syarikat saya Permainan Inno menghabiskan banyak masa bermain-main di persimpangan ClickHouse dan grafit-web. Ia merupakan pengalaman yang baik, yang menghasilkan peralihan pantas daripada bisikan kepada ClickHouse sebagai storan metrik. Saya berharap artikel ini merupakan permulaan siri tentang penambahbaikan yang telah kami lakukan pada pelbagai bahagian tindanan ini dan perkara yang akan dilakukan pada masa hadapan.

Beberapa liter bir dan hari pentadbir dihabiskan untuk membangunkan permintaan itu, bersama-sama dengan v0syaitan, yang mana saya ingin mengucapkan terima kasih kepada beliau. Dan juga untuk menyemak artikel ini.

Halaman projek pada github

Sumber: www.habr.com