हाईलोड++, यूरी नसरेटदीनोव (वीकॉन्टैक्टे): कैसे वीके हजारों सर्वरों से क्लिकहाउस में डेटा सम्मिलित करता है

हाईलोड++ मॉस्को 2018, कांग्रेस हॉल। 9 नवंबर, 15:00 बजे

सार और प्रस्तुति: http://www.highload.ru/moscow/2018/abstracts/4066

यूरी नसरेटदीनोव (VKontakte): रिपोर्ट हमारी कंपनी में ClickHouse को लागू करने के अनुभव के बारे में बात करेगी - हमें इसकी आवश्यकता क्यों है, हम कितना डेटा संग्रहीत करते हैं, हम इसे कैसे लिखते हैं, इत्यादि।

अतिरिक्त सामग्री: ईएलके, बिग क्वेरी और टाइमस्केलडीबी के प्रतिस्थापन के रूप में क्लिकहाउस का उपयोग करना

यूरी नसरेटदीनोव: - नमस्ते! मेरा नाम यूरी नसरेटदीनोव है, जैसा कि मेरा परिचय पहले ही हो चुका है। मैं VKontakte पर काम करता हूँ। मैं इस बारे में बात करूंगा कि हम अपने सर्वर बेड़े (दसियों हज़ार) से ClickHouse में डेटा कैसे सम्मिलित करते हैं।

लॉग क्या हैं और उन्हें क्यों एकत्र किया जाता है?

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

हमें कुछ भी करने की ज़रूरत ही क्यों पड़ी (VKontakte पर सब कुछ हमेशा अच्छा होता है, ठीक है?)। हम डिबग लॉग एकत्र करना चाहते थे (और वहां सैकड़ों टेराबाइट डेटा थे), शायद किसी तरह आंकड़ों की गणना करना अधिक सुविधाजनक होगा; और हमारे पास हजारों सर्वरों का बेड़ा है जिनसे यह सब करने की आवश्यकता है।

हमने यह निर्णय क्यों लिया? संभवतः हमारे पास लॉग भंडारण के लिए समाधान थे। यहाँ - एक ऐसा सार्वजनिक "बैकएंड वीके" है। मैं इसकी सदस्यता लेने की अत्यधिक अनुशंसा करता हूँ।

लॉग क्या हैं? यह एक इंजन है जो खाली ऐरे लौटाता है। वीके में इंजन वे हैं जिन्हें अन्य लोग माइक्रोसर्विसेज कहते हैं। और यहाँ एक मुस्कुराता हुआ स्टिकर है (बहुत सारे लाइक)। ऐसा कैसे? अच्छा, आगे सुनो!

लॉग को संग्रहीत करने के लिए क्या उपयोग किया जा सकता है? Hadup का उल्लेख न करना असंभव है। फिर, उदाहरण के लिए, Rsyslog (फ़ाइलों में इन लॉग को संग्रहीत करना)। एलएसडी. कौन जानता है एलएसडी क्या है? नहीं, यह एलएसडी नहीं. फ़ाइलें भी क्रमशः संग्रहित करें. खैर, ClickHouse एक अजीब विकल्प है।

क्लिकहाउस और प्रतिस्पर्धी: आवश्यकताएँ और अवसर

हम क्या चाहते हैं? हम यह सुनिश्चित करना चाहते हैं कि हमें ऑपरेशन के बारे में बहुत अधिक चिंता न करनी पड़े, ताकि यह बॉक्स से बाहर काम करे, अधिमानतः न्यूनतम कॉन्फ़िगरेशन के साथ। हम बहुत कुछ लिखना चाहते हैं, और जल्दी-जल्दी लिखना चाहते हैं। और हम इसे हर तरह के महीनों, सालों यानी लंबे समय तक बरकरार रखना चाहते हैं। हम शायद कुछ समस्या को समझना चाहते हैं जिसे लेकर वे हमारे पास आए और कहा, "यहां कुछ काम नहीं कर रहा है," और वह 3 महीने पहले था), और हम यह देखने में सक्षम होना चाहते हैं कि 3 महीने पहले क्या हुआ था। डेटा संपीड़न - यह स्पष्ट है कि यह एक प्लस क्यों होगा - क्योंकि यह इसके द्वारा ली जाने वाली जगह की मात्रा को कम करता है।

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

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

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

