ClickHouse में स्ट्रिंग ऑप्टिमाइज़ेशन। यैंडेक्स रिपोर्ट

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


- सबसे पहले, आइए देखें कि आप स्ट्रिंग्स को कैसे स्टोर कर सकते हैं।



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



बेशक, कभी-कभी कुछ धीमा हो जाता है। मान लीजिए आप एक टेबल पर एक प्रश्न बना रहे हैं। ClickHouse कुछ बड़ी मात्रा में डेटा पढ़ता है, कहते हैं, 100 GB / s की गति से, कुछ लाइनों को संसाधित किया जा रहा है। हमारे पास दो टेबल हैं जो लगभग समान डेटा स्टोर करते हैं। ClickHouse दूसरी तालिका के डेटा को उच्च गति से पढ़ता है, लेकिन यह प्रति सेकंड तीन गुना कम पंक्तियों को पढ़ता है।



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



यहाँ एक और उदाहरण है। मान लीजिए कि लाइनों का एक पूर्व निर्धारित सेट है, यह 1000 या 10,000 के निरंतर तक सीमित है और लगभग कभी नहीं बदलता है। इस मामले के लिए, Enum डेटा प्रकार हमारे लिए उपयुक्त है, ClickHouse में उनमें से दो हैं - Enum8 और Enum16। एनम में भंडारण के कारण, हम जल्दी से अनुरोधों को संसाधित करते हैं।

ClickHouse में ग्रुप BY, IN, DISTINCT और कुछ कार्यों के लिए अनुकूलन के लिए त्वरण हैं, उदाहरण के लिए, एक निरंतर स्ट्रिंग के साथ तुलना के लिए। बेशक, स्ट्रिंग में संख्याओं को परिवर्तित नहीं किया जाता है, लेकिन, इसके विपरीत, निरंतर स्ट्रिंग को मान Enum में बदल दिया जाता है। उसके बाद, सब कुछ जल्दी से तुलना की जाती है।

लेकिन इसके नुकसान भी हैं। यहां तक ​​कि अगर हम लाइनों के सटीक सेट को जानते हैं, तो कभी-कभी इसे फिर से भरना चाहिए। एक नई लाइन आ गई है - हमें ALTER करना है।



ClickHouse में Enum के लिए बेहतर रूप से कार्यान्वित किया जाता है। हम डिस्क पर डेटा को अधिलेखित नहीं करते हैं, लेकिन ALTER इस तथ्य के कारण धीमा हो सकता है कि Enum संरचनाएं तालिका के स्कीमा में ही संग्रहीत हैं। इसलिए, हमें तालिका से पढ़ने के अनुरोधों का इंतजार करना चाहिए, उदाहरण के लिए।

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



ALTER Enum के साथ खिलवाड़ नहीं करने के लिए, आप बाहरी ClickHouse शब्दकोशों का उपयोग कर सकते हैं। आपको याद दिला दूं कि यह ClickHouse के अंदर एक महत्वपूर्ण-मूल्य डेटा संरचना है, जिसके साथ आप बाहरी स्रोतों से डेटा प्राप्त कर सकते हैं, उदाहरण के लिए, MySQL तालिकाओं से।

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

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

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



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

शब्दावली स्ट्रिंग एन्कोडिंग

इसलिए हम ClickHouse - LowCardinality में एक नए डेटा प्रकार के निर्माण के लिए आए। यह डेटा संग्रहीत करने का एक प्रारूप है: उन्हें डिस्क पर कैसे लिखा जाता है और उन्हें कैसे पढ़ा जाता है, उन्हें स्मृति में कैसे प्रस्तुत किया जाता है और उनके प्रसंस्करण की योजना।



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

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

LowCardinality एक पैरामीट्रिक डेटा प्रकार है। यह या तो एक संख्या हो सकती है, या कुछ ऐसा है जो एक संख्या के रूप में संग्रहीत किया जाता है, या एक स्ट्रिंग, या उनसे अशक्त है।



