ClickHouse को प्रभावकारी प्रयोग। एलेक्सी मिलोविडोभ (यान्डेक्स)

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

नमस्ते सबै! मेरो नाम एलेक्सी हो, म क्लिकहाउस बनाउँछु।

सर्वप्रथम, म तपाईंलाई तुरुन्तै खुसी पार्न हतार गर्छु, आज म तपाईंलाई क्लिकहाउस के हो भनेर बताउँदिन। इमानदार हुन, म यो थकित छु। हरेक पटक म तिमीलाई यो के हो भन्छु। र सायद सबैलाई पहिले नै थाहा छ।

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

तर तपाईले अझै पनि ध्यानमा राख्नु पर्छ कि यो प्रणाली विशेष छ र तपाईले सजिलैसँग असामान्य प्रयोगको मामलामा आउन सक्नुहुन्छ जसले यस प्रणालीलाई यसको आराम क्षेत्रबाट बाहिर लैजान्छ।

त्यसोभए, त्यहाँ कस्तो प्रकारको रेक छ? प्रायः म स्पष्ट चीजहरूको बारेमा कुरा गर्नेछु। सबैलाई सबै कुरा स्पष्ट छ, सबैले सबै कुरा बुझ्छन् र खुसी हुन सक्छन् कि तिनीहरू धेरै स्मार्ट छन्, र जसले बुझ्दैनन् उनीहरूले केहि नयाँ सिक्नेछन्।

पहिलो र सरल उदाहरण, जुन, दुर्भाग्यवश, अक्सर हुन्छ, सानो ब्याच, अर्थात् सानो सम्मिलित को एक ठूलो संख्या संग सम्मिलित को एक ठूलो संख्या हो।

यदि हामीले क्लिकहाउसले कसरी इन्सर्ट गर्छ भनेर विचार गर्यौं भने, तपाइँ एक अनुरोधमा कम्तिमा एक टेराबाइट डाटा पठाउन सक्नुहुन्छ। यो कुनै समस्या छैन।

र हेरौं कि सामान्य प्रदर्शन कस्तो हुनेछ। उदाहरणका लागि, हामीसँग Yandex.Metrica डेटाबाट तालिका छ। हिटहरू। 105 केही स्तम्भहरू। 700 बाइट असम्पीडित। र हामी एक मिलियन पङ्क्तिहरूको ब्याचहरूमा राम्रो तरिकाले सम्मिलित गर्नेछौं।

हामी तालिकामा MergeTree सम्मिलित गर्छौं, यसले प्रति सेकेन्ड आधा मिलियन पङ्क्तिहरू निकाल्छ। महान। प्रतिलिपि गरिएको तालिकामा यो थोरै सानो हुनेछ, लगभग 400 पङ्क्तिहरू प्रति सेकेन्ड।

र यदि तपाईंले कोरम सम्मिलन सक्षम गर्नुभयो भने, तपाईंले थोरै कम, तर अझै राम्रो प्रदर्शन, प्रति सेकेन्ड 250 सर्तहरू प्राप्त गर्नुहुन्छ। कोरम सम्मिलन क्लिकहाउस* मा एक अप्रमाणित सुविधा हो।

* २०२० को अनुसार, पहिले नै दस्तावेज.

नराम्रो काम गरे के हुन्छ ? हामी MergeTree तालिकामा एउटा पङ्क्ति घुसाउँछौं र प्रति सेकेन्ड 59 पङ्क्तिहरू पाउँछौं। त्यो 10 गुणा ढिलो छ। ReplicatedMergeTree मा - 000 पङ्क्ति प्रति सेकेन्ड। र यदि कोरम सक्रिय छ भने, त्यसपछि यो प्रति सेकेन्ड 6 लाइनहरू बाहिर निस्कन्छ। मेरो विचारमा, यो एक प्रकारको निरपेक्ष बकवास हो। तपाईं कसरी यसरी ढिलो गर्न सक्नुहुन्छ? मैले मेरो टी-शर्टमा पनि लेखेको छु कि क्लिकहाउस ढिलो हुनु हुँदैन। तर, कहिलेकाहीँ यस्तो हुने गर्छ ।

वास्तवमा यो हाम्रो कमजोरी हो । हामीले सजिलैसँग सबै कुरा राम्रो बनाउन सक्थ्यौं, तर हामीले गरेनौं। र हामीले यो गरेनौं किनभने हाम्रो स्क्रिप्टलाई आवश्यक थिएन। हामीसँग पहिले नै बुचहरू थिए। हामीले भर्खरै हाम्रो प्रवेशद्वारमा ब्याचहरू प्राप्त गर्यौं, र कुनै समस्या छैन। हामी यसलाई सम्मिलित गर्छौं र सबै कुरा राम्रोसँग काम गर्दछ। तर, अवश्य पनि, सबै प्रकारका परिदृश्यहरू सम्भव छन्। उदाहरणका लागि, जब तपाईंसँग सर्भरहरूको गुच्छा हुन्छ जसमा डाटा उत्पन्न हुन्छ। र तिनीहरू प्रायः डेटा सम्मिलित गर्दैनन्, तर तिनीहरू अझै पनि बारम्बार सम्मिलित हुन्छन्। र हामीले यसबाट जोगिन आवश्यक छ।

प्राविधिक दृष्टिकोणबाट, बिन्दु यो हो कि जब तपाइँ क्लिकहाउसमा सम्मिलित गर्नुहुन्छ, डाटा कुनै पनि मेमटेबलमा समाप्त हुँदैन। हामीसँग वास्तविक लग संरचना MergeTree पनि छैन, तर केवल एक MergeTree, किनभने त्यहाँ न त लग छ न मेमटेबल। हामी तुरुन्तै फाइल प्रणालीमा डाटा लेख्छौं, पहिले नै स्तम्भहरूमा व्यवस्थित। र यदि तपाइँसँग 100 स्तम्भहरू छन् भने, त्यसपछि 200 भन्दा बढी फाइलहरू छुट्टै डाइरेक्टरीमा लेख्न आवश्यक पर्दछ। यो सबै धेरै झन्झटिलो छ।

र प्रश्न उठ्छ: "यसलाई कसरी सही गर्ने?" यदि स्थिति यस्तो छ कि तपाइँ अझै पनि क्लिकहाउसमा डाटा रेकर्ड गर्न आवश्यक छ।

विधि 1. यो सबैभन्दा सजिलो तरिका हो। केहि प्रकारको वितरित लाम प्रयोग गर्नुहोस्। उदाहरणका लागि, काफ्का। तपाईं केवल काफ्काबाट डाटा निकाल्नुहोस् र सेकेन्डमा एक पटक ब्याच गर्नुहोस्। र सबै कुरा ठीक हुनेछ, तपाईं रेकर्ड, सबै कुरा राम्रो काम गर्दछ।

बेफाइदाहरू छन् कि काफ्का अर्को ठूलो वितरण प्रणाली हो। म यो पनि बुझ्छु कि तपाईको कम्पनीमा काफ्का पहिले नै छ भने। यो राम्रो छ, यो सुविधाजनक छ। तर यदि यो अवस्थित छैन भने, तपाईंले आफ्नो परियोजनामा ​​अर्को वितरित प्रणाली तान्नु अघि तीन पटक सोच्नुपर्छ। र त्यसैले यो विकल्पहरू विचार गर्न लायक छ।

विधि 2. यो पुरानो विद्यालयको विकल्प हो र एकै समयमा धेरै सरल छ। के तपाइँसँग केहि प्रकारको सर्भर छ जसले तपाइँको लगहरू उत्पन्न गर्दछ। र यसले तपाईको लगहरू फाइलमा लेख्छ। र एक सेकेन्डमा एक पटक, उदाहरणका लागि, हामी यो फाइलको नाम परिवर्तन गर्छौं र नयाँ फाईल। र एउटा छुट्टै लिपि, या त क्रोन वा केही डेमन मार्फत, सबैभन्दा पुरानो फाइल लिन्छ र क्लिकहाउसमा लेख्छ। यदि तपाइँ एक सेकेन्डमा एक पटक लगहरू रेकर्ड गर्नुहुन्छ भने, त्यसपछि सबै ठीक हुनेछ।

तर यस विधिको बेफाइदा यो हो कि यदि तपाईको सर्भर जसमा लगहरू उत्पन्न हुन्छ कतै गायब हुन्छ, त्यसपछि डाटा पनि गायब हुनेछ।

विधि 3. त्यहाँ अर्को रोचक विधि छ, जसलाई अस्थायी फाइलहरू आवश्यक पर्दैन। उदाहरण को लागी, तपाइँसँग केहि प्रकारको विज्ञापन स्पिनर वा केहि अन्य रोचक डेमन छ जसले डेटा उत्पन्न गर्दछ। र तपाइँ बफर मा, RAM मा सीधा डाटा को गुच्छा संकलन गर्न सक्नुहुन्छ। र जब पर्याप्त समय बितिसकेको छ, तपाईले यो बफरलाई अलग राख्नुहुन्छ, नयाँ बनाउनुहोस्, र छुट्टै थ्रेडमा, क्लिकहाउसमा पहिले नै जम्मा भएको कुरा घुसाउनुहोस्।