रुसिस्लॉग. वास्तव में, हमने इसे एक बैकअप विकल्प के रूप में उपयोग किया ताकि हम बिनलॉग को डंप किए बिना इसे पढ़ सकें, लेकिन यह लंबी लाइनें नहीं लिख सकता है; सिद्धांत रूप में, यह 4 किलोबाइट से अधिक नहीं लिख सकता है। आपको खुद ही इसी तरह से डेटा कंप्रेस करना होगा। फाइलों से रीडिंग आएगी।

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

और यहां! एक मज़ेदार विकल्प ElasticSearch है। कैसे कहें? वह पढ़ने में अच्छा कर रहा है, यानी वह तेजी से पढ़ता है, लेकिन लिखने में बहुत अच्छा नहीं है। सबसे पहले, यदि यह डेटा को संपीड़ित करता है, तो यह बहुत कमजोर है। सबसे अधिक संभावना है, पूर्ण खोज के लिए मूल वॉल्यूम की तुलना में बड़ी डेटा संरचनाओं की आवश्यकता होती है। इसे चलाना मुश्किल है और इसमें अक्सर दिक्कतें आती रहती हैं। और, फिर से, इलास्टिक में रिकॉर्डिंग - हमें सब कुछ स्वयं करना होगा।

यहाँ ClickHouse निश्चित रूप से एक आदर्श विकल्प है। एकमात्र बात यह है कि हजारों सर्वरों से रिकॉर्डिंग एक समस्या है। लेकिन कम से कम एक समस्या तो है, हम उसे किसी तरह सुलझाने की कोशिश कर सकते हैं. और बाकी रिपोर्ट इसी समस्या के बारे में है. आप ClickHouse से किस प्रकार के प्रदर्शन की उम्मीद कर सकते हैं?

हम इसे कैसे सम्मिलित करेंगे? मर्जट्री

आपमें से किसने "क्लिकहाउस" के बारे में नहीं सुना या नहीं जाना है? मुझे तुम्हें बताना होगा, है ना? बहुत तेज। वहां सम्मिलन - 1-2 गीगाबिट प्रति सेकंड, 10 गीगाबिट प्रति सेकंड तक का विस्फोट वास्तव में इस कॉन्फ़िगरेशन का सामना कर सकता है - दो 6-कोर ज़ीऑन हैं (अर्थात, सबसे शक्तिशाली भी नहीं), 256 गीगाबाइट रैम, 20 टेराबाइट्स RAID में (किसी ने कॉन्फ़िगर नहीं किया, डिफ़ॉल्ट सेटिंग्स)। एलेक्सी मिलोविदोव, क्लिकहाउस डेवलपर, शायद वहां बैठकर रो रहे हैं क्योंकि हमने कुछ भी कॉन्फ़िगर नहीं किया है (हमारे लिए सब कुछ उसी तरह काम करता है)। तदनुसार, यदि डेटा अच्छी तरह से संपीड़ित है, तो प्रति सेकंड लगभग 6 बिलियन लाइन की स्कैनिंग गति प्राप्त की जा सकती है। यदि आपको टेक्स्ट स्ट्रिंग पर % पसंद है - प्रति सेकंड 100 मिलियन लाइनें, यानी, यह काफी तेज़ लगती है।

हम इसे कैसे सम्मिलित करेंगे? खैर, आप जानते हैं कि वीके PHP का उपयोग करता है। हम प्रत्येक PHP कार्यकर्ता से HTTP के माध्यम से "क्लिकहाउस" में, प्रत्येक रिकॉर्ड के लिए मर्जट्री तालिका में सम्मिलित करेंगे। इस योजना में किसे समस्या दिखती है? किसी कारणवश सभी ने हाथ नहीं उठाया। मैं आपको बता दूँ।

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

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

लेकिन, जैसा कि आप अनुमान लगा सकते हैं, यदि आप प्रत्येक प्रविष्टि के लिए 10 फ़ाइलें लिखते हैं, तो ClickHouse (या आपका सर्वर) जल्दी समाप्त हो जाएगा, इसलिए इसे बड़े बैचों में सम्मिलित करने की अनुशंसा की जाती है। तदनुसार, हमने कभी भी पहली योजना को उत्पादन में लॉन्च नहीं किया। हमने तुरंत एक लॉन्च किया, जो यहां नंबर 2 पर है:

