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

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

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

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



अतिरिक्त संसाधन: ELK, बिग क्वेरी और TimescaleDB के लिए एक विकल्प के रूप में Clickhouse का उपयोग करना

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

लॉग क्या हैं और उन्हें क्यों इकट्ठा करते हैं?

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



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



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



लॉग क्या हैं? यह एक इंजन है जो खाली सरण देता है। "VK" में इंजन वे होते हैं जिन्हें अन्य लोग माइक्रोसेवा कहते हैं। और ऐसा स्टिकर मुस्कुरा रहा है (काफी पसंद किया जाता है)। ऐसा कैसे? अच्छा, सुनो!



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

Clickhouse और प्रतियोगियों: आवश्यकताओं और अवसरों

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



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



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



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

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



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



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



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

हम कैसे करेंगे एम्बेड? MergeTree

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



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

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



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

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



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

बफर टेबल के साथ काम करें

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



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

Kittenhouse क्या है और यह कैसे काम करता है?

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



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



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

Nginx जोड़ें

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



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



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

निर्णय से एक कदम

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



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



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

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

मैंने फैसला किया कि हमें इसे स्वयं प्रबंधित करने की आवश्यकता है, इसे नगनेक्स को न दें - नग्नेक्स को पता नहीं है कि "क्लिकहाउस" में क्या तालिकाओं हैं, और नगणक्स को एक रिवर्स प्रॉक्सी के साथ बदल दिया, जिसे मैंने भी लिखा था।



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



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



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



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

खूनी - अस्थायी समाधान, बिल्ली का बच्चा - स्थायी

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

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



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

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

बफर टेबल उदास है

हाल ही में, हम बफर टेबल की एक और दिलचस्प विशेषता के साथ आए। और यह समस्या पहले से ही बाकी की तुलना में बहुत अधिक दर्दनाक है। : «», «», , (, 60 ); Alter … «», «», , «» – , - , «» . ? ?



, , , . , , , «» ( – , , ), … , «» ( - «» ) – , - : ( , ), «» , - , . , «», – .



(, ) – «» query_thread_log. , - . 840 (100 ). , (, , , ) «» (inserts). , «» – «» . , – , . क्यों? , ! .



, ? «». .

«KitttenHouse»

, ? . ! : , , - . , .



, «», – , (, - ) , , – .



? . , , 10 , – -, , . , , , , – , «», 100 - – , , , . , . , .

, , . : , - , , , read only . ? . – - , - … ( , «», ClickHouse) ? ? , . . : , . , . .

. . , - ?.. «»? - … «»? , , . , . , .



– . , . , : , , ( ), – , .



Sequel Pro, «», . : «, -?» ? 2018-? , «» (MySQL) , «», ! «», – , .



, , , , , , , , affected rows ( ), . .



. «», . - - . .

«»

, «», , . , , – . , … , , .



TCP? , «» UDP. TCP… , , : «, ! , UDP». , TCP . , , – - ; , .

«» «» HighLoad Siberia, « »… , … , , . - , - , – , ( , , ). . ! Github . «» .



: – , . , VHS.

( – ): – VHS, ?



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

सवाल

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

संयुक्त राष्ट्र: - किसकी मात्रा?

Z: - अक्षर t। कहीं तीन टी हैं, तो कहीं तीन टी।

संयुक्त राष्ट्र: - क्या मैंने वास्तव में इसे सही किया है? ठीक है, यह करता है! ये विभिन्न उत्पाद हैं - मैं इस समय आपसे केवल झूठ बोल रहा हूं। ठीक है, मैं मज़ाक कर रहा हूँ - यह नहीं है। आह, यहाँ! नहीं, यह वही बात है, मैं इसे सील कर रहा हूं।



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

संयुक्त राष्ट्र: - हाँ।

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

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

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

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

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

संयुक्त राष्ट्र: - हम टीसीपी का उपयोग क्या करते हैं?

Z: - वास्तव में, हाँ।

संयुक्त राष्ट्र: - नहीं।

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

संयुक्त राष्ट्र: - किसके साथ?



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

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

Z: - बस सुविधाजनक! ठीक है और कुछ भी उम्मीद न करें - आपके पास बिल्कुल अतुल्यकालिक है। एक नोटिस वापस आया कि सब कुछ ठीक है - इसका मतलब है कि यह आ गया है; नहीं आया - इसका मतलब बुरा है।

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

Z: - मैं समय नहीं लूंगा। इस पर लंबे समय तक चर्चा होनी चाहिए। आपका धन्यवाद

प्रस्तुतकर्ता: - जिसके पास प्रश्न हैं - आकाश में कलम!



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

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

Z: - लेकिन अंत में यह वैसे भी निकला।

संयुक्त राष्ट्र: - नहीं, कोई मेजबान नहीं हैं! यह सब Clickhouse होस्ट पर काम करता है।

Z: - लेकिन काटनहाउस के बारे में क्या, जिसका उल्टा है - वह कहाँ रहता है?



संयुक्त राष्ट्र: - क्लिकहाउस की मेजबानी में, वह डिस्क के लिए कुछ भी नहीं लिखता है।

Z: - अच्छा, चलिए बताते हैं।

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

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

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

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



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

Z: - कोई भी, बिना गारंटी के भी कि वे क्रम में जा रहे हैं। किसी भी Redis, RMQ ...

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

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

संयुक्त राष्ट्र: - मैं पहले व्यक्ति को एक पुस्तक देना चाहूँगा जिसने एक प्रश्न पूछा था।

प्रस्तुतकर्ता: - महान! बहुत बढ़िया! वाह! बहुत बहुत धन्यवाद!

विज्ञापन का एक सा :)

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

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