अर्कोतर्फ, डेटा पनि किल -9 संग गायब हुन्छ। यदि तपाईंको सर्भर क्र्यास भयो भने, तपाईंले यो डाटा गुमाउनु हुनेछ। र अर्को समस्या यो हो कि यदि तपाइँ डाटाबेसमा लेख्न असमर्थ हुनुहुन्छ भने, तपाइँको डाटा RAM मा जम्मा हुनेछ। र या त RAM समाप्त हुनेछ, वा तपाइँ केवल डाटा गुमाउनुहुनेछ।

विधि 4. अर्को रोचक विधि। के तपाइँसँग केहि प्रकारको सर्भर प्रक्रिया छ। र यसले तुरुन्तै क्लिकहाउसमा डाटा पठाउन सक्छ, तर यसलाई एक जडानमा गर्नुहोस्। उदाहरणका लागि, मैले ट्रान्सफर-इन्कोडिङको साथ HTTP अनुरोध पठाएँ: घुसाउनुहोस्। र यसले धेरै कम मात्रामा टुक्राहरू उत्पन्न गर्दछ, तपाइँ प्रत्येक लाइन पठाउन सक्नुहुन्छ, यद्यपि यो डेटा फ्रेमिङको लागि ओभरहेड हुनेछ।

यद्यपि, यस अवस्थामा डाटा तुरून्त क्लिकहाउसमा पठाइनेछ। र क्लिकहाउसले तिनीहरूलाई आफैं बफर गर्नेछ।

तर समस्या पनि आउँछन् । अब तपाईले डेटा गुमाउनु हुनेछ, तपाईको प्रक्रिया कहिले मारिएको छ र यदि क्लिकहाउस प्रक्रिया मारिएको छ भने, किनभने यो अपूर्ण सम्मिलित हुनेछ। र ClickHouse सम्मिलितहरू पङ्क्तिहरूको आकारमा निश्चित निर्दिष्ट थ्रेसहोल्डसम्म परमाणु हुन्छन्। सिद्धान्त मा, यो एक रोचक तरिका हो। पनि प्रयोग गर्न सकिन्छ।

विधि 5. यहाँ अर्को रोचक विधि छ। यो डाटा ब्याचिङको लागि समुदाय-विकसित सर्भर को एक प्रकार हो। मैले यसलाई आफैले हेरेको छैन, त्यसैले म केहि ग्यारेन्टी गर्न सक्दिन। यद्यपि, क्लिकहाउसको लागि कुनै ग्यारेन्टी प्रदान गरिएको छैन। यो खुला स्रोत पनि हो, तर अर्कोतर्फ, हामीले उपलब्ध गराउने प्रयास गरेका केही गुणस्तरीय मानकमा तपाईलाई प्रयोग गर्न सकिन्छ। तर यस कुराको लागि - मलाई थाहा छैन, GitHub मा जानुहोस्, कोड हेर्नुहोस्। सायद तिनीहरूले केहि सामान्य लेखे।

* २०२० को रूपमा, पनि विचारमा थपिनु पर्छ KittenHouse.

विधि 6. अर्को विधि भनेको बफर तालिकाहरू प्रयोग गर्नु हो। यस विधिको फाइदा यो प्रयोग गर्न सुरु गर्न धेरै सजिलो छ। एउटा बफर तालिका बनाउनुहोस् र यसमा घुसाउनुहोस्।

समस्या पूर्ण रूपमा समाधान नहुनु समस्या हो। यदि, MergeTree जस्तै दरमा, तपाईंले डेटालाई प्रति सेकेन्ड एक ब्याचमा समूहबद्ध गर्नुपर्छ भने, बफर तालिकाको दरमा, तपाईंले कम्तिमा धेरै हजार प्रति सेकेन्डसम्म समूहबद्ध गर्नुपर्छ। यदि यो प्रति सेकेन्ड 10 भन्दा बढी छ भने, यो अझै खराब हुनेछ। र यदि तपाइँ यसलाई ब्याचहरूमा सम्मिलित गर्नुहुन्छ भने, तपाईंले देख्नुभयो कि यो प्रति सेकेन्ड एक लाख लाइनहरू हुन्छ। र यो पहिले नै पर्याप्त भारी डाटा मा छ।

र बफर तालिकाहरूमा लग छैन। र यदि तपाइँको सर्भरमा केहि गलत छ भने, त्यसपछि डाटा हराउनेछ।

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

र यो अवसरको बारेमा विशेष गरी मनमोहक कुरा यो हो कि यो गर्ने हामी थिएनौं। यो एक समुदाय विशेषता हो। र जब म "सामुदायिक विशेषता" भन्छु, मेरो मतलब यो कुनै अपमान बिना। हामीले कोड पढ्यौं, समीक्षा गर्यौं, यसले राम्रोसँग काम गर्नुपर्छ।

* 2020 को रूपमा, समान समर्थन को लागी देखा पर्यो खरगोश MQ.

डेटा सम्मिलित गर्दा अरू के असुविधाजनक वा अप्रत्याशित हुन सक्छ? यदि तपाइँ एक सम्मिलित मान अनुरोध गर्नुहुन्छ र मानहरूमा केहि गणना अभिव्यक्तिहरू लेख्नुहोस्। उदाहरण को लागी, now() पनि गणना गरिएको अभिव्यक्ति हो। र यस अवस्थामा, ClickHouse लाई प्रत्येक रेखामा यी अभिव्यक्तिहरूको अनुवादक सुरु गर्न बाध्य पारिएको छ, र कार्यसम्पादन परिमाणको अर्डरले घट्नेछ। यसबाट बच्नु राम्रो हुन्छ।

* यस समयमा, समस्या पूर्ण रूपमा समाधान भएको छ, VALUES मा अभिव्यक्तिहरू प्रयोग गर्दा अब कुनै प्रदर्शन रिग्रेसन छैन।

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

* हालसालै, प्रयोगात्मक मोडमा, ClickHouse ले लेखन-अगाडि लगको साथ RAM मा टुक्रा र टुक्राहरूको कम्प्याक्ट ढाँचाको लागि समर्थन थप्यो, जसले लगभग पूर्ण रूपमा समस्या समाधान गर्दछ।

अब दोस्रो प्रकारको समस्या हेरौं - डाटा टाइपिङ।

डाटा टाइप कडा वा स्ट्रिङ हुन सक्छ। स्ट्रिङ भनेको तपाईंले भर्खरै लिनुभयो र घोषणा गर्नुभयो कि तपाईंको सबै क्षेत्रहरू प्रकारको स्ट्रिङका छन्। यो बेकार छ। यो गर्न आवश्यक छैन।

ती अवस्थाहरूमा यसलाई कसरी सही तरिकाले गर्ने भनेर पत्ता लगाउनुहोस् जब तपाईं हामीसँग केही फिल्ड, स्ट्रिङ छ भनेर भन्न चाहनुहुन्छ, र क्लिकहाउसलाई यसलाई आफैंले पत्ता लगाउन दिनुहोस्, र म चिन्ता लिने छैन। तर यो अझै पनि केहि प्रयास गर्न लायक छ।

उदाहरणका लागि, हामीसँग IP ठेगाना छ। एउटा अवस्थामा, हामीले यसलाई स्ट्रिङको रूपमा सुरक्षित गर्यौं। उदाहरण को लागी, 192.168.1.1। र अर्को मामला मा, यो UInt32 * को एक संख्या हुनेछ। IPv32 ठेगानाको लागि 4 बिट पर्याप्त छ।

पहिलो, अनौठो रूपमा पर्याप्त, डाटा लगभग समान रूपमा संकुचित हुनेछ। त्यहाँ भिन्नता हुनेछ, अवश्य पनि, तर ठूलो छैन। त्यसैले डिस्क I/O सँग कुनै विशेष समस्याहरू छैनन्।

तर प्रोसेसर समय र क्वेरी कार्यान्वयन समय मा एक गम्भीर भिन्नता छ।

यदि तिनीहरू संख्याको रूपमा भण्डारण गरिएका छन् भने अद्वितीय IP ठेगानाहरूको संख्या गणना गरौं। त्यो प्रति सेकेन्ड 137 मिलियन लाइनहरूमा काम गर्दछ। यदि समान स्ट्रिङको रूपमा छ भने, प्रति सेकेन्ड 37 मिलियन लाइनहरू। यो संयोग किन भयो मलाई थाहा छैन। यी अनुरोधहरू मैले आफैं पूरा गरें। तर अझै पनि करिब ४ गुणा ढिलो।