यहां कल्पना करें कि लगभग एक हजार सर्वर हैं जिन पर हमने लॉन्च किया है, उनमें सिर्फ PHP है। और प्रत्येक सर्वर पर हमारा स्थानीय एजेंट होता है, जिसे हम "किटनहाउस" कहते हैं, जो "क्लिकहाउस" के साथ एक कनेक्शन बनाए रखता है और हर कुछ सेकंड में डेटा डालता है। डेटा को मर्जट्री में नहीं, बल्कि एक बफ़र तालिका में सम्मिलित करता है, जो तुरंत सीधे मर्जट्री में डालने से बचने के लिए कार्य करता है।

बफ़र तालिकाओं के साथ कार्य करना

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

उसी समय, बफर वाली योजना ALTER को जटिल बनाती है, क्योंकि आपको पहले पुरानी बफर तालिका को पुरानी योजना के साथ छोड़ना होगा (डेटा कहीं भी गायब नहीं होगा, क्योंकि तालिका हटाए जाने से पहले इसे फ्लश कर दिया जाएगा)। फिर आप अपनी आवश्यक तालिका को "बदलें" और फिर से बफर तालिका बनाएं। तदनुसार, जब तक कोई बफर टेबल नहीं है, आपका डेटा कहीं भी प्रवाहित नहीं होगा, लेकिन आप इसे कम से कम स्थानीय रूप से डिस्क पर रख सकते हैं।

किटनहाउस क्या है और यह कैसे काम करता है?

किटनहाउस क्या है? यह एक प्रॉक्सी है. अंदाज़ा लगाओ कौन सी भाषा? मैंने अपनी रिपोर्ट में सबसे अधिक प्रचारित विषय एकत्र किए - "क्लिकहाउस", जाओ, शायद मुझे कुछ और याद आएगा। हां, यह गो में लिखा गया है, क्योंकि मैं वास्तव में नहीं जानता कि सी में कैसे लिखना है, मैं नहीं चाहता।

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

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

nginx जोड़ें

थ्रेड प्रति कनेक्शन मॉडल के लिए ऐसा समाधान nginx है। हमने क्लिकहाउस के सामने nginx स्थापित किया, साथ ही दो प्रतिकृतियों के लिए संतुलन स्थापित किया (हमारी डालने की गति 2 गुना बढ़ गई, हालांकि यह सच नहीं है कि यह मामला होना चाहिए) और क्लिकहाउस के लिए कनेक्शन की संख्या सीमित कर दी। अपस्ट्रीम और, तदनुसार, 50 कनेक्शनों से अधिक, ऐसा लगता है कि डालने का कोई मतलब नहीं है।

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

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

समाधान से एक कदम दूर

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

करीब एक महीने तक हम ऐसे ही रहे. हर कोई खुश था, उन्होंने तालिकाएँ जोड़ीं, उन्होंने जोड़ीं, उन्होंने जोड़ीं... सामान्य तौर पर, यह पता चला कि जिस तरह से हमने बफ़र तालिकाएँ जोड़ीं वह बहुत इष्टतम नहीं था (आइए इसे इस तरह से कहें)। हमने प्रत्येक तालिका में 16 टुकड़े किए और कुछ सेकंड का फ्लैश अंतराल किया; हमारे पास 20 टेबल थे और प्रत्येक टेबल को प्रति सेकंड 8 इंसर्ट प्राप्त होते थे - और इस बिंदु पर "क्लिकहाउस" शुरू हुआ... रिकॉर्ड धीमा होने लगा। न केवल वे पास नहीं हुए... डिफ़ॉल्ट रूप से, nginx में ऐसी दिलचस्प बात थी कि यदि कनेक्शन अपस्ट्रीम पर समाप्त हो जाता है, तो यह सभी नए अनुरोधों पर बस "502" लौटा देता है।

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

nginx को रिवर्स प्रॉक्सी से बदलना

मैंने निर्णय लिया कि हमें इसे स्वयं प्रबंधित करने की आवश्यकता है, हमें इसे nginx पर छोड़ने की आवश्यकता नहीं है - nginx को नहीं पता कि Clickhouse में कौन सी तालिकाएँ हैं, और मैंने nginx को एक रिवर्स प्रॉक्सी से बदल दिया, जिसे मैंने खुद भी लिखा था।

