क्लिकहाऊस + ग्रेफाइट: डिस्क स्पेसचा वापर लक्षणीयरीत्या कसा कमी करायचा

शुभेच्छा, नमस्कार.

जर कोणी व्यवस्थेचे शोषण करत असेल ग्रेफाइट-वेब आणि स्टोरेज कार्यप्रदर्शन समस्या आली कुजबुजणे (IO, डिस्क स्पेस वापरण्यात आली), नंतर क्लिकहाऊसला बदली म्हणून कास्ट केले जाण्याची शक्यता एकाकडे असते. हे विधान सूचित करते की तृतीय-पक्ष अंमलबजावणी आधीच डिमन प्राप्त करणारे मेट्रिक्स म्हणून वापरली जाते, उदाहरणार्थ कार्बन रायटर किंवा गो-कार्बन.

क्लिकहाऊस वर्णन केलेल्या समस्या चांगल्या प्रकारे सोडवते. उदाहरणार्थ, व्हिस्परमधून 2TiB डेटा हस्तांतरित केल्यानंतर, ते 300GiB मध्ये बसतात. मी तपशीलवार तुलना करणार नाही; या विषयावर भरपूर लेख आहेत. याव्यतिरिक्त, अलीकडे पर्यंत, आमच्या क्लिकहाऊस स्टोरेजसह सर्वकाही परिपूर्ण नव्हते.

वापरलेल्या जागेसह समस्या

पहिल्या दृष्टीक्षेपात, सर्वकाही चांगले कार्य केले पाहिजे. खालील दस्तऐवजीकरण, मेट्रिक्स स्टोरेज स्कीमसाठी एक कॉन्फिगरेशन तयार करा (पुढे retention), नंतर ग्रेफाइट-वेबसाठी निवडलेल्या बॅकएंडच्या शिफारसीनुसार एक टेबल तयार करा: कार्बन-क्लिकहाऊस+ग्रेफाइट-क्लिकहाऊस किंवा graphouse, कोणता स्टॅक वापरला जातो यावर अवलंबून. आणि... टाइम बॉम्ब निघून जातो.

कोणते हे समजून घेण्यासाठी, तुम्हाला * कुटुंबाच्या इंजिनच्या सारण्यांमध्ये इन्सर्ट कसे कार्य करतात आणि डेटाचा पुढील जीवन मार्ग माहित असणे आवश्यक आहे.MergeTree क्लिकहाऊस (वरून घेतलेले चार्ट सादरीकरणे अॅलेक्सी झाटेलपिन):

• घातले блок डेटा आमच्या बाबतीत, हे मेट्रिक्स आले होते.
  
• अशा प्रत्येक ब्लॉकची डिस्कवर लिहिण्यापूर्वी की नुसार क्रमवारी लावली जाते. ORDER BYटेबल तयार करताना निर्दिष्ट केले आहे.
• वर्गीकरण केल्यानंतर, кусок (part) डेटा डिस्कवर लिहिला जातो.
  
• सर्व्हर पार्श्वभूमीत मॉनिटर करतो जेणेकरून असे बरेच तुकडे नाहीत आणि पार्श्वभूमी लाँच करते слияния (merge, यानंतर विलीन करा).
  
  
• मध्ये डेटा सक्रियपणे वाहणे थांबताच सर्व्हर स्वतःच विलीनीकरण चालू करणे थांबवतो партицию (partition), परंतु तुम्ही कमांडसह प्रक्रिया व्यक्तिचलितपणे सुरू करू शकता OPTIMIZE.
• जर विभाजनामध्ये फक्त एक तुकडा शिल्लक असेल, तर तुम्ही नेहमीच्या कमांडचा वापर करून मर्ज चालवू शकणार नाही; तुम्ही वापरणे आवश्यक आहे. OPTIMIZE ... FINAL

तर, प्रथम मेट्रिक्स येतात. आणि ते काही जागा घेतात. त्यानंतरच्या घटना अनेक घटकांवर अवलंबून काही प्रमाणात बदलू शकतात:

• विभाजन की एकतर खूप लहान (एक दिवस) किंवा खूप मोठी (अनेक महिने) असू शकते.
• रिटेन्शन कॉन्फिगरेशन सक्रिय विभाजनामध्ये (जेथे मेट्रिक्स रेकॉर्ड केले जातात) अनेक महत्त्वपूर्ण डेटा एकत्रीकरण थ्रेशोल्डमध्ये बसू शकतात किंवा कदाचित नाही.
• जर भरपूर डेटा असेल, तर सर्वात जुने भाग, जे पार्श्वभूमी विलीनीकरणामुळे आधीच खूप मोठे असू शकतात (जर तुम्ही नॉन-इष्टतम विभाजन की निवडल्यास), ते ताज्या लहान तुकड्यांमध्ये विलीन होणार नाहीत.