र यदि तपाइँ डिस्क स्पेसमा भिन्नता गणना गर्नुहुन्छ भने, त्यहाँ पनि भिन्नता छ। र भिन्नता लगभग एक चौथाई हो, किनभने त्यहाँ धेरै अद्वितीय आईपी ठेगानाहरू छन्। र यदि त्यहाँ फरक अर्थहरूको सानो संख्याको साथ लाइनहरू थिए भने, तिनीहरू सजिलैसँग लगभग समान भोल्युममा शब्दकोश अनुसार संकुचित हुनेछन्।

र चार गुणा समय भिन्नता सडकमा छैन। हुनसक्छ तपाईलाई धिक्कार छैन, पक्कै पनि, तर जब म यस्तो भिन्नता देख्छु, यसले मलाई दुखी तुल्याउँछ।

विभिन्न केसहरू हेरौं।

1. एक केस जब तपाईंसँग केहि फरक अद्वितीय मानहरू छन्। यस अवस्थामा, हामी एक साधारण अभ्यास प्रयोग गर्दछौं जुन तपाईलाई थाहा छ र कुनै पनि DBMS को लागी प्रयोग गर्न सक्नुहुन्छ। यो सबैले क्लिकहाउसको लागि मात्र होइन। डाटाबेसमा संख्यात्मक पहिचानकर्ताहरू मात्र लेख्नुहोस्। र तपाइँ स्ट्रिङमा रूपान्तरण गर्न सक्नुहुन्छ र तपाइँको अनुप्रयोगको छेउमा।

उदाहरणका लागि, तपाईंसँग एउटा क्षेत्र छ। र तपाइँ यसलाई स्ट्रिङको रूपमा बचत गर्न प्रयास गर्दै हुनुहुन्छ। र त्यहाँ लेखिनेछ: मस्को र मस्को क्षेत्र। र जब म देख्छु कि यसले "मस्को" भन्छ, यो केहि होइन, तर जब यो मस्को हो, यो कुनै न कुनै रूपमा पूर्ण रूपमा उदास हुन्छ। यो कति बाइट्स हो।

यसको सट्टा, हामी केवल Ulnt32 र 250 नम्बर लेख्छौं। हामीसँग Yandex मा 250 छ, तर तपाईंको फरक हुन सक्छ। केवल केसमा, म भन्छु कि क्लिकहाउससँग जियोबेससँग काम गर्ने अन्तर्निहित क्षमता छ। तपाईले केवल क्षेत्रहरू सहितको डाइरेक्टरी लेख्नुहुन्छ, एक श्रेणीबद्ध सहित, अर्थात् त्यहाँ मस्को, मस्को क्षेत्र, र तपाईलाई चाहिने सबै कुरा हुनेछ। र तपाइँ अनुरोध स्तर मा रूपान्तरण गर्न सक्नुहुन्छ।

दोस्रो विकल्प लगभग समान छ, तर ClickHouse भित्र समर्थन संग। यो Enum डाटा प्रकार हो। तपाईले Enum भित्र चाहिने सबै मानहरू मात्र लेख्नुहोस्। उदाहरणका लागि, उपकरणको प्रकार र त्यहाँ लेख्नुहोस्: डेस्कटप, मोबाइल, ट्याब्लेट, टिभी। त्यहाँ कुल 4 विकल्पहरू छन्।

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

* ClickHouse को नवीनतम संस्करणहरूमा, ALTER पूर्ण रूपमा गैर-ब्लक गरिएको छ।

अर्को विकल्प जो ClickHouse को लागी एकदम अद्वितीय छ बाह्य शब्दकोश जडान गर्दै। तपाइँ क्लिकहाउसमा नम्बरहरू लेख्न सक्नुहुन्छ, र तपाइँको लागि सुविधाजनक प्रणालीमा तपाइँको निर्देशिकाहरू राख्न सक्नुहुन्छ। उदाहरण को लागी, तपाइँ प्रयोग गर्न सक्नुहुन्छ: MySQL, Mongo, Postgres। तपाइँ तपाइँको आफ्नै माइक्रोसर्भिस पनि सिर्जना गर्न सक्नुहुन्छ जसले यो डाटा http मार्फत पठाउनेछ। र क्लिकहाउस स्तरमा, तपाईले एउटा प्रकार्य लेख्नुहुन्छ जसले यो डेटालाई संख्याबाट स्ट्रिङमा रूपान्तरण गर्नेछ।

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

यहाँ एउटा उदाहरण हो। त्यहाँ Yandex.Direct छ। र त्यहाँ एक विज्ञापन कम्पनी र ब्यानर छ। त्यहाँ शायद लाखौं विज्ञापन कम्पनीहरू छन्। र तिनीहरू लगभग RAM मा फिट छन्। र त्यहाँ अरबौं ब्यानरहरू छन्, तिनीहरू फिट छैनन्। र हामी MySQL बाट क्यास गरिएको शब्दकोश प्रयोग गर्दछौं।

केवल समस्या यो हो कि क्यास गरिएको शब्दकोशले राम्रो काम गर्नेछ यदि हिट दर 100% नजिक छ। यदि यो सानो छ भने, त्यसपछि डाटाको प्रत्येक ब्याचको लागि प्रश्नहरू प्रशोधन गर्दा, तपाईंले वास्तवमा छुटेको कुञ्जीहरू लिनु पर्छ र MySQL बाट डाटा प्राप्त गर्नुपर्नेछ। ClickHouse को बारेमा, म अझै पनि ग्यारेन्टी गर्न सक्छु - हो, यो ढिलो हुँदैन, म अन्य प्रणालीहरूको बारेमा कुरा गर्दिन।

र बोनसको रूपमा, शब्दकोशहरू क्लिकहाउसमा डेटा अपडेट गर्न धेरै सजिलो तरिका हो। त्यो हो, तपाईसँग विज्ञापन कम्पनीहरूको रिपोर्ट थियो, प्रयोगकर्ताले मात्र विज्ञापन कम्पनी परिवर्तन गर्यो र सबै पुरानो डाटामा, सबै रिपोर्टहरूमा, यो डाटा पनि परिवर्तन भयो। यदि तपाइँ तालिकामा सीधा पङ्क्तिहरू लेख्नुहुन्छ भने, तिनीहरूलाई अद्यावधिक गर्न असम्भव हुनेछ।

अर्को तरिका जब तपाइँ तपाइँको स्ट्रिङ को लागी पहिचानकर्ताहरू कहाँ प्राप्त गर्ने थाहा छैन। तपाईं यसलाई सजिलै ह्यास गर्न सक्नुहुन्छ। यसबाहेक, सरल विकल्प 64-बिट ह्यास लिनु हो।

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

र यसरी विज्ञापन कम्पनीहरूको नाम ह्यास गर्नु राम्रो हुनेछैन। यदि विभिन्न कम्पनीहरूको विज्ञापन अभियानहरू मिलाइयो भने, त्यहाँ केहि नबुझेको हुनेछ।

र त्यहाँ एक सरल चाल छ। साँचो, यो गम्भीर डेटाको लागि पनि धेरै उपयुक्त छैन, तर यदि केहि धेरै गम्भीर छैन भने, केवल ग्राहक पहिचानकर्तालाई शब्दकोश कुञ्जीमा थप्नुहोस्। र त्यसपछि तपाइँसँग टक्कर हुनेछ, तर केवल एक ग्राहक भित्र। र हामी Yandex.Metrica मा लिङ्क नक्साहरूको लागि यो विधि प्रयोग गर्दछौं। हामीसँग त्यहाँ URL हरू छन्, हामी ह्यासहरू भण्डार गर्छौं। र हामीलाई थाहा छ, अवश्य पनि, त्यहाँ टक्करहरू छन्। तर जब पृष्ठ प्रदर्शित हुन्छ, सम्भाव्यता कि एक प्रयोगकर्ताको एक पृष्ठमा केहि URL हरू सँगै अड्किएका छन् र यो ध्यान दिइनेछ भनेर बेवास्ता गर्न सकिन्छ।

बोनसको रूपमा, धेरै कार्यहरूका लागि ह्यासहरू मात्र पर्याप्त छन् र स्ट्रिङहरू आफैं कतै भण्डारण गर्न आवश्यक छैन।

अर्को उदाहरण हो यदि तारहरू छोटो छन्, उदाहरणका लागि, वेबसाइट डोमेनहरू। तिनीहरू जस्तै भण्डारण गर्न सकिन्छ। वा, उदाहरणका लागि, ब्राउजर भाषा ru 2 बाइट्स हो। निस्सन्देह, म बाइट्स को लागी साँच्चै माफी मान्छु, तर चिन्ता नगर्नुहोस्, 2 बाइटहरु दया छैन। कृपया यसलाई यथास्थितिमा राख्नुहोस्, चिन्ता नगर्नुहोस्।