वह क्या कर रहा है? यह fasthttp लाइब्रेरी "goshnoy" पर आधारित काम करता है, यानी तेज़, लगभग nginx जितना तेज़। क्षमा करें, इगोर, यदि आप यहां मौजूद हैं (नोट: इगोर सियोसेव एक रूसी प्रोग्रामर हैं जिन्होंने नेग्नेक्स वेब सर्वर बनाया है)। यह समझ सकता है कि ये किस प्रकार के प्रश्न हैं - INSERT या SELECT - तदनुसार, यह विभिन्न प्रकार के प्रश्नों के लिए अलग-अलग कनेक्शन पूल रखता है।

तदनुसार, भले ही हमारे पास सम्मिलन अनुरोधों को पूरा करने का समय न हो, "चयन" पारित हो जाएगा, और इसके विपरीत। और यह डेटा को बफ़र तालिकाओं में समूहित करता है - एक छोटे बफ़र के साथ: यदि कोई त्रुटि, वाक्यविन्यास त्रुटियाँ, इत्यादि होती हैं - ताकि वे शेष डेटा को बहुत अधिक प्रभावित न करें, क्योंकि जब हम बस बफ़र तालिकाओं में डालते हैं, तो हम छोटी "बच्ची" थी, और सभी वाक्यविन्यास त्रुटियों ने केवल इस छोटे टुकड़े को प्रभावित किया; और यहां वे पहले से ही एक बड़े बफर को प्रभावित करेंगे। छोटा 1 मेगाबाइट है, यानी इतना छोटा नहीं।

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

योजना इस तरह दिखने लगी: "किटनहाउस", रिवर्स प्रॉक्सी कई अनुरोधों को तालिकाओं में समूहित करता है और बदले में, बफर टेबल उन्हें मुख्य में सम्मिलित करता है।

हत्यारा एक अस्थायी समाधान है, बिल्ली का बच्चा स्थायी है

यह एक दिलचस्प समस्या है... क्या आप में से किसी ने fasthttp का उपयोग किया है? POST अनुरोधों के साथ fasthttp का उपयोग किसने किया? संभवतः, यह वास्तव में नहीं किया जाना चाहिए था, क्योंकि यह अनुरोध निकाय को डिफ़ॉल्ट रूप से बफ़र करता है, और हमारा बफ़र आकार 16 मेगाबाइट पर सेट किया गया था। कुछ बिंदु पर सम्मिलन रुक गया, और 16-मेगाबाइट के टुकड़े हजारों सर्वरों से आने लगे, और क्लिकहाउस में भेजे जाने से पहले उन सभी को मेमोरी में बफर कर दिया गया। तदनुसार, मेमोरी खत्म हो गई, आउट-ऑफ-मेमोरी किलर आया और रिवर्स प्रॉक्सी (या "क्लिकहाउस", जो सैद्धांतिक रूप से रिवर्स प्रॉक्सी से अधिक "खा" सकता था) को मार डाला। चक्र ने खुद को दोहराया. बहुत सुखद समस्या नहीं है. हालाँकि हम कई महीनों के ऑपरेशन के बाद ही इस पर पहुँचे।

मैने क्या किया है? फिर, मैं वास्तव में यह समझना पसंद नहीं करता कि वास्तव में क्या हुआ था। मुझे लगता है कि यह बिल्कुल स्पष्ट है कि आपको मेमोरी में बफर नहीं करना चाहिए। हालाँकि मैंने कोशिश की, मैं fasthttp को पैच नहीं कर सका। लेकिन मुझे इसे बनाने का एक तरीका मिल गया ताकि कुछ भी पैच करने की आवश्यकता न हो, और मैं HTTP में अपनी खुद की विधि लेकर आया - मैंने इसे KITTEN कहा। खैर, यह तर्कसंगत है - "वीके", "बिल्ली का बच्चा"... और क्या?..

यदि किटन विधि के साथ सर्वर पर कोई अनुरोध आता है, तो सर्वर को तार्किक रूप से "म्याऊ" का जवाब देना चाहिए। यदि वह इसका जवाब देता है, तो यह माना जाता है कि वह इस प्रोटोकॉल को समझता है, और फिर मैं कनेक्शन को इंटरसेप्ट करता हूं (fasthttp में ऐसी विधि है), और कनेक्शन "रॉ" मोड में चला जाता है। मुझे इसकी ज़रूरत क्यों है? मैं नियंत्रित करना चाहता हूं कि टीसीपी कनेक्शन से रीडिंग कैसे होती है। टीसीपी की एक अद्भुत संपत्ति है: यदि कोई दूसरी तरफ से नहीं पढ़ रहा है, तो लिखने में देरी होने लगती है, और इस पर स्मृति विशेष रूप से खर्च नहीं होती है।

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

