VK में ClickHouse का उपयोग करना, या हमने KittenHouse को क्यों लिखा

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

उस समय, हमारे पास लॉग्स को स्टोर करने और प्रोसेस करने के 2 तरीके थे - हमारे अपने लॉग इंजन और rsyslog, जिनका हमने समानांतर में उपयोग किया था। हमने अन्य विकल्पों पर विचार करना शुरू किया और महसूस किया कि यैंडेक्स से क्लिकहाउस हमारे लिए काफी उपयुक्त है - हमने इसे लागू करने का फैसला किया।

इस लेख में मैं इस बारे में बात करूंगा कि हमने किस तरह VKontakte पर ClickHouse का उपयोग करना शुरू किया, किस रेक पर हमने कदम रखा, और KittenHouse और LightHouse क्या हैं। दोनों उत्पादों को लेख के अंत में ओपन-सोर्स, लिंक में रखा गया है।

संग्रह कार्य लॉग करें

सिस्टम आवश्यकताएँ:

1. लॉग के सैकड़ों टेराबाइट्स का भंडारण।
2. महीनों या (शायद ही कभी) वर्षों के लिए भंडारण।
3. उच्च लिखने की गति।
4. उच्च पढ़ने की गति (पढ़ना दुर्लभ है)।
5. सूचकांक समर्थन
6. लंबे तार के लिए समर्थन (> 4 Kb)।
7. ऑपरेशन की सादगी।
8. कॉम्पैक्ट भंडारण।
9. हजारों सर्वरों (यूडीपी एक प्लस होगा) से सम्मिलित करने की क्षमता।

संभव समाधान

आइए संक्षेप में उन विकल्पों को सूचीबद्ध करें जिन्हें हमने माना था, और उनकी विपक्ष:

लॉग इंजन

लॉग के लिए हमारा स्व-लिखित माइक्रोसर्विस।

- केवल अंतिम एन लाइनों को देने में सक्षम है जो रैम में फिट होते हैं।
- बहुत कॉम्पैक्ट भंडारण (कोई पारदर्शी संपीड़न नहीं)।

Hadoop

- सभी प्रारूपों में अनुक्रमित नहीं होते हैं।
- पढ़ने की गति अधिक हो सकती है (प्रारूप के आधार पर)।
- सेटिंग्स की जटिलता।
- दसियों हज़ार सर्वरों से डालने की कोई संभावना नहीं है (कफ़्का या एनालॉग्स की आवश्यकता है)।

Rslog + फाइलें

- कोई सूचकांक नहीं।
- कम पढ़ने की गति (नियमित grep / zgrep)।
- आर्किटेक्चरली समर्थित स्ट्रिंग्स नहीं> 4 Kb, यूडीपी और भी कम (1.5 Kb)।
Crow मुकुट पर लॉगरोट द्वारा कॉम्पैक्ट भंडारण प्राप्त किया जाता है

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

एलएसडी + फाइलें

- कोई सूचकांक नहीं।
- कम पढ़ने की गति (नियमित grep / zgrep)।
- विशेष रूप से हजारों सर्वरों के सम्मिलन के लिए डिज़ाइन नहीं किया गया है।
Crow मुकुट पर लॉगरोट द्वारा कॉम्पैक्ट भंडारण प्राप्त किया जाता है।

हमारे मामले में rsyslog से अंतर यह है कि LSD लंबे तार का समर्थन करता है, लेकिन आंतरिक प्रोटोकॉल में महत्वपूर्ण परिवर्तन दसियों हजारों सर्वरों से सम्मिलित करने के लिए आवश्यक हैं, हालांकि यह किया जा सकता है।

ElasticSearch

- ऑपरेशन की समस्या।
- अस्थिर रिकॉर्डिंग।
- कोई यूडीपी नहीं।
- खराब संपीड़न।

लॉग संग्रहण के लिए ELK स्टैक पहले से ही लगभग उद्योग मानक है। हमारे अनुभव में, पढ़ने की गति के साथ सब कुछ ठीक है, लेकिन लेखन के साथ समस्याएं हैं, उदाहरण के लिए, जब सूचकांकों का विलय होता है।

ElasticSearch मुख्य रूप से पूर्ण-पाठ खोज और अपेक्षाकृत लगातार पढ़ने के अनुरोधों के लिए डिज़ाइन किया गया है। हमारे लिए, स्थिर रिकॉर्डिंग और हमारे डेटा को अधिक या कम तेज़ी से पढ़ने की क्षमता अधिक महत्वपूर्ण है, और सटीक संयोग से। फुल-टेक्स्ट खोज के लिए ElasticSearch पर सूचकांक को तेज किया गया है, और मूल सामग्री के गज़िप की तुलना में डिस्क स्थान काफी बड़ा है।

