ClickHouse + Graphite: როგორ მნიშვნელოვნად შევამციროთ დისკის სივრცის მოხმარება

გამარჯობა, ჰაბრ.

თუ ვინმე იყენებს სისტემას გრაფიტი-ვებე და შეექმნა შენახვის მუშაობის პრობლემა ჩურჩული (IO, დისკზე მოხმარებული ადგილი), მაშინ იმის შანსი, რომ ClickHouse ჩანაცვლების სახით იქნა მიცემული, ერთი უნდა იყოს. ეს განცხადება გულისხმობს, რომ მესამე მხარის იმპლემენტაცია უკვე გამოიყენება, როგორც დემონის მიმღები მეტრიკა, მაგალითად კარბონაწერი ან go-carbon.

ClickHouse კარგად წყვეტს აღწერილ პრობლემებს. მაგალითად, ჩურჩულიდან 2TiB მონაცემების გადაცემის შემდეგ ისინი ჯდება 300GiB-ში. შედარებაზე დეტალურად არ შევჩერდები, ამ თემაზე უამრავი სტატიაა. გარდა ამისა, ბოლო დრომდე, ყველაფერი არ იყო სრულყოფილი ჩვენს ClickHouse საცავში.

პრობლემები მოხმარებულ სივრცეში

ერთი შეხედვით, ყველაფერი კარგად უნდა მუშაობდეს. მიჰყვება დოკუმენტაცია, შექმენით კონფიგურაცია მეტრიკის შენახვის სქემისთვის (შემდეგ retention), შემდეგ შექმენით ცხრილი შერჩეული ბექენდის რეკომენდაციის მიხედვით გრაფიტ-ვებისთვის: carbon-clickhouse+გრაფიტი-კლიკჰაუსი ან გრაფუსი, იმის მიხედვით, თუ რომელი დასტა გამოიყენება. და... დროის ბომბი იშლება.

იმისათვის, რომ გაიგოთ რომელი, თქვენ უნდა იცოდეთ როგორ მუშაობს ჩანართები და მონაცემთა შემდგომი ცხოვრების გზა * ოჯახის ძრავების ცხრილებში.MergeTree ClickHouse (სქემები აღებულია პრეზენტაციები ალექსეი ზატელეპინი):

• ჩასმულია блок მონაცემები. ჩვენს შემთხვევაში, ეს იყო მეტრიკა, რომელიც მოვიდა.
  
• თითოეული ასეთი ბლოკი დალაგებულია გასაღების მიხედვით დისკზე ჩაწერამდე. ORDER BYმითითებული ცხრილის შექმნისას.
• დახარისხების შემდეგ, кусок (part) მონაცემები იწერება დისკზე.
  
• სერვერი აკვირდება ფონზე ისე, რომ ბევრი ასეთი ნაწილი არ იყოს და გაუშვებს ფონს слияния (merge, შემდგომში შერწყმა).
  
  
• სერვერი თავისთავად წყვეტს შერწყმას, როგორც კი მონაცემები შეწყვეტს მასში აქტიურ ნაკადს партицию (partition), მაგრამ თქვენ შეგიძლიათ დაიწყოთ პროცესი ხელით ბრძანებით OPTIMIZE.
• თუ დანაყოფში დარჩა მხოლოდ ერთი ნაწილი, მაშინ ვერ შეძლებთ შერწყმის გაშვებას ჩვეულებრივი ბრძანების გამოყენებით; თქვენ უნდა გამოიყენოთ OPTIMIZE ... FINAL

ასე რომ, პირველი მეტრიკა მოდის. და ისინი იკავებენ გარკვეულ ადგილს. შემდგომი მოვლენები შეიძლება გარკვეულწილად განსხვავდებოდეს მრავალი ფაქტორიდან გამომდინარე:

• დანაყოფის გასაღები შეიძლება იყოს ძალიან მცირე (დღეში) ან ძალიან დიდი (რამდენიმე თვე).
• შენახვის კონფიგურაცია შეიძლება შეესაბამებოდეს რამდენიმე მნიშვნელოვან მონაცემთა აგრეგაციის ზღურბლს აქტიურ დანაყოფში (სადაც მეტრიკა არის ჩაწერილი), ან შეიძლება არა.
• თუ ბევრი მონაცემია, მაშინ ყველაზე ადრეული ნაწილაკები, რომლებიც ფონის შერწყმის გამო შეიძლება უკვე დიდი იყოს (თუ აირჩევთ არაოპტიმალური დანაყოფის გასაღებს), არ გაერთიანდება ახალ პატარა ნაწილებთან.

და ყოველთვის ერთნაირად მთავრდება. ClickHouse-ში მეტრიკის მიერ დაკავებული სივრცე იზრდება მხოლოდ იმ შემთხვევაში, თუ:

• არ ვრცელდება OPTIMIZE ... FINAL ხელით ან
• არ ჩადოთ მონაცემები ყველა დანაყოფში მუდმივად, რათა ადრე თუ გვიან დაიწყოს ფონის შერწყმა