बफ़र तालिका दुखद है

हाल ही में हमें बफ़र तालिकाओं की एक और दिलचस्प विशेषता के बारे में पता चला। और यह समस्या पहले से ही अन्य की तुलना में बहुत अधिक दर्दनाक है। आइए इस स्थिति की कल्पना करें: आप पहले से ही सक्रिय रूप से क्लिकहाउस का उपयोग कर रहे हैं, आपके पास दर्जनों क्लिकहाउस सर्वर हैं, और आपके पास कुछ अनुरोध हैं जिन्हें पढ़ने में बहुत लंबा समय लगता है (मान लीजिए, 60 सेकंड से अधिक); और आप आएं और इस समय ऑल्टर करें... इस बीच, "ऑल्टर" से पहले शुरू हुए "सेलेक्ट्स" को इस तालिका में शामिल नहीं किया जाएगा, "ऑल्टर" शुरू नहीं होगा - शायद "क्लिकहाउस" कैसे काम करता है इसकी कुछ विशेषताएं इस जगह। शायद इसे ठीक किया जा सकता है? या यह संभव नहीं है?

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

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

कौन जानता था कि इस लड़के का नाम स्पॉटी था? वीके कर्मचारियों ने हाथ खड़े कर दिए। ठीक है।

"किटनहाउस" की योजनाओं के बारे में

योजनाएँ आमतौर पर साझा नहीं की जातीं, है ना? अचानक आप उन्हें पूरा नहीं कर पाएंगे और दूसरे लोगों की नजरों में बहुत अच्छे नहीं दिखेंगे। लेकिन मैं जोखिम लूंगा! हम निम्नलिखित कार्य करना चाहते हैं: मुझे ऐसा लगता है कि बफ़र टेबल अभी भी एक बैसाखी हैं और हमें सम्मिलन को स्वयं बफ़र करने की आवश्यकता है। लेकिन हम अभी भी इसे डिस्क पर बफ़र नहीं करना चाहते हैं, इसलिए हम मेमोरी में सम्मिलन को बफ़र करेंगे।

तदनुसार, जब एक "इन्सर्ट" बनाया जाता है, तो यह अब सिंक्रोनस नहीं होगा - यह पहले से ही एक बफर टेबल के रूप में काम करेगा, मूल टेबल में डाला जाएगा (ठीक है, किसी दिन बाद) और एक अलग चैनल के माध्यम से रिपोर्ट करेगा कि कौन सा इन्सर्ट पास हो गया है और कौन सा नहीं है।

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

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

चलो पढ़ने के बारे में बात करते हैं

अब बात करते हैं पढ़ने की. हमने यहां अपना स्वयं का टूल भी लिखा है। ऐसा प्रतीत होता है, ठीक है, यहाँ अपना स्वयं का उपकरण क्यों लिखें?.. और टैबिक्स का उपयोग किसने किया? किसी तरह कुछ लोगों ने हाथ उठाए... और टैबिक्स के प्रदर्शन से कौन संतुष्ट है? खैर, हम इससे खुश नहीं हैं और डेटा देखने के लिए यह बहुत सुविधाजनक नहीं है। यह विश्लेषण के लिए ठीक है, लेकिन केवल देखने के लिए यह स्पष्ट रूप से अनुकूलित नहीं है। इसलिए मैंने अपना स्वयं का इंटरफ़ेस लिखा।

यह बहुत सरल है - यह केवल डेटा पढ़ सकता है। वह ग्राफिक्स दिखाना नहीं जानता, वह कुछ भी करना नहीं जानता। लेकिन यह दिखा सकता है कि हमें क्या चाहिए: उदाहरण के लिए, तालिका में कितनी पंक्तियाँ हैं, यह कितनी जगह लेती है (इसे स्तंभों में तोड़े बिना), यानी, एक बहुत ही बुनियादी इंटरफ़ेस वह है जो हमें चाहिए।