ClickHouse

- कोई यूडीपी नहीं।

By और बड़े, केवल एक चीज जो हमें ClickHouse पर सूट नहीं करती थी, वह UDP संचार की कमी थी। वास्तव में, उपरोक्त विकल्पों में, केवल rsyslog के पास था, लेकिन rsyslog ने लंबी लाइनों का समर्थन नहीं किया।

अन्य मानदंडों के अनुसार, ClickHouse हमारे पास आया, और हमने इसका उपयोग करने का फैसला किया, और परिवहन के साथ समस्याओं को प्रक्रिया में हल किया गया।

क्यों बिल्ली का बच्चा की जरूरत है

जैसा कि आप शायद जानते हैं, VKontakte PHP / KPHP पर काम करता है, "इंजन" (microservices) के साथ C / C ++ और गो पर थोड़ा सा। साझा मेमोरी और ओपन कनेक्शन के अलावा, PHP के पास अनुरोधों के बीच "राज्य" की अवधारणा नहीं है।

चूँकि हमारे पास हज़ारों सर्वर हैं जिनसे हम ClickHouse में लॉग भेजना चाहते हैं, इसलिए प्रत्येक PHP-वर्कर (प्रत्येक सर्वर के लिए 100+ वर्कर हो सकते हैं) से खुले कनेक्शन रखना लाभहीन होगा। इसलिए, हमें ClickHouse और PHP के बीच किसी प्रकार के प्रॉक्सी की आवश्यकता है। हमने इस प्रॉक्सी को बिल्ली का बच्चा कहा।

बिल्ली का बच्चा, v1

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



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

किटनहाउस, v1

KittenHouse का पहला संस्करण काफी कुछ जानता था, लेकिन यह परीक्षण के लिए पर्याप्त था:

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

पहली समस्याएं

हमने पहली समस्या का सामना किया जब हमने कई घंटों के लिए ClickHouse सर्वर को "चुकाया" और फिर उसे वापस चालू कर दिया। नीचे आप "औसत" होने के बाद सर्वर पर लोड औसत देख सकते हैं:



स्पष्टीकरण काफी सरल है: ClickHouse में एक नेटवर्क प्रति थ्रेड मॉडल है, इसलिए जब मैंने एक ही समय में हजारों नोड्स से INSERT बनाने की कोशिश की, तो सीपीयू संसाधनों के लिए बहुत मजबूत प्रतिस्पर्धा थी और सर्वर ने मुश्किल से जवाब दिया। हालांकि, सभी डेटा अंततः डाला गया था और कुछ भी नहीं गिरा था।

इस समस्या को हल करने के लिए, हमने न्यूहाउस को ClickHouse के सामने रखा और, सामान्य तौर पर, इससे मदद मिली।

आगे का विकास

ऑपरेशन के दौरान, हमें कई समस्याओं का सामना करना पड़ा, मुख्य रूप से ClickHouse से संबंधित नहीं, लेकिन इसे संचालित करने के हमारे तरीके से। यहाँ एक और रेक है जिस पर हमने कदम रखा है:

बफ़र तालिकाओं की एक बड़ी संख्या "मर्जट्री" में लगातार बफर फ्लश की ओर ले जाती है

हमारे मामले में, बफर के 16 टुकड़े थे और हर 2 सेकंड में एक रीसेट अंतराल था, और 20 टुकड़े टेबल थे, जो प्रति सेकंड 160 आवेषण तक थे। इसने समय-समय पर सम्मिलन के प्रदर्शन को बहुत बुरी तरह से प्रभावित किया - बहुत सारे पृष्ठभूमि विलय और डिस्क उपयोग 80% और अधिक तक पहुंच गए।

समाधान: डिफ़ॉल्ट बफर रीसेट अंतराल बढ़ाएं, टुकड़ों की संख्या 2 तक कम करें।

जब अपस्ट्रीम अंत तक कनेक्शन आता है, तो Nginx 502 देता है

यह अपने आप में कोई समस्या नहीं है, लेकिन बफर के बार-बार निस्तब्धता के साथ संयोजन में, इसने 502 त्रुटियों की एक उच्च पृष्ठभूमि दी, जब किसी भी तालिकाओं में सम्मिलित करने की कोशिश की, साथ ही साथ SELECT करने की कोशिश की।

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

गहन सम्मिलन के साथ स्मृति से बाहर चल रहा है

