ClickHouse + Graphite: कसरी उल्लेखनीय रूपमा डिस्क स्पेस खपत कम गर्ने

नमस्कार, नमस्कार।

यदि कसैले प्रणालीको शोषण गर्छ ग्रेफाइट-वेब र भण्डारण कार्यसम्पादन समस्याको सामना गर्यो लेकानेखुसीगर्छ (IO, डिस्क स्पेस खपत), त्यसपछि क्लिकहाउस प्रतिस्थापनको रूपमा कास्ट गरिएको मौका एक हुनुपर्दछ। यो कथनले संकेत गर्छ कि तेस्रो-पक्ष कार्यान्वयन पहिले नै डेमन प्राप्त मेट्रिक्सको रूपमा प्रयोग गरिएको छ, उदाहरणका लागि कार्बन लेखक वा गो-कार्बन.

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

खपत भएको ठाउँको समस्या

पहिलो नजर मा, सबै राम्रो काम गर्नुपर्छ। पछ्याउँदै कागजात, मेट्रिक्स भण्डारण योजनाको लागि कन्फिगरेसन सिर्जना गर्नुहोस् (थप retention), त्यसपछि ग्रेफाइट-वेबको लागि चयन गरिएको ब्याकइन्डको सिफारिस अनुसार तालिका सिर्जना गर्नुहोस्: कार्बन क्लिकहाउस+ग्रेफाइट क्लिकहाउस वा graphouse, कुन स्ट्याक प्रयोग गरिन्छ मा निर्भर गर्दछ। र ... टाइम बम निस्कन्छ।

कुन कुन बुझ्नको लागि, तपाइँले जान्न आवश्यक छ कि कसरी सम्मिलित गर्दछ र * परिवारको इन्जिनहरूको तालिकामा डेटाको थप जीवन मार्ग।मर्जट्री क्लिकहाउस (चार्टहरूबाट लिइएको प्रस्तुतिकरण एलेक्सी जेतेलेपिन):

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

त्यसोभए, पहिलो मेट्रिक्स आइपुग्छ। र तिनीहरूले केही ठाउँ लिन्छन्। पछिका घटनाहरू धेरै कारकहरूमा निर्भर गर्दै केही फरक हुन सक्छन्:

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

र यो सधैं उस्तै समाप्त हुन्छ। ClickHouse मा मेट्रिक्स द्वारा ओगटेको ठाउँ मात्र बढ्छ यदि:

• लागू नगर्नुहोस् OPTIMIZE ... FINAL म्यानुअल रूपमा वा
• निरन्तर आधारमा सबै विभाजनहरूमा डाटा घुसाउनुहोस्, ताकि ढिलो वा पछि पृष्ठभूमि मर्ज सुरु हुनेछ।

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

ClickHouse प्रणाली तालिकाहरूमा जानकारी

तालिकाको संरचनालाई हेरौं प्रणाली भागहरू। यो ClickHouse सर्भरमा सबै तालिकाहरूको प्रत्येक टुक्राको बारेमा विस्तृत जानकारी हो। समावेश गर्दछ, अन्य चीजहरू बीच, निम्न स्तम्भहरू:

• 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 बाट पूर्व सहकर्मीहरूले यसलाई उत्पादनमा प्रयास गरे, कामको नतिजा तल देख्न सकिन्छ।

यदि तपाइँ क्लिकहाउसको साथ सर्भरमा कार्यक्रम चलाउनुहुन्छ भने, यसले केवल डेमन मोडमा काम गर्न सुरु गर्नेछ। एक घण्टामा एक पटक अनुरोध कार्यान्वयन गरिनेछ, तीन दिन भन्दा पुरानो नयाँ विभाजनहरू देखा परेको छ कि भनेर जाँच गर्दै जुन अनुकूलित गर्न सकिन्छ।

हाम्रो तत्काल योजनाहरू कम्तिमा deb प्याकेजहरू प्रदान गर्ने हो, र सम्भव भएमा rpm पनि।

बरु एक निष्कर्षमा को

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

धेरै लीटर बियर र प्रशासक दिनहरू सँगै अनुरोध विकास गर्न खर्च गरियो v0devilजसको लागि म उहाँप्रति कृतज्ञता व्यक्त गर्न चाहन्छु। र यो लेख समीक्षाको लागि पनि।

Github मा परियोजना पृष्ठ

स्रोत: www.habr.com