और यह सीक्वल प्रो के समान दिखता है, लेकिन केवल ट्विटर के बूटस्ट्रैप और दूसरे संस्करण पर बनाया गया है। आप पूछते हैं: "यूरी, दूसरे संस्करण पर क्यों?" कौन सा साल? 2018? सामान्य तौर पर, मैंने इसे काफी समय पहले "मसल" (MySQL) के लिए किया था और वहां प्रश्नों में बस कुछ पंक्तियों को बदल दिया था, और यह "क्लिकहाउस" के लिए काम करना शुरू कर दिया, जिसके लिए विशेष धन्यवाद! क्योंकि पार्सर "मांसपेशियों" के समान है, और प्रश्न भी बहुत समान हैं - बहुत सुविधाजनक, खासकर शुरुआत में।

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

एक संपादक भी हैं. मैंने ईमानदारी से टैबिक्स से संपूर्ण संपादक चुराने की कोशिश की, लेकिन मैं ऐसा नहीं कर सका। लेकिन किसी तरह यह काम करता है. सिद्धांत रूप में, बस इतना ही।

"क्लिकहाउस" डेंस के लिए उपयुक्त है

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

टीसीपी? सामान्य तौर पर, वीके में यूडीपी का उपयोग करने की प्रथा है। और जब मैंने टीसीपी का उपयोग किया... बेशक, किसी ने मुझसे नहीं कहा: “यूरी, तुम किस बारे में बात कर रहे हो! आप ऐसा नहीं कर सकते, आपको यूडीपी की आवश्यकता है।" यह पता चला कि टीसीपी इतना डरावना नहीं है। एकमात्र बात यह है कि, यदि आपके पास हजारों सक्रिय यौगिक हैं जिन्हें आप लिखते हैं, तो आपको इसे थोड़ा और सावधानी से तैयार करने की आवश्यकता है; लेकिन यह संभव है, और काफी आसान है।

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

संचालक: - दोस्तों, अब प्रश्नों के लिए। वीएचएस पर प्रशंसा प्रमाणपत्र और आपकी रिपोर्ट प्रस्तुत करने के ठीक बाद।

यूरी नसरेटदीनोव (बाद में वाईएन के रूप में संदर्भित): - यदि वीएचएस अभी-अभी समाप्त हुई तो आप मेरी रिपोर्ट को उस पर कैसे रिकॉर्ड कर पाए?

संचालक: - आप यह भी पूरी तरह से निर्धारित नहीं कर सकते कि "क्लिकहाउस" कैसे काम करेगा या नहीं! मित्रों, प्रश्नों के लिए 5 मिनट!

सवाल

दर्शकों से प्रश्न (बाद में इसे प्रश्न के रूप में संदर्भित किया जाएगा): - शुभ दोपहर। रिपोर्ट के लिए बहुत बहुत धन्यवाद. मेरे दो प्रश्न हैं. मैं कुछ तुच्छ से शुरू करूंगा: क्या आरेख (3, 4, 7...) में "किटनहाउस" नाम में अक्षरों की संख्या बिल्लियों की संतुष्टि को प्रभावित करती है?

Y N: - किसकी मात्रा?

जेड: – पत्र टी. तीन टी हैं, कहीं तीन टी के आसपास।

Y N: - क्या मैंने इसे ठीक नहीं किया? खैर, निःसंदेह ऐसा होता है! ये अलग-अलग उत्पाद हैं - मैं इस समय बस आपको धोखा दे रहा था। ठीक है, मैं मजाक कर रहा हूं - इससे कोई फर्क नहीं पड़ता। आह, यहीं! नहीं, यह वही बात है, मैंने एक टाइपो गलती कर दी है।

जेड: - धन्यवाद। दूसरा सवाल गंभीर है. जहां तक ​​मैं समझता हूं, क्लिकहाउस में, बफ़र टेबल विशेष रूप से मेमोरी में रहते हैं, डिस्क पर बफ़र नहीं होते हैं और, तदनुसार, स्थायी नहीं होते हैं।

Y N: - हाँ।

जेड: - और साथ ही, आपका क्लाइंट डिस्क पर बफ़र करता है, जिसका अर्थ है कि इन्हीं लॉग्स की डिलीवरी की कुछ गारंटी है। लेकिन क्लिकहाउस में इसकी कोई गारंटी नहीं है। बताएं कि गारंटी कैसे दी जाती है, किस कारण से?.. यहां यह तंत्र अधिक विस्तार से दिया गया है

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

