यैंडेक्स में निरंतर एकीकरण। भाग २

पिछले लेख में, हमने विधानसभा, परीक्षण, तैनाती और निगरानी के लिए एकीकृत प्रणालियों के साथ विकास के लिए ट्रंक-आधारित दृष्टिकोण के साथ एकल रिपॉजिटरी में विकास को स्थानांतरित करने के बारे में बात की थी, इस तरह की स्थितियों में प्रभावी ढंग से काम करने के लिए एक सतत एकीकरण प्रणाली को किन कार्यों को हल करना चाहिए।

आज हम Habr पाठकों को निरंतर एकीकरण प्रणाली के उपकरण के बारे में बताएंगे।

एक निरंतर एकीकरण प्रणाली को मज़बूती से और तेज़ी से काम करना चाहिए। सिस्टम को आने वाली घटनाओं के लिए जल्दी से जवाब देना चाहिए और उपयोगकर्ता को परीक्षण रन परिणाम देने की प्रक्रिया में अतिरिक्त देरी का परिचय नहीं देना चाहिए। असेंबली और परीक्षण के परिणामों को वास्तविक समय में उपयोगकर्ता तक पहुंचाया जाना चाहिए।

निरंतर एकीकरण प्रणाली न्यूनतम विलंब के साथ एक स्ट्रीमिंग डेटा प्रोसेसिंग सिस्टम है।