अर्को मामला हो जब, यसको विपरित, त्यहाँ धेरै रेखाहरू छन् र तिनीहरूमा धेरै अनौंठो छन्, र सेट पनि सम्भावित रूपमा असीमित छ। एउटा सामान्य उदाहरण खोज वाक्यांश वा URL हरू हो। खोज वाक्यांशहरू, टाइपो सहित। त्यहाँ प्रति दिन कतिवटा अद्वितीय खोज वाक्यांशहरू छन् हेरौं। र यो बाहिर जान्छ कि तिनीहरू सबै घटनाहरूको लगभग आधा हुन्। र यस अवस्थामा, तपाईले सोच्न सक्नुहुन्छ कि तपाईले डेटा सामान्य बनाउन आवश्यक छ, पहिचानकर्ताहरू गणना गर्नुहोस्, र यसलाई छुट्टै तालिकामा राख्नुहोस्। तर तपाईंले त्यसो गर्न आवश्यक छैन। यी रेखाहरू जस्तै राख्नुहोस्।

कुनै पनि कुराको आविष्कार नगर्नु राम्रो हो, किनकि यदि तपाईंले यसलाई छुट्टै भण्डार गर्नुभयो भने, तपाईंले सामेल हुन आवश्यक छ। र यो जडान, सबै भन्दा राम्रो, मेमोरीमा अनियमित पहुँच हो, यदि यो अझै मेमोरीमा फिट हुन्छ। यदि यो मिल्दैन भने, त्यहाँ समस्या हुनेछ।

र यदि डाटा ठाउँमा भण्डारण गरिएको छ भने, त्यसपछि यो फाइल प्रणालीबाट आवश्यक क्रममा पढ्न सकिन्छ र सबै ठीक छ।

यदि तपाइँसँग URL हरू वा केहि अन्य जटिल लामो स्ट्रिङहरू छन् भने, यो विचार गर्न लायक छ कि तपाइँ पहिले नै केहि प्रकारको निकासी गणना गर्न सक्नुहुन्छ र यसलाई छुट्टै स्तम्भमा लेख्न सक्नुहुन्छ।

URL को लागि, उदाहरण को लागी, तपाइँ डोमेन अलग भण्डारण गर्न सक्नुहुन्छ। र यदि तपाईंलाई साँच्चै डोमेन चाहिन्छ भने, त्यसोभए यो स्तम्भ प्रयोग गर्नुहोस्, र URL हरू त्यहाँ रहनेछन्, र तपाईंले तिनीहरूलाई छुने पनि छैन।

के फरक छ हेरौं। क्लिकहाउससँग डोमेन गणना गर्ने विशेष प्रकार्य छ। यो धेरै छिटो छ, हामीले यसलाई अनुकूलित गरेका छौं। र, इमानदार हुन, यसले RFC को पालना पनि गर्दैन, तर जे होस्, यसले हामीलाई चाहिने सबै कुरालाई विचार गर्दछ।

र एक अवस्थामा हामी केवल URL हरू प्राप्त गर्नेछौं र डोमेन गणना गर्नेछौं। त्यो 166 मिलिसेकेन्डमा काम गर्दछ। र यदि तपाइँ एक रेडिमेड डोमेन लिनुभयो भने, त्यसपछि यो केवल 67 मिलिसेकेन्डमा जान्छ, अर्थात् लगभग तीन गुणा छिटो। र यो छिटो होइन किनभने हामीले केही गणनाहरू गर्न आवश्यक छ, तर किनभने हामी कम डेटा पढ्छौं।

यसैले एउटा अनुरोध, जुन ढिलो छ, प्रति सेकेन्ड गीगाबाइटको उच्च गति छ। किनभने यसले धेरै गीगाबाइटहरू पढ्छ। यो पूर्णतया अनावश्यक डाटा हो। अनुरोध छिटो चल्ने देखिन्छ, तर यसलाई पूरा हुन धेरै समय लाग्छ।

र यदि तपाइँ डिस्कमा डाटाको मात्रा हेर्नुहुन्छ भने, यो थाहा हुन्छ कि URL 126 मेगाबाइट हो, र डोमेन मात्र 5 मेगाबाइट हो। यो 25 पटक कम बाहिर जान्छ। तर यद्यपि, अनुरोध मात्र 4 गुणा छिटो कार्यान्वयन गरिएको छ। तर त्यो किनभने डाटा तातो छ। र यदि यो चिसो थियो भने, यो डिस्क I/O को कारणले 25 गुणा छिटो हुनेछ।

वैसे, यदि तपाईंले URL भन्दा डोमेन कति सानो छ भनेर अनुमान गर्नुहुन्छ भने, यो लगभग 4 गुणा सानो हुन्छ। तर कुनै कारणले, डाटाले डिस्कमा 25 गुणा कम लिन्छ। किन? कम्प्रेसनको कारण। र URL कम्प्रेस गरिएको छ, र डोमेन कम्प्रेस गरिएको छ। तर प्रायः URL मा फोहोरको गुच्छा हुन्छ।

र, निस्सन्देह, यसले सही डेटा प्रकारहरू प्रयोग गर्न भुक्तान गर्दछ जुन विशेष रूपमा वांछित मानहरूको लागि डिजाइन गरिएको हो वा उपयुक्त छन्। यदि तपाईं IPv4 मा हुनुहुन्छ भने, UInt32* भण्डार गर्नुहोस्। यदि IPv6, तब FixedString(16), किनभने IPv6 ठेगाना १२८ बिट हो, अर्थात् बाइनरी ढाँचामा सिधै भण्डारण गरिएको छ।

तर के हुन्छ यदि तपाइँसँग कहिलेकाहीँ IPv4 ठेगानाहरू छन् र कहिलेकाहीं IPv6? हो, तपाईं दुवै भण्डारण गर्न सक्नुहुन्छ। एउटा स्तम्भ IPv4 को लागि, अर्को IPv6 को लागि। अवश्य पनि, IPv4 मा IPv6 प्रदर्शन गर्ने विकल्प छ। यसले पनि काम गर्नेछ, तर यदि तपाईंलाई प्रायः अनुरोधहरूमा IPv4 ठेगाना चाहिन्छ भने, यसलाई छुट्टै स्तम्भमा राख्नु राम्रो हुनेछ।

* ClickHouse मा अब छुट्टै IPv4, IPv6 डेटा प्रकारहरू छन् जसले डेटालाई संख्या जत्तिकै कुशलतापूर्वक भण्डारण गर्दछ, तर तिनीहरूलाई स्ट्रिङहरू जस्तै सहज रूपमा प्रतिनिधित्व गर्दछ।

यो नोट गर्न पनि महत्त्वपूर्ण छ कि यो अग्रिम डेटा प्रिप्रोसेस गर्न लायक छ। उदाहरणका लागि, तपाईंले केही कच्चा लगहरू प्राप्त गर्नुभयो। र हुनसक्छ तपाईंले तिनीहरूलाई क्लिकहाउसमा तुरुन्तै राख्नु हुँदैन, यद्यपि यो केहि गर्न धेरै लोभलाग्दो छ र सबै काम हुनेछ। तर यो अझै पनि सम्भव छ कि गणना गर्न लायक छ।

उदाहरण को लागी, ब्राउजर संस्करण। केही नजिकैको विभागमा, जुन म औंला औंल्याउन चाहन्न, ब्राउजर संस्करण यसरी भण्डार गरिएको छ, त्यो हो, स्ट्रिङको रूपमा: 12.3। र त्यसपछि, एक रिपोर्ट बनाउन, तिनीहरूले यो स्ट्रिङ लिन र एक array मा विभाजित, र त्यसपछि array को पहिलो तत्व मा। स्वाभाविक रूपमा, सबै कुरा सुस्त हुन्छ। मैले सोधेँ किन यस्तो गर्छन् । तिनीहरूले मलाई भने कि तिनीहरू समयपूर्व अनुकूलन मन पराउँदैनन्। र मलाई समयपूर्व निराशा मन पर्दैन।

त्यसैले यस अवस्थामा यो 4 स्तम्भहरूमा विभाजन गर्न थप सही हुनेछ। यहाँ नडराउनुहोस्, किनकि यो क्लिकहाउस हो। ClickHouse एक स्तम्भ डाटाबेस हो। र अधिक सफा साना स्तम्भहरू, राम्रो। त्यहाँ 5 ब्राउजर भर्सनहरू हुनेछ, 5 स्तम्भहरू बनाउनुहोस्। यो ठीक छ।

अब तपाईसँग धेरै लामो स्ट्रिङहरू, धेरै लामो एरेहरू छन् भने के गर्ने भनेर हेरौं। तिनीहरूलाई क्लिकहाउसमा भण्डारण गर्न आवश्यक छैन। यसको सट्टा, तपाईंले क्लिकहाउसमा पहिचानकर्ता मात्र भण्डारण गर्न सक्नुहुन्छ। र यी लामो लाइनहरू कुनै अन्य प्रणालीमा राख्नुहोस्।

उदाहरण को लागी, हाम्रो एनालिटिक्स सेवाहरु मध्ये केहि घटना मापदण्डहरु छन्। र यदि घटनाहरूका लागि धेरै प्यारामिटरहरू छन् भने, हामी केवल पहिलो 512 लाई सुरक्षित गर्छौं जुन भेटिन्छ। किनभने 512 कुनै दया होइन।