जेड: - यानी, "किटनहाउस" खिड़की को लंबे समय तक पकड़कर रखता है और गिरने की स्थिति में, उसे पहचान सकता है और उसे उल्टा कर सकता है?

Y N: - लेकिन यह सिद्धांत में है। व्यवहार में, हम ऐसा नहीं करते हैं, और विश्वसनीय डिलीवरी शून्य से अनंत गुना तक होती है। लेकिन औसतन एक. हम संतुष्ट हैं कि यदि किसी कारण से क्लिकहाउस क्रैश हो जाता है या सर्वर "रीबूट" हो जाता है, तो हमें थोड़ा नुकसान होता है। अन्य सभी मामलों में, कुछ नहीं होगा.

जेड: - नमस्ते। शुरुआत से ही मुझे ऐसा लग रहा था कि आप रिपोर्ट की शुरुआत से ही वास्तव में यूडीपी का उपयोग कर रहे होंगे। आपके पास http है, वह सब... और अधिकांश समस्याएं जिनका आपने वर्णन किया है, जैसा कि मैं समझता हूं, इस विशेष समाधान के कारण हुई थीं...

Y N: – हम टीसीपी का उपयोग क्या करते हैं?

जेड: - मूलतः हाँ.

Y N: - नहीं।

जेड: - fasthttp के साथ आपको समस्याएँ हुईं, कनेक्शन के साथ आपको समस्याएँ हुईं। यदि आपने अभी यूडीपी का उपयोग किया होता तो आप अपना कुछ समय बचा लेते। खैर, लंबे संदेशों या किसी और चीज़ से समस्याएँ होंगी...

Y N: - साथ क्या?

जेड: - लंबे संदेशों के साथ, चूंकि यह एमटीयू में फिट नहीं हो सकता है, कुछ और... खैर, उनकी अपनी समस्याएं हो सकती हैं। सवाल यह है: यूडीपी क्यों नहीं?

Y N: - मेरा मानना ​​है कि टीसीपी/आईपी विकसित करने वाले लेखक मुझसे कहीं अधिक होशियार हैं और मुझसे बेहतर जानते हैं कि पैकेटों को क्रमबद्ध कैसे किया जाए (ताकि वे चले जाएं), साथ ही भेजने वाली विंडो को समायोजित करें, नेटवर्क को ओवरलोड न करें, किस पर प्रतिक्रिया दें पढ़ा नहीं गया है, दूसरी तरफ गिनती नहीं है... ये सभी समस्याएं, मेरी राय में, यूडीपी में मौजूद होंगी, केवल मुझे उसी चीज़ को स्वयं लागू करने के लिए पहले से लिखे गए से भी अधिक कोड लिखना होगा और सबसे अधिक संभावना है ख़राब. मुझे वास्तव में C में लिखना भी पसंद नहीं है, वहां तो अकेले ही...

जेड: - बस सुविधाजनक! ठीक है भेजा गया है और किसी भी चीज़ की प्रतीक्षा न करें - यह पूरी तरह से अतुल्यकालिक है। एक सूचना वापस आई कि सब कुछ ठीक है - इसका मतलब है कि यह आ गया; यदि यह नहीं आता है, तो इसका मतलब है कि यह ख़राब है।

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

जेड: - मैं समय बर्बाद नहीं करूंगा। इस पर और अधिक चर्चा किये जाने की जरूरत है. धन्यवाद।

संचालक: – किसके पास प्रश्न हैं – आसमान की ओर हाथ!

जेड: - नमस्ते, मैं साशा हूं। रिपोर्ट के बीच में कहीं यह अहसास हुआ कि टीसीपी के अलावा, तैयार समाधान - किसी प्रकार का काफ्का का उपयोग करना संभव था।

Y N: - अच्छा... मैंने तुमसे कहा था कि मैं मध्यवर्ती सर्वर का उपयोग नहीं करना चाहता, क्योंकि... काफ्का में, यह पता चला है कि हमारे पास दस हजार होस्ट हैं; वास्तव में, हमारे पास इससे भी अधिक - हजारों की संख्या में मेज़बान हैं। बिना किसी प्रॉक्सी के काफ्का के साथ काम करना भी दर्दनाक हो सकता है। इसके अलावा, सबसे महत्वपूर्ण बात यह है कि यह अभी भी "विलंबता" देता है, यह अतिरिक्त होस्ट देता है जो आपके पास होना चाहिए। लेकिन मैं उन्हें नहीं चाहता - मैं चाहता हूं...

