क्लिकहाउस + ग्रेफाइट: डिस्क स्थान की खपत को उल्लेखनीय रूप से कैसे कम करें

नमस्ते, हबर।

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

ClickHouse वर्णित समस्याओं को अच्छी तरह हल करता है। उदाहरण के लिए, व्हिस्पर से 2TiB डेटा स्थानांतरित करने के बाद, वे 300GiB में फिट हो जाते हैं। मैं तुलना पर विस्तार से ध्यान नहीं दूंगा; इस विषय पर बहुत सारे लेख हैं। इसके अलावा, हाल तक, हमारे ClickHouse स्टोरेज के साथ सब कुछ सही नहीं था।

उपभोग की गई जगह के साथ समस्याएँ

पहली नज़र में, सब कुछ ठीक से काम करना चाहिए। अगले प्रलेखन, मेट्रिक्स भंडारण योजना के लिए एक कॉन्फ़िगरेशन बनाएं (आगे)। retention), फिर ग्रेफाइट-वेब के लिए चयनित बैकएंड की अनुशंसा के अनुसार एक तालिका बनाएं: कार्बन-क्लिकहाउस+ग्रेफाइट-क्लिकहाउस या ग्राफ़हाउस, इस पर निर्भर करता है कि किस स्टैक का उपयोग किया जाता है। और... टाइम बम फट जाता है।

यह समझने के लिए कि आपको यह जानना होगा कि इंसर्ट कैसे काम करते हैं और * परिवार के इंजनों की तालिकाओं में डेटा का आगे का जीवन पथ क्या हैमर्जट्री क्लिकहाउस (चार्ट से लिया गया प्रस्तुतियों एलेक्सी ज़ेटेलेपिन):

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

तो, पहले मेट्रिक्स आते हैं। और वे कुछ जगह घेर लेते हैं. बाद की घटनाएं कई कारकों के आधार पर कुछ हद तक भिन्न हो सकती हैं:

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

और इसका अंत हमेशा एक जैसा ही होता है. ClickHouse में मेट्रिक्स द्वारा कब्जा किया गया स्थान केवल तभी बढ़ता है यदि:

• लागू नहीं होता है OPTIMIZE ... FINAL मैन्युअल रूप से या
• सभी विभाजनों में निरंतर आधार पर डेटा न डालें, ताकि देर-सबेर पृष्ठभूमि मर्ज शुरू हो जाए

दूसरी विधि लागू करने में सबसे आसान लगती है और इसलिए, यह गलत है और इसे पहले आज़माया गया था।
मैंने एक काफी सरल पायथन स्क्रिप्ट लिखी जो पिछले 4 वर्षों से हर दिन के लिए डमी मेट्रिक्स भेजती थी और हर घंटे क्रॉन चलाती थी।
चूँकि ClickHouse DBMS का संपूर्ण संचालन इस तथ्य पर आधारित है कि यह सिस्टम देर-सबेर सभी पृष्ठभूमि कार्य करेगा, लेकिन यह ज्ञात नहीं है कि कब, मैं उस क्षण का इंतजार करने में असमर्थ था जब पुराने विशाल टुकड़े विलय शुरू करने के लिए तैयार होंगे नये छोटे. यह स्पष्ट हो गया कि हमें जबरन अनुकूलन को स्वचालित करने का एक तरीका तलाशने की जरूरत है।

ClickHouse सिस्टम तालिकाओं में जानकारी

आइए तालिका संरचना पर एक नज़र डालें सिस्टम.पार्ट्स. यह ClickHouse सर्वर पर सभी तालिकाओं के प्रत्येक टुकड़े के बारे में व्यापक जानकारी है। अन्य बातों के अलावा, निम्नलिखित कॉलम शामिल हैं:

• डीबी नाम (database);
• तालिका नाम (table);
• विभाजन का नाम और आईडी (partition & partition_id);
• जब टुकड़ा बनाया गया था (modification_time);
• एक टुकड़े में न्यूनतम और अधिकतम तिथि (विभाजन दिन के अनुसार किया जाता है) (min_date & max_date);

एक टेबल भी है system.graphite_retentions, निम्नलिखित दिलचस्प क्षेत्रों के साथ:

• डीबी नाम (Tables.database);
• तालिका नाम (Tables.table);
• मीट्रिक आयु जब अगला एकत्रीकरण लागू किया जाना चाहिए (age);

तो:

1. हमारे पास टुकड़ों की एक तालिका और एकत्रीकरण नियमों की एक तालिका है।
2. हम उनके प्रतिच्छेदन को जोड़ते हैं और सभी तालिकाएँ *ग्रेफाइटमर्जट्री प्राप्त करते हैं।
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. अंतिम कार्यान्वयन इस तथ्य को भी ध्यान में रखता है कि सक्रिय रिकॉर्डिंग के साथ विभाजन को छूने की कोई आवश्यकता नहीं है।

प्रोजेक्ट बिल्कुल यही करता है ग्रेफाइट-ch-अनुकूलक. Yandex.Market के पूर्व सहयोगियों ने इसे उत्पादन में आज़माया, कार्य का परिणाम नीचे देखा जा सकता है।

यदि आप प्रोग्राम को ClickHouse वाले सर्वर पर चलाते हैं, तो यह बस डेमॉन मोड में काम करना शुरू कर देगा। एक घंटे में एक बार अनुरोध निष्पादित किया जाएगा, यह जाँच की जाएगी कि क्या तीन दिन से अधिक पुराने नए विभाजन सामने आए हैं जिन्हें अनुकूलित किया जा सकता है।

हमारी तत्काल योजना कम से कम डिबेट पैकेज और यदि संभव हो तो आरपीएम भी प्रदान करने की है।

इसके बजाय एक निष्कर्ष की

पिछले 9+ महीनों से मैं अपनी कंपनी के अंदर हूं InnoGames ClickHouse और ग्रेफ़ाइट-वेब के चौराहे पर बहुत समय बिताया। यह एक अच्छा अनुभव था, जिसके परिणामस्वरूप मेट्रिक्स स्टोरेज के रूप में व्हिस्पर से क्लिकहाउस में त्वरित परिवर्तन हुआ। मुझे आशा है कि यह लेख एक शृंखला की शुरुआत है कि हमने इस स्टैक के विभिन्न हिस्सों में क्या सुधार किए हैं, और भविष्य में क्या किया जाएगा।

अनुरोध को विकसित करने में कई लीटर बियर और व्यवस्थापक दिवस एक साथ खर्च किए गए v0शैतानजिसके लिए मैं उनका आभार व्यक्त करना चाहता हूं. और इस लेख की समीक्षा के लिए भी.

जीथब पर प्रोजेक्ट पेज

स्रोत: www.habr.com