र यदि तपाइँ तपाइँको डेटा प्रकारहरू बारे निर्णय गर्न सक्नुहुन्न भने, तपाइँ क्लिकहाउसमा डाटा रेकर्ड गर्न सक्नुहुन्छ, तर लग प्रकारको अस्थायी तालिकामा, अस्थायी डेटाको लागि विशेष। यस पछि, तपाईले त्यहाँ के मानहरूको वितरणको विश्लेषण गर्न सक्नुहुन्छ, त्यहाँ सामान्य रूपमा के छ, र सही प्रकारहरू सिर्जना गर्नुहोस्।

*क्लिकहाउससँग अब डाटा प्रकार छ कम कार्डिनलिटी जसले तपाईंलाई कम प्रयासमा कुशलतापूर्वक तारहरू भण्डारण गर्न अनुमति दिन्छ।

अब अर्को रोचक प्रसंग हेरौं। कहिलेकाहीँ चीजहरू मानिसहरूको लागि अनौठो काम गर्दछ। म भित्र आएर यो हेर्छु। र यो तुरुन्तै देखिन्छ कि यो केहि धेरै अनुभवी, स्मार्ट प्रशासक द्वारा गरिएको थियो जसलाई MySQL संस्करण 3.23 सेटअप गर्ने व्यापक अनुभव छ।

यहाँ हामी एक हजार तालिकाहरू देख्छौं, जसमध्ये प्रत्येकले एक हजारले के थाहा छ विभाजनको बाँकी रेकर्ड गर्दछ।

सिद्धान्तमा, म अन्य व्यक्तिहरूको अनुभवलाई सम्मान गर्छु, यस अनुभवबाट प्राप्त गर्न सकिने पीडाको बुझाइ सहित।

र कारणहरू कम वा कम स्पष्ट छन्। यी पुराना स्टेरियोटाइपहरू हुन् जुन अन्य प्रणालीहरूसँग काम गर्दा जम्मा भएको हुन सक्छ। उदाहरणका लागि, MyISAM तालिकाहरूमा क्लस्टर गरिएको प्राथमिक कुञ्जी छैन। र डाटा विभाजन गर्ने यो तरिका समान कार्यक्षमता प्राप्त गर्न एक हताश प्रयास हुन सक्छ।

अर्को कारण यो हो कि ठूला टेबलहरूमा कुनै पनि परिवर्तन अपरेशनहरू गर्न गाह्रो छ। सबै अवरुद्ध हुनेछ। यद्यपि MySQL को आधुनिक संस्करणहरूमा यो समस्या अब त्यति गम्भीर छैन।

वा, उदाहरणका लागि, माइक्रोशार्डिङ, तर पछि थप।

ClickHouse मा यो गर्न आवश्यक छैन, किनभने, पहिलो, प्राथमिक कुञ्जी क्लस्टर गरिएको छ, डाटा प्राथमिक कुञ्जी द्वारा क्रमबद्ध छ।

र कहिलेकाहीँ मानिसहरूले मलाई सोध्छन्: "क्लिकहाउसमा दायरा प्रश्नहरूको प्रदर्शन तालिकाको आकारमा निर्भर गर्दै कसरी भिन्न हुन्छ?" म भन्छु यो पटक्कै परिवर्तन हुँदैन। उदाहरणका लागि, तपाईंसँग एक अरब पङ्क्तिहरू भएको तालिका छ र तपाईंले दस लाख पङ्क्तिहरूको दायरा पढ्नुहुन्छ। सबै ठीक छ। यदि तालिकामा एक ट्रिलियन पङ्क्तिहरू छन् र तपाईंले एक मिलियन पङ्क्तिहरू पढ्नुभयो भने, यो लगभग उस्तै हुनेछ।

र, दोस्रो, सबै प्रकारका चीजहरू जस्तै म्यानुअल विभाजनहरू आवश्यक पर्दैन। यदि तपाईं भित्र जानुभयो र फाइल प्रणालीमा के छ भनेर हेर्नुभयो भने, तपाईंले देख्नुहुनेछ कि तालिका धेरै ठूलो कुरा हो। र त्यहाँ भित्र विभाजन जस्तै केहि छ। त्यो हो, क्लिकहाउसले तपाईको लागि सबै गर्छ र तपाईले कष्ट भोग्नु पर्दैन।

स्तम्भ थप्नुहोस्/छाड्नुहोस् भने क्लिकहाउसमा परिवर्तन निःशुल्क छ।

र तपाईंले सानो तालिकाहरू बनाउनु हुँदैन, किनकि यदि तपाईंसँग तालिकामा 10 पङ्क्तिहरू वा 10 पङ्क्तिहरू छन् भने, त्यसले कुनै फरक पर्दैन। ClickHouse एउटा प्रणाली हो जसले थ्रुपुटलाई अप्टिमाइज गर्छ, विलम्बता होइन, त्यसैले यसले 000 लाइनहरू प्रशोधन गर्न कुनै अर्थ राख्दैन।

एउटा ठूलो टेबल प्रयोग गर्नु सही हो। पुरानो स्टेरियोटाइपहरूबाट छुटकारा पाउनुहोस्, सबै ठीक हुनेछ।

र बोनसको रूपमा, पछिल्लो संस्करणमा हामीसँग अब व्यक्तिगत विभाजनहरूमा सबै प्रकारका मर्मतसम्भार कार्यहरू गर्नको लागि एक स्वेच्छाचारी विभाजन कुञ्जी सिर्जना गर्ने क्षमता छ।

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

* अब क्लिकहाउस पनि छ तालिका प्रकार्य इनपुट.

अर्को antipattern माइक्रोशार्डिङ हो। उदाहरण को लागी, तपाईले डाटा शार्ड गर्न आवश्यक छ र तपाईसँग 5 सर्भरहरू छन्, र भोलि त्यहाँ 6 सर्भरहरू हुनेछन्। र तपाइँ यो डेटा कसरी पुन: सन्तुलन गर्ने बारे सोच्नुहोस्। र यसको सट्टा तपाईं 5 शार्डहरूमा होइन, तर 1 शार्डहरूमा विभाजन गर्नुहुन्छ। र त्यसपछि तपाइँ यी प्रत्येक माइक्रोशार्डहरूलाई छुट्टै सर्भरमा नक्सा गर्नुहुन्छ। र तपाईले पाउनुहुनेछ, उदाहरणका लागि, एउटा सर्भरमा 000 ClickHouses, उदाहरणका लागि। अलग पोर्ट वा अलग डेटाबेस मा अलग उदाहरणहरू।

तर क्लिकहाउसमा यो धेरै राम्रो छैन। किनभने एउटा क्लिकहाउस उदाहरणले पनि एउटा अनुरोधलाई प्रशोधन गर्न सबै उपलब्ध सर्भर स्रोतहरू प्रयोग गर्ने प्रयास गर्दछ। त्यो हो, तपाईसँग केहि प्रकारको सर्भर छ र यसमा, उदाहरणका लागि, 56 प्रोसेसर कोरहरू छन्। तपाइँ एक सेकेन्ड लिने क्वेरी चलाउँदै हुनुहुन्छ र यसले 56 कोर प्रयोग गर्नेछ। र यदि तपाईंले त्यहाँ एउटा सर्भरमा 200 क्लिकहाउसहरू राख्नुभयो भने, त्यसपछि यो थाहा हुन्छ कि 10 थ्रेडहरू सुरु हुनेछन्। सामान्यतया, सबै कुरा धेरै खराब हुनेछ।

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

र अर्को कारण यो हो कि तपाइँसँग TCP मार्फत इन्टरप्रोसेसर संचार हुनेछ। डेटा क्रमबद्ध, deserialized हुनुपर्छ, र यो माइक्रोशार्ड को एक ठूलो संख्या हो। यसले प्रभावकारी रूपमा काम गर्दैन।

अर्को antipattern, यद्यपि यसलाई शायद नै antipattern भनिन्छ। यो पूर्व-एकत्रीकरणको ठूलो मात्रा हो।

सामान्यतया, पूर्व-एकत्रीकरण राम्रो छ। तपाईंसँग एक अरब पङ्क्तिहरू थिए, तपाईंले यसलाई जम्मा गर्नुभयो र यो 1 पङ्क्तिहरू भयो, र अब क्वेरी तुरुन्तै कार्यान्वयन हुन्छ। सबै कुरा महान छ। तपाईं यो गर्न सक्नुहुन्छ। र यसका लागि, ClickHouse सँग पनि एक विशेष तालिका प्रकार, AggregatingMergeTree छ, जसले डेटा सम्मिलित हुने बित्तिकै वृद्धिशील एकत्रीकरण कार्य गर्दछ।