Fasthttp लाइब्रेरी के अपने फायदे और नुकसान हैं। कमियों में से एक यह है कि अनुरोध हैंडलर को नियंत्रण देने से पहले अनुरोध और प्रतिक्रिया पूरी तरह से मेमोरी में बफ़र हो जाती है। हमारे लिए, यह इस तथ्य के परिणामस्वरूप था कि अगर ClickHouse में डालने "समय नहीं है", तो बफ़र्स बढ़ने लगे और अंततः सर्वर पर सभी मेमोरी बाहर भाग गईं, जिसके कारण OOM द्वारा रिवर्स प्रॉक्सी की हत्या हुई। सहकर्मियों ने एक डेमोक्रेट को आकर्षित किया:



समाधान: POST रिक्वेस्ट के बॉडी को सपोर्ट करने के लिए फास्टहट पैचिंग करना एक कठिन काम है, इसलिए हमने Hijack () कनेक्शन का उपयोग करने का अनुरोध किया और यदि KITTEN HTTP मेथड के साथ रिक्वेस्ट आई तो हमारे प्रोटोकॉल में कनेक्शन अपग्रेड करें। चूंकि सर्वर को जवाब में MEOW का जवाब देना चाहिए, अगर वह इस प्रोटोकॉल को समझता है, तो पूरी योजना को KITTEN / MEOW प्रोटोकॉल कहा जाता है।

हम केवल एक समय में 50 यादृच्छिक कनेक्शन से पढ़ते हैं, इसलिए, टीसीपी / आईपी के लिए धन्यवाद, बाकी क्लाइंट "प्रतीक्षा" करते हैं और हम बफ़र्स पर मेमोरी तब तक खर्च नहीं करते हैं जब तक कतार संबंधित क्लाइंट तक नहीं पहुंच जाती। इससे स्मृति की खपत कम से कम 20 गुना हो गई, और हमें ऐसी कोई समस्या नहीं थी।

यदि लंबे प्रश्न हैं, तो तालिकाएँ लंबी जा सकती हैं

ClickHouse इस अर्थ में गैर-अवरोधक है कि यह SELECT और INSERT दोनों प्रश्नों में हस्तक्षेप नहीं करता है। लेकिन ALTER तब तक शुरू नहीं हो सकता जब तक कि ALTER से पहले भेजी गई इस तालिका में प्रश्नों को निष्पादित करना समाप्त न हो जाए।

यदि आपके सर्वर में कुछ तालिकाओं के लिए "लंबे" प्रश्नों की पृष्ठभूमि है, तो आप ऐसी स्थिति का सामना कर सकते हैं, जहां इस तालिका में ALTER के पास 60 सेकंड के डिफ़ॉल्ट समय में निष्पादित करने का समय नहीं होगा। लेकिन इसका मतलब यह नहीं है कि ALTER विफल हो जाएगा: जैसे ही उन SELECT क्वेश्चन खत्म होंगे, उन्हें निष्पादित किया जाएगा।

इसका मतलब यह है कि आपको पता नहीं है कि वास्तव में किस समय पर हुआ था, और आपके पास बफ़र तालिकाओं को स्वचालित रूप से फिर से बनाने की क्षमता नहीं है, ताकि उनका लेआउट हमेशा समान हो। इससे सम्मिलन समस्याएँ हो सकती हैं।





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

डेटा पढ़ना

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

• तालिका सामग्री का त्वरित दृश्य।
• छानना, छांटना।
• SQL क्वेरी का संपादन।
• तालिका संरचना देखें।
• प्रयुक्त लाइनों और डिस्क स्थान की अनुमानित संख्या दिखाता है।

हालाँकि, लाइटहाउस तेज़ है और वह करने में सक्षम है जिसकी हमें आवश्यकता है। यहाँ स्क्रीनशॉट के एक जोड़े हैं:

तालिका संरचना देखें



सामग्री फ़िल्टरिंग

परिणाम

ClickHouse व्यावहारिक रूप से एकमात्र ओपन-सोर्स डेटाबेस है जिसने VKontakte पर रूट लिया है। हम इसके काम की गति से प्रसन्न हैं और कमियों के साथ तैयार होने के लिए तैयार हैं, जिनकी चर्चा नीचे की गई है।

काम में कठिनाई

सब सब में, ClickHouse एक बहुत ही स्थिर डेटाबेस और बहुत तेज़ है। हालांकि, किसी भी उत्पाद के साथ, विशेष रूप से बहुत युवा, काम में ऐसी विशेषताएं हैं जिन पर विचार करने की आवश्यकता है:

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

खुला स्रोत

किथहाउस और लाइटहाउस अब हमारे गीथूब भंडार में खुले स्रोत में उपलब्ध हैं:

• बिल्ली का बच्चा: github.com/vkcom/kittenhouse
• लाइटहाउस: github.com/vkcom/lighthouse

धन्यवाद!

यूरी नसेरेतिनोव, VKontakte के बैकेंड इंफ्रास्ट्रक्चर विभाग में डेवलपर