LowCardinality की ख़ासियत यह है कि इसे कुछ कार्यों के लिए बचाया जा सकता है। एक उदाहरण अनुरोध स्लाइड पर दिखाया गया है। पहली पंक्ति में, मैंने String से निम्न LowCardinality के प्रकार का एक कॉलम बनाया, इसका नाम S. तब मैंने उसका नाम पूछा - ClickHouse ने कहा कि यह String से LowCardinality थी। ठीक है।

तीसरी पंक्ति लगभग समान है, केवल हमने लंबाई फ़ंक्शन कहा। ClickHouse में, लंबाई फ़ंक्शन UInt64 डेटा प्रकार लौटाता है। लेकिन हमें UInt64 से लोकार्डिनिटी मिली। क्या बात है?



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

अन्य अनुकूलन भी हो सकते हैं, जैसे कि साधारण कैश जोड़ना। किसी फ़ंक्शन के मूल्य की गणना करते समय, आप इसे याद कर सकते हैं और इसे समान बना सकते हैं, फिर से गणना न करें।

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



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

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

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

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



LowCardinality के फायदों के बारे में बोलने से पहले, मैं तुरंत कहता हूं कि हम डिस्क पर कम डेटा प्राप्त करने की संभावना नहीं है (हालांकि ऐसा हो सकता है), क्योंकि ClickHouse डेटा को संपीड़ित करता है। एक डिफ़ॉल्ट विकल्प है - LZ4। आप ZSTD का उपयोग करके संपीड़न भी कर सकते हैं। लेकिन दोनों एल्गोरिदम पहले से ही शब्दकोश संपीड़न को लागू करते हैं, इसलिए हमारा बाहरी ClickHouse शब्दकोश ज्यादा मदद नहीं करेगा।

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

यदि आप PhoneModel लेते हैं, तो उनमें से 48 हजार से अधिक हैं, और स्ट्रिंग और लोकार्डिनिटी (स्ट्रिंग) के बीच लगभग कोई अंतर नहीं है। URL के लिए, हमने केवल 2 जीबी बचाई है - मुझे लगता है कि आपको इस पर भरोसा नहीं करना चाहिए।

काम की गति का अनुमान

^{_{स्लाइड से लिंक करें}}

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



मैंने पहला अनुरोध काफी सरल किया - मैंने पूछा कि टैक्सियों को सबसे अधिक बार कहां ऑर्डर किया जाता है। ऐसा करने के लिए, आपको उस स्थान को लेने की आवश्यकता है जहां से आपने आदेश दिया था, उस पर GROUP BY बनाएं और गणना फ़ंक्शन की गणना करें। यहाँ ClickHouse कुछ देता है।



क्वेरी प्रसंस्करण की गति को मापने के लिए, मैंने एक ही डेटा के साथ तीन तालिकाओं का निर्माण किया, लेकिन हमारे प्रारंभ स्थान के लिए तीन अलग-अलग डेटा प्रकारों का उपयोग किया - स्ट्रिंग, लोकर्डिनिटी और एनम। LowCardinality और Enum, स्ट्रिंग की तुलना में पाँच गुना तेज हैं। एनम तेज है क्योंकि यह संख्याओं के साथ काम करता है। लो-कार्डिनलिटी - क्योंकि ग्रुप बाय ऑप्टिमाइज़ेशन लागू किया गया है।



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



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

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



आइए आखिरी अनुरोध को देखें, अधिक कृत्रिम। हम केवल अपने स्थान से हैश फ़ंक्शन की गणना करेंगे। हैश फ़ंक्शन एक धीमी गति से अनुरोध है, इसमें लंबा समय लगता है, इसलिए सब कुछ तीन बार धीमा हो जाएगा।



LowCardinality अभी भी तेज है, हालांकि कोई फ़िल्टरिंग नहीं है। यह इस तथ्य के कारण है कि हमारे कार्य केवल शब्दकोश पर काम करते हैं। हैश गणना फ़ंक्शन का एक तर्क है - यह कम डेटा को संसाधित कर सकता है और लोकार्डर्डिनिटी भी लौटा सकता है।



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