तर कहिलेकाहीँ तपाई सोच्नुहुन्छ कि हामी यस प्रकारको डेटा र यस प्रकारको डेटा एकत्रित गर्नेछौं। र केही छिमेकी विभागमा, म कुन चाहिँ भन्न चाहन्न, तिनीहरूले प्राथमिक कुञ्जीद्वारा सारांशित गर्न SummingMergeTree तालिकाहरू प्रयोग गर्छन्, र लगभग 20 स्तम्भहरू प्राथमिक कुञ्जीको रूपमा प्रयोग गरिन्छ। केवल मामलामा, मैले गोप्यताको लागि केही स्तम्भहरूको नाम परिवर्तन गरें, तर यो धेरै धेरै हो।

र त्यस्ता समस्याहरू उत्पन्न हुन्छन्। पहिलो, तपाईंको डाटा भोल्युम धेरै घट्दैन। उदाहरणका लागि, यो तीन पटक घट्छ। तपाईंको डेटा एकत्रित नभएको खण्डमा उत्पन्न हुने असीमित एनालिटिक्स क्षमताहरू वहन गर्न तीन पटक राम्रो मूल्य हुनेछ। यदि डेटा एकत्रित छ भने, त्यसपछि विश्लेषणको सट्टा तपाईले केवल दयनीय तथ्याङ्कहरू प्राप्त गर्नुहुन्छ।

अनि यसमा खास के छ? तथ्य यो हो कि छिमेकी विभागका यी मानिसहरू कहिलेकाहीँ जान्छन् र प्राथमिक कुञ्जीमा अर्को स्तम्भ थप्न सोध्छन्। त्यो हो, हामीले यसरी डेटा एकत्रित गर्यौं, तर अब हामी अलि बढी चाहन्छौं। तर ClickHouse मा प्राथमिक कुञ्जी परिवर्तन गर्दैन। त्यसैले, हामीले C++ मा केही स्क्रिप्टहरू लेख्नुपर्छ। र मलाई स्क्रिप्टहरू मनपर्दैन, यदि तिनीहरू C++ मा छन् भने।

र यदि तपाइँ क्लिकहाउस के को लागी सिर्जना गरिएको थियो भनेर हेर्नुभयो भने, तब गैर-एकत्रित डाटा ठ्याक्कै त्यो परिदृश्य हो जसको लागि यो जन्मिएको थियो। यदि तपाइँ गैर-एकत्रित डाटाको लागि क्लिकहाउस प्रयोग गर्दै हुनुहुन्छ भने, तपाइँ यसलाई सही गर्दै हुनुहुन्छ। यदि तपाइँ जम्मा गर्नुहुन्छ भने, यो कहिलेकाहीं क्षमा योग्य छ।

अर्को चाखलाग्दो केस अनन्त पाशमा प्रश्नहरू हो। कहिलेकाहीँ म केहि उत्पादन सर्भरमा जान्छु र त्यहाँ शो प्रोसेसलिस्ट हेर्छु। र हरेक चोटि मैले पत्ता लगाउँछु कि केहि भयानक भइरहेको छ।

उदाहरण को लागी, यो जस्तै। यो तुरुन्तै स्पष्ट छ कि सबै एक अनुरोध मा गर्न सकिन्छ। केवल url मा र त्यहाँ सूची लेख्नुहोस्।

अनन्त लूपमा यस्ता धेरै प्रश्नहरू किन खराब छन्? यदि अनुक्रमणिका प्रयोग गरिएको छैन भने, तपाइँसँग समान डेटामा धेरै पासहरू हुनेछन्। तर यदि अनुक्रमणिका प्रयोग गरिन्छ भने, उदाहरणका लागि, तपाइँसँग ru को लागि प्राथमिक कुञ्जी छ र तपाइँ त्यहाँ url = केहि लेख्नुहुन्छ। र तपाइँ सोच्नुहुन्छ कि यदि तालिकाबाट केवल एक URL पढियो भने, सबै कुरा ठीक हुनेछ। तर वास्तवमा छैन। किनभने क्लिकहाउसले सबै ब्याचहरूमा गर्छ।

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

र बोनसको रूपमा, तपाईंले नोट गर्न सक्नुहुन्छ कि क्लिकहाउसमा तपाईंले IN खण्डमा मेगाबाइटहरू र सयौं मेगाबाइटहरू पनि स्थानान्तरण गर्न डराउनु पर्दैन। मलाई हाम्रो अभ्यासबाट याद छ कि यदि MySQL मा हामीले IN खण्डमा मानहरूको गुच्छा स्थानान्तरण गर्छौं, उदाहरणका लागि, हामीले त्यहाँ केही संख्याहरूको 100 मेगाबाइटहरू स्थानान्तरण गर्छौं, तब MySQL ले 10 गीगाबाइट मेमोरी खान्छ र यसमा अरू केही हुँदैन, सबै कुरा। खराब काम गर्दछ।

र दोस्रो हो कि क्लिकहाउसमा, यदि तपाइँका प्रश्नहरूले अनुक्रमणिका प्रयोग गर्दछ भने, यो सधैं पूर्ण स्क्यान भन्दा ढिलो हुँदैन, अर्थात् यदि तपाइँ लगभग सम्पूर्ण तालिका पढ्न आवश्यक छ भने, यो क्रमिक रूपमा जान्छ र सम्पूर्ण तालिका पढ्छ। सामान्यतया, उसले यो आफैले पत्ता लगाउनेछ।

तर तैपनि केही कठिनाइहरू छन्। उदाहरण को लागी, तथ्य यो कि एक subquery संग IN अनुक्रमणिका प्रयोग गर्दैन। तर यो हाम्रो समस्या हो र हामीले यसलाई समाधान गर्न आवश्यक छ। यहाँ आधारभूत केही छैन। हामी यसलाई ठीक गर्नेछौं*।

र अर्को चाखलाग्दो कुरा यो हो कि यदि तपाइँसँग धेरै लामो अनुरोध छ र वितरित अनुरोध प्रशोधन प्रगतिमा छ, तब यो धेरै लामो अनुरोध प्रत्येक सर्भरमा बिना कम्प्रेसन पठाइनेछ। उदाहरण को लागी, 100 मेगाबाइट र 500 सर्भर। र, तदनुसार, तपाइँसँग नेटवर्कमा 50 गीगाबाइट स्थानान्तरण हुनेछ। यो प्रसारित हुनेछ र त्यसपछि सबै सफलतापूर्वक पूरा हुनेछ।

* पहिले नै प्रयोग गर्दै; सबै कुरा प्रतिज्ञा अनुसार तय भयो।

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

र त्यहाँ एक मात्र समाधान छ। यदि तपाईंले API खोल्नुभएको छ भने, तपाईंले यसलाई काट्नु पर्छ। उदाहरण को लागी, कोटा को केहि प्रकार को परिचय। त्यहाँ अन्य सामान्य विकल्पहरू छैनन्। अन्यथा, तिनीहरूले तुरुन्तै एक स्क्रिप्ट लेख्नेछन् र त्यहाँ समस्या हुनेछ।

र ClickHouse को एक विशेष सुविधा छ - कोटा गणना। यसबाहेक, तपाईं आफ्नो कोटा कुञ्जी स्थानान्तरण गर्न सक्नुहुन्छ। यो, उदाहरण को लागी, आन्तरिक प्रयोगकर्ता आईडी हो। र कोटाहरू प्रत्येकको लागि स्वतन्त्र रूपमा गणना गरिनेछ।

अब अर्को रोचक कुरा। यो म्यानुअल प्रतिकृति हो।

मलाई धेरै केसहरू थाहा छ जहाँ क्लिकहाउसमा निर्मित प्रतिकृति समर्थन भए पनि, मानिसहरूले क्लिकहाउसलाई म्यानुअल रूपमा प्रतिकृति गर्छन्।

सिद्धान्त के हो? तपाईंसँग डाटा प्रोसेसिङ पाइपलाइन छ। र यसले स्वतन्त्र रूपमा काम गर्दछ, उदाहरणका लागि, विभिन्न डाटा केन्द्रहरूमा। तपाईंले क्लिकहाउसमा उही डाटा लेख्नुहुन्छ। साँचो, अभ्यासले देखाउँछ कि डेटा अझै पनि तपाईंको कोडमा केही सुविधाहरूको कारण भिन्न हुनेछ। मलाई आशा छ कि यो तपाईंको मा छ।

र समय-समयमा तपाईंले अझै पनि म्यानुअल रूपमा सिंक गर्नुपर्नेछ। उदाहरणका लागि, महिनामा एक पटक प्रशासकहरूले rsync गर्छन्।