आणि तो नेहमी सारखाच संपतो. ClickHouse मधील मेट्रिक्सने व्यापलेली जागा फक्त तेव्हाच वाढते जेव्हा:

• लागू करू नका OPTIMIZE ... FINAL व्यक्तिचलितपणे किंवा
• सततच्या आधारावर सर्व विभाजनांमध्ये डेटा समाविष्ट करू नका, जेणेकरून लवकरच किंवा नंतर पार्श्वभूमी एकत्रीकरण सुरू होईल

दुसरी पद्धत अंमलात आणण्यासाठी सर्वात सोपी आहे असे दिसते आणि म्हणूनच, ती चुकीची आहे आणि प्रथम प्रयत्न केला गेला.
मी एक अगदी सोपी पायथन स्क्रिप्ट लिहिली जी गेल्या 4 वर्षांपासून प्रत्येक दिवसासाठी डमी मेट्रिक्स पाठवते आणि प्रत्येक तासाला क्रॉन चालवते.
क्लिकहाऊस डीबीएमएसचे संपूर्ण ऑपरेशन या वस्तुस्थितीवर आधारित आहे की ही प्रणाली लवकरच किंवा नंतर सर्व पार्श्वभूमी कार्य करेल, परंतु हे माहित नाही की जुने मोठे तुकडे कधी विलीन होतील त्या क्षणाची प्रतीक्षा करण्यास मी अक्षम होतो. नवीन लहान. हे स्पष्ट झाले की आम्हाला सक्तीने ऑप्टिमायझेशन स्वयंचलित करण्याचा मार्ग शोधण्याची आवश्यकता आहे.

क्लिकहाऊस सिस्टम टेबलमधील माहिती

चला टेबलच्या संरचनेवर एक नजर टाकूया प्रणाली.भाग. क्लिकहाऊस सर्व्हरवरील सर्व सारण्यांच्या प्रत्येक तुकड्याची ही सर्वसमावेशक माहिती आहे. इतर गोष्टींबरोबरच, खालील स्तंभांचा समावेश आहे:

• db नाव (database);
• टेबल नाव (table);
• विभाजनाचे नाव आणि आयडी (partition & partition_id);
• जेव्हा तुकडा तयार झाला (modification_time);
• एका तुकड्यात किमान आणि कमाल तारीख (विभाजन दिवसानुसार केले जाते) (min_date & max_date);

एक टेबल देखील आहे system.graphite_retentions, खालील मनोरंजक फील्डसह:

• db नाव (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. अंतिम अंमलबजावणी हे तथ्य देखील लक्षात घेते की सक्रिय रेकॉर्डिंगसह विभाजनांना स्पर्श करण्याची आवश्यकता नाही.

प्रकल्प नेमके हेच करतो ग्रेफाइट-सीएच-ऑप्टिमायझर. Yandex.Market मधील माजी सहकाऱ्यांनी उत्पादनात याचा प्रयत्न केला, कामाचा परिणाम खाली पाहिला जाऊ शकतो.

तुम्ही क्लिकहाऊससह सर्व्हरवर प्रोग्राम चालवल्यास, ते फक्त डिमन मोडमध्ये कार्य करण्यास प्रारंभ करेल. एक तासाने एकदा विनंती कार्यान्वित केली जाईल, तीन दिवसांपेक्षा जुनी नवीन विभाजने ऑप्टिमाइझ करता येतील का ते तपासत आहे.

आमची तात्काळ योजना किमान डेब पॅकेजेस आणि शक्य असल्यास आरपीएम प्रदान करण्याच्या आहेत.

त्याऐवजी एक निष्कर्ष

गेल्या 9+ महिन्यांत मी माझ्या कंपनीत आहे इनोगेम्स क्लिकहाऊस आणि ग्रेफाइट-वेबच्या छेदनबिंदूवर टिंकर करण्यात बराच वेळ घालवला. हा एक चांगला अनुभव होता, ज्याचा परिणाम मेट्रिक्स स्टोरेज म्हणून व्हिस्परमधून क्लिकहाऊसमध्ये द्रुत संक्रमण झाला. मला आशा आहे की हा लेख या स्टॅकच्या विविध भागांमध्ये आम्ही कोणत्या सुधारणा केल्या आहेत आणि भविष्यात काय केले जाईल याबद्दलच्या मालिकेची सुरुवात आहे.

विनंती विकसित करण्यासाठी अनेक लीटर बिअर आणि प्रशासन दिवस खर्च केले गेले v0devil, ज्यासाठी मी त्यांचे आभार व्यक्त करू इच्छितो. आणि या लेखाचे पुनरावलोकन करण्यासाठी देखील.

गिथब वर प्रकल्प पृष्ठ

स्त्रोत: www.habr.com