ClickHouse + ग्रेफाइट: डिस्क स्थान की खपत को काफी कम करने के लिए कैसे

नमस्ते।

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

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

उपभोग की समस्याएं

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

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

• एक डेटा डाला जाता है। हमारे मामले में, मैट्रिक्स आ गए हैं।
  
• डिस्क लिखने से पहले प्रत्येक ऐसे ब्लॉक को तालिका बनाते समय निर्दिष्ट की ORDER BY अनुसार क्रमबद्ध किया जाता है।
• सॉर्ट करने के बाद, डेटा का एक डिस्क पर लिखा जाता है।
  
• सर्वर पृष्ठभूमि में मॉनिटर करता है कि ऐसे कई टुकड़े नहीं हैं, और पृष्ठभूमि ( merge , इसके बाद मर्ज) शुरू होता है।
  
  
• जैसे ही डेटा सक्रिय रूप partition , सर्वर अपने आप ही मर्ज करना बंद कर देता है, लेकिन आप OPTIMIZE कमांड से मैन्युअल रूप से प्रक्रिया शुरू कर सकते हैं।
• यदि विभाजन में केवल एक टुकड़ा बचा है, तो आप सामान्य कमांड के साथ मर्ज शुरू नहीं कर सकते, आपको OPTIMIZE ... FINAL उपयोग करना होगा

तो, पहले मेट्रिक्स आते हैं। और वे एक निश्चित स्थान पर कब्जा कर लेते हैं। कई कारकों के आधार पर बाद की घटनाएं थोड़ी भिन्न हो सकती हैं:

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

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

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

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

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

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

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

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

• DB नाम ( 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 

* ग्रेफाइटमेजरट्री टेबल के प्रत्येक विभाजन को लौटाता है जिसका विलय डिस्क स्थान को खाली करना चाहिए। यह सब छोड़ दिया जाना छोटी बात है: उन सभी के साथ OPTIMIZE ... FINAL अनुरोध पर जाएं। अंतिम कार्यान्वयन ने इस क्षण को भी ध्यान में रखा कि एक सक्रिय रिकॉर्ड के साथ विभाजन को छूने की कोई आवश्यकता नहीं है।

यह वही है जो ग्रेफाइट-च-आशावादी परियोजना करता है। Yandex.Market के पूर्व सहयोगियों ने ठेस में इसका परीक्षण किया, काम का परिणाम नीचे देखा जा सकता है।

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

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

UPD: पैकेज github रिलीज़ पर उपलब्ध हैं, और काम करने वाले चित्र innogames / ग्रेफाइट-ch- ऑप्टिमाइज़र रिपॉजिटरी में docker-hub पर पाए जा सकते हैं।

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

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

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

प्रोजेक्ट पेज github पर