वास्तवमा, क्लिकहाउसमा निर्मित प्रतिकृति प्रयोग गर्न धेरै सजिलो छ। तर त्यहाँ केही विरोधाभासहरू हुन सक्छ, किनभने यसको लागि तपाईंले ZooKeeper प्रयोग गर्न आवश्यक छ। म ZooKeeper को बारे मा केहि नराम्रो भन्दिन, सिद्धान्त मा, प्रणाली काम गर्दछ, तर यो हुन्छ कि जाभा-फोबिया को कारणले मानिसहरूले यसलाई प्रयोग गर्दैनन्, किनभने ClickHouse यस्तो राम्रो प्रणाली हो, C++ मा लेखिएको, जुन तपाइँ प्रयोग गर्न सक्नुहुन्छ र सबै ठीक हुनेछ। र ZooKeeper जाभामा हुनुहुन्छ। र कुनै न कुनै रूपमा तपाइँ हेर्न चाहनुहुन्न, तर तपाइँ म्यानुअल प्रतिकृति प्रयोग गर्न सक्नुहुन्छ।

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

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

MergeTree तालिकामा, तपाइँसँग कुनै मिति र समय हुनु आवश्यक छैन। तपाईं अझै पनि यसलाई प्रयोग गर्न सक्नुहुन्छ। यदि त्यहाँ कुनै मिति र समय छैन भने, पूर्वनिर्धारित 2000 लेख्नुहोस्। यसले काम गर्नेछ र स्रोतहरूको आवश्यकता पर्दैन।

र सर्भरको नयाँ संस्करणमा, तपाइँ तपाइँसँग विभाजन कुञ्जी बिना अनुकूलन विभाजन छ भनेर निर्दिष्ट गर्न सक्नुहुन्छ। त्यस्तै हुनेछ।

अर्कोतर्फ, तपाईं आदिम तालिका इन्जिनहरू प्रयोग गर्न सक्नुहुन्छ। उदाहरणका लागि, एक पटक डाटा भर्नुहोस् र हेर्नुहोस्, ट्विस्ट गर्नुहोस् र मेटाउनुहोस्। तपाईं लग प्रयोग गर्न सक्नुहुन्छ।

वा मध्यवर्ती प्रशोधनको लागि सानो मात्रा भण्डारण गर्नु भनेको स्ट्रिपलग वा टिनीलग हो।

यदि डाटाको मात्रा सानो छ भने मेमोरी प्रयोग गर्न सकिन्छ र तपाईले RAM मा केहि ट्विडल गर्न सक्नुहुन्छ।

क्लिकहाउसले पुन: सामान्यीकृत डाटा मन पराउँदैन।

यहाँ एउटा सामान्य उदाहरण हो। यो URL को एक ठूलो संख्या हो। तपाईंले तिनीहरूलाई अर्को तालिकामा राख्नुहोस्। र त्यसपछि तिनीहरूले तिनीहरूसँग सामेल हुने निर्णय गरे, तर यसले काम गर्दैन, नियमको रूपमा, किनकि क्लिकहाउसले ह्यास जोइनलाई मात्र समर्थन गर्दछ। यदि जडान गर्न आवश्यक पर्ने धेरै डाटाको लागि पर्याप्त RAM छैन भने, JOIN ले काम गर्दैन*।

यदि डाटा उच्च कार्डिनलिटीको छ भने, चिन्ता नगर्नुहोस्, यसलाई डिनोर्मलाइज्ड फारममा भण्डार गर्नुहोस्, URL हरू मुख्य तालिकामा सीधा ठाउँमा छन्।

* र अब ClickHouse सँग पनि मर्ज जोडिएको छ, र यसले मध्यवर्ती डाटा RAM मा फिट नहुने अवस्थामा काम गर्दछ। तर यो प्रभावकारी छैन र सिफारिस लागू रहन्छ।

एक जोडी थप उदाहरणहरू, तर मलाई पहिले नै शंका छ कि तिनीहरू विरोधी ढाँचा हुन् वा होइनन्।

क्लिकहाउसमा एउटा ज्ञात त्रुटि छ। यसलाई कसरी अपडेट गर्ने थाहा छैन*। केही तरिकामा, यो पनि राम्रो छ। यदि तपाइँसँग केहि महत्त्वपूर्ण डेटा छ, उदाहरणका लागि, लेखा, तब कसैले यसलाई पठाउन सक्षम हुनेछैन, किनभने त्यहाँ कुनै अद्यावधिकहरू छैनन्।

* ब्याच मोडमा अपडेट र मेटाउनको लागि समर्थन धेरै पहिले थपिएको छ।

तर त्यहाँ केही विशेष तरिकाहरू छन् जसले पृष्ठभूमिमा जस्तै अद्यावधिकहरूलाई अनुमति दिन्छ। उदाहरण को लागी, टेबल जस्तै ReplaceMergeTree। तिनीहरू पृष्ठभूमि मर्जको समयमा अद्यावधिकहरू बनाउँछन्। तपाइँ यसलाई अनुकूलन तालिका प्रयोग गरेर बल गर्न सक्नुहुन्छ। तर यो धेरै पटक नगर्नुहोस्, किनकि यसले विभाजनलाई पूर्ण रूपमा अधिलेखन गर्नेछ।

ClickHouse मा वितरित JOIN हरू पनि क्वेरी प्लानरद्वारा खराब रूपमा ह्यान्डल गरिएका छन्।

खराब, तर कहिलेकाहीँ ठीक छ।

चयन* प्रयोग गरेर डेटा फिर्ता पढ्न क्लिकहाउस मात्र प्रयोग गर्दै।

म जटिल गणनाहरूको लागि क्लिकहाउस प्रयोग गर्न सिफारिस गर्दिन। तर यो पूर्णतया सत्य होइन, किनकि हामी पहिले नै यो सिफारिसबाट टाढा जाँदैछौं। र हामीले भर्खरै ClickHouse - Catboost मा मेसिन लर्निङ मोडेलहरू लागू गर्ने क्षमता थपेका छौं। र यसले मलाई सताउँछ किनभने मलाई लाग्छ, "कस्तो डरलाग्दो। यो प्रति बाइट कति चक्र बाहिर जान्छ! मलाई बाइटहरूमा घडीहरू बर्बाद गर्न साँच्चै घृणा छ।

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

तपाईंका प्रश्नहरू

रिपोर्ट को लागी धन्यवाद! क्लिकहाउस क्र्यासिङको बारेमा म कहाँ उजुरी गर्न सक्छु?

तपाईं अहिले व्यक्तिगत रूपमा मलाई गुनासो गर्न सक्नुहुन्छ।

मैले भर्खरै क्लिकहाउस प्रयोग गर्न थालें। मैले तुरुन्तै cli इन्टरफेस छोडें।

कस्तो स्कोर।

केही समय पछि मैले सानो चयनको साथ सर्भर क्र्यास गरें।

तिमीमा प्रतिभा छ।

मैले GitHub बग खोले, तर यसलाई बेवास्ता गरियो।

हामी हेर्नेछौं।

एलेक्सीले मलाई रिपोर्टमा भाग लिन ठग्यो, तपाईले भित्रको डेटा कसरी पहुँच गर्नुहुन्छ भनेर मलाई बताउनुहुन्छ।

एकदम सजिलो।

यो कुरा मैले हिजो बुझेँ । थप विवरण।

त्यहाँ कुनै भयानक चालहरू छैनन्। त्यहाँ केवल ब्लक-द्वारा-ब्लक कम्प्रेसन छ। पूर्वनिर्धारित LZ4 हो, तपाईंले ZSTD* सक्षम गर्न सक्नुहुन्छ। 64 किलोबाइट देखि 1 मेगाबाइट सम्म ब्लक।

* त्यहाँ विशेष कम्प्रेसन कोडेकहरूको लागि समर्थन पनि छ जुन अन्य एल्गोरिदमहरूसँग श्रृंखलामा प्रयोग गर्न सकिन्छ।

के ब्लकहरू कच्चा डाटा मात्र हुन्?

पूर्णतया कच्चा छैन। त्यहाँ arrays छन्। यदि तपाइँसँग संख्यात्मक स्तम्भ छ भने, पङ्क्तिमा संख्याहरू एरेमा राखिन्छन्।

यो स्पष्ट छ।

एलेक्सी, एउटा उदाहरण जुन आईपीहरूमा UniqExact को साथ थियो, अर्थात् तथ्य यो हो कि UniqExact लाई संख्याहरू भन्दा रेखाहरूद्वारा गणना गर्न धेरै समय लाग्छ, र यस्तै। यदि हामीले प्रूफरीडिङको समयमा हाम्रो कान र कास्टमा फेन्ट प्रयोग गर्छौं भने के हुन्छ? त्यो हो, तपाईले भन्नुभएको जस्तो देखिन्छ कि हाम्रो डिस्कमा यो धेरै फरक छैन। यदि हामीले डिस्क र कास्टबाट लाइनहरू पढ्यौं भने, हाम्रो समुच्चयहरू छिटो हुनेछ कि छैन? वा हामी अझै पनि यहाँ थोरै लाभ? मलाई लाग्छ कि तपाईंले यो परीक्षण गर्नुभयो, तर कुनै कारणले यसलाई बेन्चमार्कमा संकेत गर्नुभएन।