सभी परिणाम एक निश्चित चरण (कॉन्फ़िगर, बिल्ड, स्टाइल, छोटे परीक्षण, मध्यम परीक्षण, आदि) पर भेजने के बाद, निर्माण प्रणाली इसे निरंतर एकीकरण प्रणाली ("मंच" बंद ") के लिए संकेत देती है, और उपयोगकर्ता देखता है कि इस जाँच के लिए और इस स्तर पर सभी परिणाम ज्ञात हैं। प्रत्येक चरण स्वतंत्र रूप से बंद हो जाता है। उपयोगकर्ता तेजी से एक उपयोगी संकेत प्राप्त करता है। सभी चरणों को बंद करने के बाद, चेक को पूर्ण माना जाता है।

प्रणाली को लागू करने के लिए, हमने कप्पा वास्तुकला को चुना। सिस्टम में 2 सबसिस्टम होते हैं:

• घटना और डेटा प्रसंस्करण एक रीयलटाइम सर्किट में होता है। किसी भी इनपुट डेटा को डेटा स्ट्रीम (स्ट्रीम) के रूप में माना जाता है। सबसे पहले, घटनाओं को धारा में दर्ज किया जाता है और उसके बाद ही उन्हें संसाधित किया जाता है।
• डेटा प्रोसेसिंग के परिणाम लगातार डेटाबेस को लिखे जाते हैं, जहां एपीआई के माध्यम से कॉल किया जाता है। कप्पा वास्तुकला में, इसे सेवारत परत कहा जाता है।

डेटा संशोधन के लिए सभी अनुरोधों को रीयलटाइम सर्किट के माध्यम से जाना चाहिए, क्योंकि आपको हमेशा सिस्टम की वर्तमान स्थिति की आवश्यकता होती है। पढ़ें अनुरोध केवल डेटाबेस पर जाएं।

जहाँ भी संभव हो, हम परिशिष्ट-केवल नियम का पालन करते हैं। पुराने, अनावश्यक डेटा को हटाने के अपवाद के साथ वस्तुओं का कोई संशोधन या विलोपन नहीं।

प्रति दिन 2 टीबी से अधिक कच्चा डेटा सेवा से गुजरता है।

फायदे:

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

लेकिन डेटा प्रोसेसिंग स्ट्रीमिंग इतना आसान नहीं है:

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

स्ट्रीम प्रसंस्करण

परियोजना पर काम करते समय, स्ट्रीम प्रोसेसर लाइब्रेरी को लिखा गया था, जिसने हमें उत्पादन में डेटा प्रोसेसिंग एल्गोरिदम को जल्दी से लागू करने और लॉन्च करने में मदद की।

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

यह गारंटी है कि इनपुट स्ट्रीम के प्रत्येक संदेश को प्रत्येक प्रोसेसर से कम से कम एक बार (शब्दार्थ कम से कम एक बार) संसाधित किया जाएगा। यह भी गारंटी है कि सभी संदेश उसी क्रम में संसाधित किए जाएंगे, जिसमें वे इस स्ट्रीम में पहुंचे थे। ऐसा करने के लिए, स्ट्रीम प्रोसेसर को सभी कार्यशील सेवा नोड्स में वितरित किया जाता है, ताकि एक समय में प्रत्येक पंजीकृत प्रोसेसर के एक से अधिक उदाहरण काम न कर रहे हों।

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

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

स्ट्रीम स्टोरेज में डेटा के कॉम्पैक्ट स्टोरेज के लिए, स्ट्रीम में लिखने से पहले कुछ डेटा को सामान्य किया जाता है, अर्थात। संख्याओं में बदलो। प्रभावी संपीड़न एल्गोरिदम फिर संख्याओं (ऑब्जेक्ट पहचानकर्ताओं) पर लागू किया जा सकता है। संख्याओं को क्रमबद्ध किया जाता है, डेल्टास की गणना की जाती है, फिर ज़िगज़ैग एन्कोडिंग के साथ एन्कोडिंग और फिर संग्रहकर्ता द्वारा संपीड़न। डेटा प्रोसेसिंग सिस्टम स्ट्रीमिंग के लिए सामान्यीकरण बहुत मानक तकनीक नहीं है। लेकिन यह संपीड़न तकनीक बहुत प्रभावी है और सबसे अधिक लोड स्ट्रीम में डेटा की मात्रा लगभग 1,000 गुना कम हो जाती है।

प्रत्येक स्ट्रीम और प्रोसेसर के लिए, हम संदेश प्रसंस्करण के जीवन चक्र की निगरानी करते हैं: इनपुट स्ट्रीम में नए संदेशों की उपस्थिति, अप्रमाणित संदेशों की कतार का आकार, परिणामी स्ट्रीम को लिखने के लिए कतार का आकार, संदेश प्रसंस्करण समय और संदेश प्रसंस्करण के चरणों के अनुसार समय:

डेटा वेयरहाउस

डेटा प्रोसेसिंग स्ट्रीमिंग के परिणाम जल्द से जल्द उपयोगकर्ता के लिए उपलब्ध होने चाहिए। धाराओं से संसाधित डेटा को लगातार डेटाबेस में दर्ज किया जाना चाहिए, जहां आप फिर डेटा के लिए जा सकते हैं (उदाहरण के लिए, परीक्षण के परिणामों के साथ एक रिपोर्ट दिखाएं, परीक्षण का इतिहास दिखाएं)।

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

पहले, हम संसाधित डेटा संग्रहीत करने के लिए MySQL का उपयोग करते थे। हमने धीरे-धीरे डेटाबेस की क्षमताओं के खिलाफ आराम करना शुरू किया:

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

नए डेटा वेयरहाउस के उम्मीदवारों के रूप में, हमने कई विकल्पों पर विचार किया: PostgreSQL, MongoDB और ClickHouse सहित कई आंतरिक समाधान।

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

ClickHouse

हमने ClickHouse का विकल्प चुना। ClickHouse ऑनलाइन विश्लेषणात्मक क्वेरी प्रसंस्करण (OLAP) के लिए एक स्तंभ डेटाबेस प्रबंधन प्रणाली (DBMS) है।

ClickHouse पर स्विच करते हुए, हमने जानबूझकर अन्य DBMS द्वारा प्रदान किए गए कुछ अवसरों को छोड़ दिया, इसके लिए बहुत तेजी से विश्लेषणात्मक प्रश्नों और एक कॉम्पैक्ट डेटा वेयरहाउस के रूप में इसके लिए योग्य मुआवजे से अधिक प्राप्त किया।

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

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

सामान्यीकरण के साथ डेटा योजना कार्यात्मक नहीं है, इसके विपरीत, इसके लिए अनुरोधों के आधार पर डेटा को निरूपित करना बेहतर है। बड़ी संख्या में कॉलम के साथ "विस्तृत" टेबल बनाना बेहतर होता है। यह आइटम पिछले एक से भी संबंधित है, क्योंकि माध्यमिक अनुक्रमों की अनुपस्थिति कभी-कभी एक अलग प्राथमिक कुंजी का उपयोग करके तालिकाओं की प्रतियां बनाती है।

शास्त्रीय अर्थ में ClickHouse में UPDATE और DELETE नहीं है, लेकिन उनके अनुकरण की संभावना है।

डेटा को बड़े ब्लॉकों में डाला जाना चाहिए और बहुत बार नहीं (एक बार हर कुछ सेकंड में)। वास्तविक डेटा वॉल्यूम पर लाइन-बाय-लाइन डेटा लोडिंग वास्तव में निष्क्रिय है।

ClickHouse लेनदेन का समर्थन नहीं करता है; सिस्टम अंततः सुसंगत हो जाता है।

फिर भी, ClickHouse की कुछ विशेषताएं, अन्य DBMS के समान, इससे मौजूदा सिस्टम को स्थानांतरित करना आसान हो जाता है।

• ClickHouse SQL का उपयोग करता है, लेकिन थोड़े अंतर के साथ, OLAP सिस्टम के विशिष्ट प्रश्नों के लिए उपयोगी है। कुल कार्यों की एक शक्तिशाली प्रणाली है, ALL / Any JOIN, कार्यों में लंबोदर भाव और अन्य SQL एक्सटेंशन जो आपको लगभग किसी भी विश्लेषणात्मक क्वेरी को लिखने की अनुमति देते हैं।
• ClickHouse प्रतिकृति, कोरम रिकॉर्डिंग , कोरम पढ़ने का समर्थन करता है। विश्वसनीय डेटा संग्रहण के लिए एक कोरम लिखना आवश्यक है: INSERT तभी सफल होता है, जब ClickHouse किसी त्रुटि के बिना किसी प्रतिकृति के डेटा को लिखने में सक्षम था।

आप प्रलेखन में ClickHouse सुविधाओं के बारे में अधिक पढ़ सकते हैं।

ClickHouse के साथ काम करने की सुविधाएँ

प्राथमिक कुंजी और विभाजन कुंजी की पसंद।

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

हमारे मामले में, परीक्षण चलाने के लिए मुख्य टेबल मैट्रिक्स हैं। यह मान लेना तर्कसंगत है कि इस डेटा संरचना के साथ, कुंजियों का चयन किया जाना चाहिए ताकि उनमें से एक का बायपास क्रम पंक्ति संख्या बढ़ाने के क्रम में चला जाए, और दूसरे का बाईपास क्रम - कॉलम संख्या बढ़ाने के क्रम में।

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

विभाजन कुंजी के दो उद्देश्य हैं। एक ओर, यह विभाजनों को "संग्रहीत" होने की अनुमति देता है ताकि उन्हें भंडारण से स्थायी रूप से हटा दिया जा सके, क्योंकि उनमें डेटा पहले से पुराना है। दूसरी ओर, विभाजन कुंजी एक द्वितीयक सूचकांक है, जिसका अर्थ है कि यह आपको प्रश्नों को गति देने की अनुमति देता है यदि इसके लिए एक अभिव्यक्ति मौजूद है।

हमारे मैट्रिसेस के लिए, विभाजन कुंजी के रूप में कमिट संख्या चुनना काफी स्वाभाविक लगता है। लेकिन यदि आप विभाजन कुंजी के लिए अभिव्यक्ति में संशोधन मूल्य निर्धारित करते हैं, तो ऐसी तालिका में अनुचित रूप से कई विभाजन होंगे, जिससे प्रश्नों के प्रदर्शन में गिरावट आएगी। इसलिए, विभाजन कुंजी के लिए अभिव्यक्ति में, विभाजन की संख्या को कम करने के लिए संशोधन मूल्य को कुछ बड़ी संख्या में विभाजित किया जा सकता है, उदाहरण के लिए, PARTITION BY intDiv (संशोधन, 2000)। यह संख्या पर्याप्त रूप से बड़ी होनी चाहिए ताकि विभाजन की संख्या अनुशंसित मानों से अधिक न हो, जबकि यह पर्याप्त रूप से छोटा होना चाहिए ताकि बहुत से डेटा एक विभाजन में न पड़ें और डेटाबेस को बहुत अधिक डेटा नहीं पढ़ना पड़े।

UPDATE और DELETE कैसे लागू करें?

सामान्य अर्थ में, UPHATE और DELETE, ClickHouse में समर्थित नहीं हैं। हालाँकि, UPDATE और DELETE के बजाय, आप तालिका में एक संस्करण के साथ एक कॉलम जोड़ सकते हैं और विशेष ReplacingMergeTree इंजन का उपयोग कर सकते हैं (समान प्राथमिक कुंजी मान के साथ डुप्लिकेट रिकॉर्ड हटाता है)। कुछ मामलों में, संस्करण शुरू से ही स्वाभाविक रूप से तालिका में मौजूद होगा: उदाहरण के लिए, यदि हम परीक्षण की वर्तमान स्थिति के लिए एक तालिका बनाना चाहते हैं, तो इस तालिका में संस्करण प्रतिबद्ध संख्या होगी।

CREATE TABLE current_tests ( test_id UInt64, value Nullable(String), version UInt64 ) ENGINE = ReplacingMergeTree(version) ORDER BY test_id 

एक रिकॉर्ड परिवर्तन के मामले में, हम एक नए मूल्य के साथ संस्करण को हटाते हैं, हटाने के मामले में, एक NULL मान (या कुछ अन्य विशेष मूल्य जो डेटा में नहीं मिल सकते हैं) के साथ।

नए स्टोरेज के साथ आपने क्या हासिल किया?

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

हमारे पास आओ

हमारा विभाग लगातार विस्तार कर रहा है। यदि आप जटिल और दिलचस्प कार्यों और एल्गोरिदम पर काम करना चाहते हैं, तो हमें जाएँ । यदि आपके कोई प्रश्न हैं, तो आप मुझसे सीधे पीएम से पूछ सकते हैं।

उपयोगी लिंक

स्ट्रीम प्रसंस्करण

• लॉग: क्या हर सॉफ्टवेयर इंजीनियर को वास्तविक समय के डेटा के एकीकरण अमूर्तता के बारे में पता होना चाहिए ।
• बैच से परे दुनिया: 101 स्ट्रीमिंग ।
• पुस्तक डिजाइनिंग डेटा-गहन अनुप्रयोग - ओ'रिली मीडिया।

कप्पा स्थापत्य

• https://www.oreilly.com/ideas/questioning-the-lambda-Healthecture ।
• कप्पा-स्थापत्य ।

ClickHouse:

• Yandex ClickHouse को खोलता है ।
• https://clickhouse.yandex
• प्रलेखन ।