जेड: "लेकिन अंत में वैसे ही नतीजा निकला।"

Y N: – नहीं, कोई मेज़बान नहीं हैं! यह सब Clickhouse होस्ट्स पर काम करता है।

जेड: - ठीक है, और "किटनहाउस", जो विपरीत है - वह कहाँ रहता है?

Y N: - क्लिकहाउस होस्ट पर, यह डिस्क पर कुछ भी नहीं लिखता है।

जेड: - मान लीजिए.

संचालक: - क्या आप संतुष्ट हैं? क्या हम आपको वेतन दे सकते हैं?

जेड: - हाँ तुम कर सकते हो। वास्तव में, एक ही चीज़ को पाने के लिए बहुत सारी बैसाखियाँ हैं, और अब - टीसीपी विषय पर पिछला उत्तर, मेरी राय में, इस स्थिति का खंडन करता है। ऐसा महसूस होता है कि सब कुछ बहुत कम समय में मेरे घुटनों पर किया जा सकता था।

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

जेड: - मुझे बताओ, आपने किसी कतार या किसी प्रकार की सामान्य बस का प्रयास क्यों नहीं किया? चूँकि आप कहते हैं कि एसिंक्रोनी के साथ आप स्वयं लॉग को कतार के माध्यम से भेज सकते हैं और कतार के माध्यम से एसिंक्रोनस रूप से प्रतिक्रिया प्राप्त कर सकते हैं?

Y N: - कृपया सुझाव दें कि किन कतारों का उपयोग किया जा सकता है?

जेड: - कोई भी, इस बात की गारंटी के बिना भी कि वे क्रम में हैं। किसी प्रकार की रेडिस, आरएमक्यू...

Y N: - मुझे लगता है कि रेडिस संभवतः एक होस्ट (कई सर्वरों के अर्थ में) पर भी इतनी मात्रा में सम्मिलन खींचने में सक्षम नहीं होगा जो क्लिकहाउस को बाहर खींचता है। मैं किसी भी सबूत के साथ इसका समर्थन नहीं कर सकता (मैंने इसे बेंचमार्क नहीं किया है), लेकिन मुझे ऐसा लगता है कि रेडिस यहां सबसे अच्छा समाधान नहीं है। सिद्धांत रूप में, इस प्रणाली को एक तात्कालिक संदेश कतार के रूप में माना जा सकता है, लेकिन इसे केवल "क्लिकहाउस" के लिए तैयार किया गया है।

संचालक: - यूरी, आपका बहुत-बहुत धन्यवाद। मैं प्रश्नों और उत्तरों को यहीं समाप्त करने का प्रस्ताव करता हूं और कहता हूं कि प्रश्न पूछने वालों में से हम किसको पुस्तक देंगे।

Y N: - मैं प्रश्न पूछने वाले पहले व्यक्ति को एक किताब देना चाहूँगा।

संचालक: - आश्चर्यजनक! महान! आश्चर्यजनक! बहुत-बहुत धन्यवाद!

कुछ विज्ञापन 🙂

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक रोचक सामग्री देखना चाहते हैं? आदेश देकर या मित्रों को अनुशंसा करके हमारा समर्थन करें, डेवलपर्स के लिए क्लाउड VPS $4.99 से शुरू, प्रवेश स्तर के सर्वरों का एक अनूठा एनालॉग, जिसका आविष्कार हमने आपके लिए किया था: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $19 से या सर्वर कैसे साझा करें? (RAID1 और RAID10 के साथ उपलब्ध, 24 कोर तक और 40GB DDR4 तक)।

एम्स्टर्डम में इक्विनिक्स टियर IV डेटा सेंटर में Dell R730xd 2x सस्ता है? केवल यहां 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीवी $199 से नीदरलैंड में! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 से! के बारे में पढ़ा इन्फ्रास्ट्रक्चर कॉर्प का निर्माण कैसे करें। एक पैसा के लिए 730 यूरो मूल्य के डेल R5xd E2650-4 v9000 सर्वर के उपयोग के साथ वर्ग?

स्रोत: www.habr.com