मलाई लाग्छ कि यो कास्ट नगरी भन्दा ढिलो हुनेछ। यस अवस्थामा, IP ठेगाना स्ट्रिङबाट पार्स हुनुपर्छ। अवश्य पनि, ClickHouse मा, हाम्रो IP ठेगाना पार्सिङ पनि अनुकूलित छ। हामीले धेरै कोसिस गर्यौं, तर त्यहाँ दस हजारौं फारममा अंक लेखिएको छ। धेरै असहज। अर्कोतर्फ, uniqExact प्रकार्यले स्ट्रिङहरूमा ढिलो काम गर्नेछ, यी स्ट्रिङहरू मात्र नभएर एल्गोरिदमको फरक विशेषज्ञता चयन गरिएकोले पनि। स्ट्रिङहरू मात्र फरक तरिकाले प्रशोधन गरिन्छ।

के हुन्छ यदि हामीले अधिक आदिम डाटा प्रकार लियौं? उदाहरणका लागि, हामीले प्रयोगकर्ता आईडी लेख्यौं, जुन हामीसँग छ, यसलाई लाइनको रूपमा लेख्यौं, र त्यसपछि यसलाई स्क्र्याम्बल गर्‍यौं, यो अझ रमाइलो हुनेछ कि पर्दैन?

मलाई शंका छ। मलाई लाग्छ कि यो अझ दु: खी हुनेछ, किनभने सबै पछि, संख्या पार्सिङ एक गम्भीर समस्या हो। मलाई लाग्छ कि यो सहकर्मीले दश हजारौं फारममा संख्याहरू पार्स गर्न कत्ति गाह्रो छ भनेर रिपोर्ट पनि दिए, तर सायद होइन।

एलेक्सी, रिपोर्ट को लागी धेरै धेरै धन्यवाद! र ClickHouse को लागी धेरै धेरै धन्यवाद! मसँग योजनाहरूको बारेमा प्रश्न छ। के त्यहाँ अपूर्ण शब्दकोषहरू अद्यावधिक गर्ने सुविधाको लागि कुनै योजनाहरू छन्?

त्यो हो, आंशिक रिबुट?

हो हो। त्यहाँ MySQL फिल्ड सेट गर्ने क्षमता जस्तै, अर्थात् पछि अपडेट गर्नुहोस् ताकि यदि शब्दकोश धेरै ठूलो छ भने मात्र यो डाटा लोड हुन्छ।

एक धेरै रोचक सुविधा। र मलाई लाग्छ कि कसैले हाम्रो च्याटमा यो सुझाव दियो। सायद यो तपाईं पनि हुनुहुन्थ्यो।

मलाई त्यस्तो लाग्दैन।

राम्रो, अब यो बाहिर जान्छ कि त्यहाँ दुई अनुरोधहरू छन्। र तपाईं बिस्तारै यो गर्न सुरु गर्न सक्नुहुन्छ। तर म तपाईंलाई तुरुन्तै चेतावनी दिन चाहन्छु कि यो सुविधा लागू गर्न एकदम सरल छ। त्यो हो, सिद्धान्तमा, तपाईंले तालिकामा संस्करण नम्बर लेख्न आवश्यक छ र त्यसपछि लेख्नुहोस्: यस्तो र यस्तो भन्दा कम संस्करण। यसको मतलब, सम्भवतः, हामी यसलाई उत्साहीहरूलाई प्रस्ताव गर्नेछौं। तपाईं एक उत्साही हुनुहुन्छ?

हो, तर, दुर्भाग्यवश, C++ मा होइन।

के तपाईका सहकर्मीहरूलाई C++ मा कसरी लेख्ने थाहा छ?

म कसैलाई भेट्टाउनेछु।

महान *।

* फिचर रिपोर्टको दुई महिना पछि थपिएको थियो - प्रश्नको लेखकले यसलाई विकास गरी पठाउनुभयो अनुरोध तान्नुहोस्.

धन्यवाद!

नमस्ते! रिपोर्ट को लागी धन्यवाद! तपाईंले उल्लेख गर्नुभयो कि क्लिकहाउस यसमा उपलब्ध सबै स्रोतहरू उपभोग गर्न धेरै राम्रो छ। र लक्सोफ्टको छेउमा वक्ताले रूसी पोष्टको लागि आफ्नो समाधानको बारेमा कुरा गरे। उनले भने कि उनीहरूलाई क्लिकहाउस साँच्चै मनपर्‍यो, तर उनीहरूले यसलाई आफ्नो मुख्य प्रतिस्पर्धीको सट्टा प्रयोग गरेनन् किनभने यसले सबै सीपीयू खाइरहेको थियो। र तिनीहरूले यसलाई तिनीहरूको वास्तुकलामा प्लग गर्न सकेनन्, तिनीहरूको ZooKeeper मा डकरहरूसँग। के यो सम्भव छ कि क्लिकहाउसलाई सीमित गर्न ताकि यसले यसलाई उपलब्ध हुने सबै चीजहरू उपभोग गर्दैन?

हो, यो सम्भव छ र धेरै सजिलो छ। यदि तपाइँ कम कोर उपभोग गर्न चाहनुहुन्छ भने, त्यसपछि मात्र लेख्नुहोस् set max_threads = 1। र यो हो, यसले अनुरोधलाई एक कोरमा कार्यान्वयन गर्नेछ। यसबाहेक, तपाईं विभिन्न प्रयोगकर्ताहरूको लागि विभिन्न सेटिङहरू निर्दिष्ट गर्न सक्नुहुन्छ। त्यसैले समस्या छैन। र Luxoft का आफ्ना सहकर्मीहरूलाई भन्नुहोस् कि यो राम्रो छैन कि उनीहरूले कागजातमा यो सेटिङ फेला पारेनन्।

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

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

* ClickHouse को नवीनतम संस्करणहरूमा, "अनुकूल अनुक्रमणिका ग्रेन्युलारिटी" सक्षम गरिएको छ, जसले धेरै भागको लागि लामो पङ्क्तिहरू भण्डारण गर्ने समस्यालाई हटाउँछ।

के एक किलोबाइट सामान्य छ?

Нормально।

नमस्ते! रिपोर्ट को लागी धन्यवाद! मैले पहिले नै च्याटमा यस बारे सोधेको छु, तर मैले जवाफ पाएको छु भने मलाई याद छैन। के त्यहाँ कुनै न कुनै रूपमा CTE को रूपमा WITH खण्ड विस्तार गर्ने योजना छ?

अझै छैन। हाम्रो WITH खण्ड केही बेकार छ। यो हाम्रो लागि सानो सुविधा जस्तै छ।

म बुझ्दछु। धन्यवाद!

रिपोर्ट को लागी धन्यवाद! निकै रोमान्चक! विश्वव्यापी प्रश्न। के त्यहाँ डेटा मेटाउने परिमार्जन गर्ने योजनाहरू छन्, सायद कुनै प्रकारको स्टबको रूपमा?

अनिवार्य रूपमा। यो हाम्रो लाइनमा हाम्रो पहिलो कार्य हो। हामी अब सक्रिय रूपमा सबै कुरा कसरी सही तरिकाले गर्ने बारे सोचिरहेका छौं। र तपाईंले किबोर्ड* थिच्न सुरु गर्नुपर्छ।

* किबोर्डमा बटन थिच्नुहोस् र सबै गर्नुभयो।

यसले कुनै न कुनै रूपमा प्रणालीको कार्यसम्पादनलाई असर गर्छ कि गर्दैन? के हालको रूपमा प्रविष्टि छिटो हुनेछ?

सायद मेटाउनेहरू र अद्यावधिकहरू आफैंमा धेरै भारी हुनेछन्, तर यसले चयनहरूको कार्यसम्पादन वा सम्मिलितहरूको कार्यसम्पादनलाई असर गर्दैन।

र अर्को सानो प्रश्न। प्रस्तुतिमा तपाईंले प्राथमिक कुञ्जीको बारेमा कुरा गर्नुभयो। तदनुसार, हामीसँग विभाजन छ, जुन पूर्वनिर्धारित रूपमा मासिक हो, सही? र जब हामीले एक महिनामा फिट हुने मिति दायरा सेट गर्छौं, तब मात्र यो विभाजन पढिन्छ, हैन?

हो।

एउटा प्रश्न। यदि हामीले कुनै पनि प्राथमिक कुञ्जी चयन गर्न सक्दैनौं भने, त्यसोभए के यो विशेष रूपमा "मिति" फिल्ड अनुसार गर्न सही छ ताकि पृष्ठभूमिमा यस डेटाको कम पुनर्व्यवस्थित छ ताकि यो अझ व्यवस्थित रूपमा फिट हुन्छ? यदि तपाइँसँग दायरा प्रश्नहरू छैनन् र तपाइँ कुनै पनि प्राथमिक कुञ्जी चयन गर्न सक्नुहुन्न भने, के यो प्राथमिक कुञ्जीमा मिति राख्न लायक छ?

हो।

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

धेरै धेरै धन्यवाद!

स्रोत: www.habr.com