მეორე მეთოდი, როგორც ჩანს, უმარტივესად განსახორციელებელია და, შესაბამისად, ის არასწორია და პირველ რიგში სცადეს.
მე დავწერე საკმაოდ მარტივი პითონის სკრიპტი, რომელიც აგზავნიდა ცრუ მეტრებს ყოველ დღე ბოლო 4 წლის განმავლობაში და ვაწარმოებდი cron-ს ყოველ საათში.
ვინაიდან ClickHouse DBMS-ის მთელი მოქმედება ემყარება იმ ფაქტს, რომ ეს სისტემა ადრე თუ გვიან შეასრულებს ყველა ფონურ მუშაობას, მაგრამ უცნობია როდის, მე ვერ დაველოდე იმ მომენტს, როდესაც ძველი უზარმაზარი ნაწილები შერწყმას დაიწყებდა. ახალი პატარები. ცხადი გახდა, რომ ჩვენ გვჭირდებოდა იძულებითი ოპტიმიზაციის ავტომატიზაციის გზა.

ინფორმაცია ClickHouse სისტემის ცხრილებში

მოდით შევხედოთ ცხრილის სტრუქტურას სისტემა.ნაწილები. ეს არის ყოვლისმომცველი ინფორმაცია ClickHouse სერვერზე ყველა ცხრილის თითოეული ნაწილის შესახებ. შეიცავს, სხვა საკითხებთან ერთად, შემდეგ სვეტებს:

• დბ სახელი (database);
• მაგიდის სახელი (table);
• დანაყოფის სახელი და ID (partition & partition_id);
• როდესაც ცალი შეიქმნა (modification_time);
• მინიმალური და მაქსიმალური თარიღი ცალი (დაყოფა ხდება დღისით) (min_date & max_date);

ასევე არის მაგიდა სისტემა.გრაფიტის_შეკავება, შემდეგი საინტერესო ველებით:

• დბ სახელი (Tables.database);
• მაგიდის სახელი (Tables.table);
• მეტრული ასაკი, როდის უნდა იქნას გამოყენებული შემდეგი აგრეგაცია (age);

ასე რომ:

1. ჩვენ გვაქვს ნაწილაკების ცხრილი და აგრეგაციის წესების ცხრილი.
2. ჩვენ ვაკავშირებთ მათ კვეთას და ვიღებთ ყველა ცხრილს *GraphiteMergeTree.
3. ჩვენ ვეძებთ ყველა დანაყოფს, რომელშიც:
   • ერთზე მეტი ცალი
   • ან დადგა მორიგი აგრეგაციის წესის გამოყენების დრო და modification_time უფრო ძველი ვიდრე ამ მომენტში.

Реализация

ეს თხოვნა

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 ცხრილის თითოეულ დანაყოფს, რომელთა შერწყმამ უნდა გაათავისუფლოს ადგილი დისკზე. ერთადერთი, რაც გასაკეთებელია, არის ყველა მათგანის თხოვნით გავლა OPTIMIZE ... FINAL. საბოლოო განხორციელება ასევე ითვალისწინებს იმ ფაქტს, რომ არ არის საჭირო ტიხრების შეხება აქტიური ჩანაწერით.

ეს არის ზუსტად ის, რასაც პროექტი აკეთებს graphite-ch-optimizer. Yandex.Market-ის ყოფილმა კოლეგებმა სცადეს ის წარმოებაში, მუშაობის შედეგი შეგიძლიათ იხილოთ ქვემოთ.

თუ პროგრამას სერვერზე ClickHouse-ით გაუშვით, ის უბრალოდ დაიწყებს მუშაობას დემონის რეჟიმში. საათში ერთხელ შესრულდება მოთხოვნა, შემოწმდება თუ არა გამოჩნდა სამ დღეზე ძველი ტიხრები, რომელთა ოპტიმიზაცია შესაძლებელია.

ჩვენი უახლოესი გეგმებია მინიმუმ დებ პაკეტების მიწოდება და, თუ შესაძლებელია, ასევე rpm.

იმის ნაცვლად, რომ დასკვნა

ბოლო 9+ თვის განმავლობაში მე ვიყავი ჩემს კომპანიაში innogames დიდი დრო გაატარა ClickHouse-ისა და graphite-web-ის კვეთაზე. ეს იყო კარგი გამოცდილება, რამაც გამოიწვია სწრაფი გადასვლა ჩურჩულიდან ClickHouse-ზე, როგორც მეტრიკის შესანახად. ვიმედოვნებ, რომ ეს სტატია არის სერიის დასაწყისი იმის შესახებ, თუ რა გაუმჯობესებები განვახორციელეთ ამ სტეკის სხვადასხვა ნაწილში და რა გაკეთდება მომავალში.

მოთხოვნის შემუშავებაზე რამდენიმე ლიტრი ლუდი და ადმინისტრაციული დღე დაიხარჯა v0ეშმაკირისთვისაც მინდა მადლობა გადავუხადო მას. და ასევე ამ სტატიის განხილვისთვის.

პროექტის გვერდი github-ზე

წყარო: www.habr.com