यह लेख मेरे और मेरे सहयोगी काई दाई द्वारा सह-लिखा गया है। हम दोनों Tencent Music (NYSE: TME) में डेटा प्लेटफ़ॉर्म इंजीनियर हैं, जो कि 800 मिलियन मासिक सक्रिय उपयोगकर्ताओं के साथ एक संगीत स्ट्रीमिंग सेवा प्रदाता है। यहां संख्या कम करना डींग मारना नहीं है बल्कि डेटा के समुद्र का संकेत देना है जिससे मेरे गरीब सहकर्मियों और मुझे हर रोज निपटना पड़ता है। हम क्लिकहाउस का उपयोग किस लिए करते हैं टेनसेंट म्यूजिक की म्यूजिक लाइब्रेरी में सभी रूपों और प्रकारों का डेटा होता है: रिकॉर्डेड म्यूजिक, लाइव म्यूजिक, ऑडियो, वीडियो आदि। डेटा प्लेटफॉर्म इंजीनियरों के रूप में, हमारा काम डेटा से जानकारी को डिस्टिल करना है, जिसके आधार पर हमारे साथी बेहतर निर्णय ले सकते हैं। हमारे उपयोगकर्ताओं और संगीत भागीदारों का समर्थन करने के लिए। विशेष रूप से, हम गीतों, गीतों, धुनों, एल्बमों और कलाकारों का चौतरफा विश्लेषण करते हैं, इस सारी जानकारी को डेटा संपत्तियों में बदलते हैं, और उन्हें अपने आंतरिक डेटा उपयोगकर्ताओं को इन्वेंट्री काउंटिंग, उपयोगकर्ता प्रोफाइलिंग, मेट्रिक्स विश्लेषण और समूह लक्ष्यीकरण के लिए पास करते हैं। . हमने अपना अधिकांश डेटा Tencent डेटा वेयरहाउस (TDW) में संग्रहीत और संसाधित किया, एक ऑफ़लाइन डेटा प्लेटफ़ॉर्म जहाँ हम डेटा को विभिन्न टैग और मीट्रिक सिस्टम में डालते हैं और फिर प्रत्येक ऑब्जेक्ट (गीत, कलाकार, आदि) को केंद्रित करते हुए फ्लैट टेबल बनाते हैं। फिर हमने डेटा खोज और समूह लक्ष्यीकरण के लिए विश्लेषण और इलास्टिक्स खोज के लिए क्लिकहाउस में फ्लैट टेबल आयात किए। उसके बाद, हमारे डेटा विश्लेषकों ने विभिन्न उपयोग परिदृश्यों के लिए डेटासेट बनाने के लिए आवश्यक टैग और मेट्रिक्स के तहत डेटा का उपयोग किया, जिसके दौरान वे अपने स्वयं के टैग और मेट्रिक्स बना सकते थे। डाटा प्रोसेसिंग पाइपलाइन इस तरह दिखी: क्लिकहाउस के साथ समस्याएं उपरोक्त पाइपलाइन के साथ काम करते समय, हमें कुछ कठिनाइयों का सामना करना पड़ा: : स्तंभों का आंशिक अद्यतन समर्थित नहीं था। इसलिए, किसी भी एक डेटा स्रोत से कोई विलंबता फ्लैट टेबल के निर्माण में देरी कर सकती है, और इस प्रकार डेटा समयबद्धता को कम कर सकती है। आंशिक अद्यतन : विभिन्न टैग्स और मेट्रिक्स के तहत डेटा को विभिन्न आवृत्तियों पर अपडेट किया गया था। जितना क्लिकहाउस ने फ्लैट टेबल से निपटने में उत्कृष्ट प्रदर्शन किया, यह भंडारण संसाधनों की एक बड़ी बर्बादी थी, बस सभी डेटा को एक फ्लैट टेबल में डालना और इसे दिन में विभाजित करना, इसके साथ आने वाली रखरखाव लागत का उल्लेख नहीं करना। उच्च भंडारण लागत : वास्तुकला की दृष्टि से, क्लिकहाउस को स्टोरेज नोड्स और कंप्यूट नोड्स के मजबूत युग्मन की विशेषता थी। क्लस्टर अस्थिरता के जोखिमों को जोड़ते हुए, इसके घटक अत्यधिक अन्योन्याश्रित थे। साथ ही, ClickHouse और Elasticsearch में फ़ेडरेटेड प्रश्नों के लिए, हमें बड़ी मात्रा में कनेक्शन संबंधी समस्याओं का ध्यान रखना था। वह सिर्फ थकाऊ था। उच्च रखरखाव लागत अपाचे डोरिस में संक्रमण , एक रीयल-टाइम विश्लेषणात्मक डेटाबेस, कुछ विशेषताएं समेटे हुए है जो वास्तव में हमारी समस्याओं को हल करने के लिए आवश्यक हैं: Apache Doris : डोरिस विभिन्न प्रकार के डेटा मॉडल का समर्थन करता है, जिनमें से कुल मॉडल स्तंभों के वास्तविक समय के आंशिक अद्यतन का समर्थन करता है। इसके आधार पर, हम कच्चे डेटा को सीधे डोरिस में डाल सकते हैं और वहां फ्लैट टेबल बना सकते हैं। अंतर्ग्रहण इस प्रकार है: सबसे पहले, हम काफ्का में डेटा लोड करने के लिए स्पार्क का उपयोग करते हैं; फिर, किसी भी वृद्धिशील डेटा को Flink के माध्यम से Doris और Elasticsearch में अपडेट किया जाएगा। इस बीच, फ्लिंक डेटा को प्री-एग्रीगेट करेगा ताकि डोरिस और इलास्टिक्स खोज पर बोझ कम हो सके। आंशिक अद्यतन : डोरिस हाइव, आइसबर्ग, हुडी, माईएसक्यूएल, और एलिस्टिक्स खोज में मल्टी-टेबल जॉइन क्वेश्चन और फेडरेटेड क्वेश्चन का समर्थन करता है। यह हमें बड़े फ्लैट तालिकाओं को छोटे में विभाजित करने और उन्हें अद्यतन आवृत्ति द्वारा विभाजित करने की अनुमति देता है। ऐसा करने के लाभों में भंडारण बोझ से राहत और क्वेरी थ्रूपुट में वृद्धि शामिल है। भंडारण लागत : डोरिस सरल वास्तुकला की है और MySQL प्रोटोकॉल के अनुकूल है। डोरिस की तैनाती में केवल दो प्रक्रियाएं (एफई और बीई) शामिल हैं, अन्य प्रणालियों पर कोई निर्भरता नहीं है, जिससे इसे संचालित करना और बनाए रखना आसान हो जाता है। इसके अलावा, डोरिस बाहरी ES डेटा टेबल्स को क्वेरी करने का समर्थन करता है। यह ईएस में मेटाडेटा के साथ आसानी से इंटरफ़ेस कर सकता है और स्वचालित रूप से ईएस से तालिका स्कीमा को मैप कर सकता है ताकि हम जटिल कनेक्शनों से जूझने के बिना डोरिस के माध्यम से एलिस्टिक्स खोज डेटा पर प्रश्नों का संचालन कर सकें। रखरखाव लागत क्या अधिक है, डोरिस कई डेटा अंतर्ग्रहण विधियों का समर्थन करता है, जिसमें HDFS और S3 जैसे रिमोट स्टोरेज से बैच आयात, MySQL बिनलॉग और काफ्का से डेटा रीड, और रीयल-टाइम डेटा सिंक्रोनाइज़ेशन या MySQL, Oracle, और PostgreSQL से बैच आयात शामिल हैं। यह एक निरंतरता प्रोटोकॉल के माध्यम से सेवा की उपलब्धता और डेटा की विश्वसनीयता सुनिश्चित करता है और ऑटो डिबगिंग में सक्षम है। यह हमारे ऑपरेटरों और अनुरक्षकों के लिए बहुत अच्छी खबर है। सांख्यिकीय रूप से कहा जाए तो, इन सुविधाओं ने हमारी भंडारण लागत में 42% और विकास लागत में 40% की कटौती की है। डोरिस के हमारे उपयोग के दौरान, हमें ओपन सोर्स अपाचे डोरिस समुदाय से बहुत समर्थन मिला है और सेलेक्टडीबी टीम से समय पर मदद मिली है, जो अब अपाचे डोरिस का व्यावसायिक संस्करण चला रही है। हमारी जरूरतों को पूरा करने के लिए और सुधार सिमेंटिक परत का परिचय दें डेटासेट की बात करें तो अच्छी बात यह है कि हमारे डेटा विश्लेषकों को अपनी सुविधानुसार टैग और मेट्रिक्स को फिर से परिभाषित करने और संयोजन करने की स्वतंत्रता दी गई है। लेकिन डार्क साइड पर, टैग और मीट्रिक सिस्टम की उच्च विषमता उनके उपयोग और प्रबंधन में अधिक कठिनाई का कारण बनती है। हमारा समाधान हमारी डेटा प्रोसेसिंग पाइपलाइन में सिमेंटिक परत पेश करना है। सिमेंटिक परत वह है जहां हमारे आंतरिक डेटा उपयोगकर्ताओं के लिए सभी तकनीकी शब्दों को अधिक बोधगम्य अवधारणाओं में अनुवादित किया जाता है। दूसरे शब्दों में, हम डेटा परिभाषा और प्रबंधन के लिए टैग और मेट्रिक्स को प्रथम श्रेणी के नागरिकों में बदल रहे हैं। यह क्यों मदद करेगा? डेटा विश्लेषकों के लिए, सभी टैग और मेट्रिक्स सिमेंटिक परत पर बनाए और साझा किए जाएंगे ताकि कम भ्रम और उच्च दक्षता हो। डेटा उपयोगकर्ताओं के लिए, उन्हें अब अपने स्वयं के डेटासेट बनाने या यह पता लगाने की आवश्यकता नहीं है कि प्रत्येक परिदृश्य के लिए कौन सा डेटासेट लागू है, लेकिन वे केवल अपने निर्दिष्ट टैगसेट और मीट्रिकसेट पर प्रश्नों का संचालन कर सकते हैं। सिमेंटिक लेयर को अपग्रेड करें सिमेंटिक परत पर स्पष्ट रूप से टैग और मेट्रिक्स को परिभाषित करना पर्याप्त नहीं था। एक मानकीकृत डेटा प्रोसेसिंग सिस्टम बनाने के लिए, हमारा अगला लक्ष्य पूरे डेटा प्रोसेसिंग पाइपलाइन में टैग और मेट्रिक्स की लगातार परिभाषा सुनिश्चित करना था। इस खातिर, हमने सिमेंटिक लेयर को अपने डेटा प्रबंधन सिस्टम का दिल बना दिया है: यह कैसे काम करता है? TDW में सभी कंप्यूटिंग लॉजिक्स को सिमेंटिक लेयर पर सिंगल टैग या मेट्रिक के रूप में परिभाषित किया जाएगा। सिमेंटिक परत अनुप्रयोग पक्ष से तार्किक प्रश्न प्राप्त करती है, तदनुसार एक इंजन का चयन करती है, और SQL उत्पन्न करती है। फिर यह SQL कमांड को निष्पादन के लिए TDW को भेजता है। इस बीच, यह डोरिस को कॉन्फ़िगरेशन और डेटा अंतर्ग्रहण कार्य भी भेज सकता है और यह तय कर सकता है कि कौन से मेट्रिक्स और टैग को त्वरित किया जाना चाहिए। इस प्रकार, हमने टैग और मीट्रिक को अधिक प्रबंधनीय बना दिया है। मरहम में एक मक्खी यह है कि चूंकि प्रत्येक टैग और मीट्रिक को अलग-अलग परिभाषित किया गया है, हम प्रश्नों के लिए एक वैध SQL कथन की पीढ़ी को स्वचालित करने के साथ संघर्ष कर रहे हैं। यदि आपके पास इसके बारे में कोई विचार है, तो हमसे बात करने के लिए आपका स्वागत है। अपाचे डोरिस को पूरा खेल दें जैसा कि आप देख सकते हैं, अपाचे डोरिस ने हमारे समाधान में महत्वपूर्ण भूमिका निभाई है। डोरिस के उपयोग को अनुकूलित करने से हमारी समग्र डाटा प्रोसेसिंग दक्षता में काफी हद तक सुधार हो सकता है। इसलिए इस भाग में, हम आपके साथ साझा करने जा रहे हैं कि हम डोरिस के साथ डेटा अंतर्ग्रहण और प्रश्नों में तेजी लाने और लागत कम करने के लिए क्या करते हैं। हम जो चाहते हैं? वर्तमान में, हमारे पास TDW में 80+ स्रोत तालिकाओं से प्राप्त 800+ टैग और 1300+ मीट्रिक हैं। टीडीडब्ल्यू से डोरिस में डेटा आयात करते समय, हम प्राप्त करने की आशा करते हैं: : पारंपरिक T+1 ऑफ़लाइन डेटा अंतर्ग्रहण के अतिरिक्त, हमें रीयल-टाइम टैगिंग की आवश्यकता होती है। रीयल-टाइम उपलब्धता : प्रत्येक स्रोत तालिका अपने स्वयं के ETL कार्य के माध्यम से विभिन्न गति से डेटा उत्पन्न करती है और इसमें टैग और मैट्रिक्स का केवल एक हिस्सा शामिल होता है, इसलिए हमें स्तंभों के आंशिक अद्यतन के लिए समर्थन की आवश्यकता होती है। आंशिक अद्यतन : समूह लक्ष्यीकरण, विश्लेषण और रिपोर्टिंग परिदृश्यों में हमें केवल कुछ सेकंड का प्रतिक्रिया समय चाहिए। उच्च प्रदर्शन : हम जितना संभव हो उतना लागत कम करने की उम्मीद करते हैं। कम लागत हम क्या करते हैं? टीडीडब्ल्यू के बजाय फ्लिंक में फ्लैट टेबल जेनरेट करें टीडीडब्ल्यू में फ्लैट टेबल बनाने के कुछ नुकसान हैं: : TDW को असतत 80+ स्रोत तालिकाओं के अलावा एक अतिरिक्त सपाट तालिका बनाए रखनी होती है। यह बहुत बड़ा अतिरेक है। उच्च भंडारण लागत : स्रोत तालिकाओं में किसी भी देरी को बढ़ाया जाएगा और पूरे डेटा लिंक को मंद कर दिया जाएगा। कम वास्तविक समयबद्धता : वास्तविक समयबद्धता प्राप्त करने के लिए अतिरिक्त विकास प्रयासों और संसाधनों की आवश्यकता होगी। उच्च विकास लागत इसके विपरीत, डोरिस में फ्लैट टेबल बनाना बहुत आसान और कम खर्चीला है। प्रक्रिया इस प्रकार है: ऑफ़लाइन तरीके से काफ्का में नया डेटा आयात करने के लिए स्पार्क का उपयोग करें। काफ्का डेटा का उपभोग करने के लिए फ्लिंक का उपयोग करें। प्राथमिक कुंजी आईडी के माध्यम से एक फ्लैट टेबल बनाएं। डोरिस में फ्लैट टेबल आयात करें। जैसा कि नीचे दिखाया गया है, फ्लिंक ने डेटा की पांच पंक्तियों को एकत्र किया है, जिनमें से "आईडी" = 1, डोरिस में एक पंक्ति में, डोरिस पर डेटा लेखन दबाव को कम करता है। यह भंडारण लागत को काफी हद तक कम कर सकता है क्योंकि TDW को लंबे समय तक डेटा की दो प्रतियां नहीं रखनी पड़ती हैं और काफ्का को केवल अंतर्ग्रहण के लिए लंबित नए डेटा को संग्रहीत करने की आवश्यकता होती है। क्या अधिक है, हम फ़्लिंक में जो भी ईटीएल तर्क चाहते हैं उसे जोड़ सकते हैं और ऑफ़लाइन और वास्तविक समय डेटा अंतर्ग्रहण के लिए बहुत सारे विकास तर्क का पुन: उपयोग कर सकते हैं। कॉलम को स्मार्ट तरीके से नाम दें जैसा कि हमने उल्लेख किया है, डोरिस का सकल मॉडल स्तंभों के आंशिक अद्यतन की अनुमति देता है। यहां हम आपके संदर्भ के लिए डोरिस में अन्य डेटा मॉडलों का सरल परिचय प्रदान करते हैं: : यह प्राथमिक कुंजी विशिष्टता की आवश्यकता वाले परिदृश्यों के लिए लागू होता है। यह केवल उसी प्राथमिक कुंजी आईडी का नवीनतम डेटा रखता है। (जहाँ तक हम जानते हैं, अपाचे डोरिस समुदाय विशिष्ट मॉडल में भी स्तंभों के आंशिक अद्यतन को शामिल करने की योजना बना रहा है।) अद्वितीय मॉडल : यह मॉडल बिना किसी प्री-एग्रीगेशन या डुप्लीकेशन के सभी मूल डेटा को ठीक वैसे ही स्टोर करता है जैसे यह है। डुप्लीकेट मॉडल डेटा मॉडल निर्धारित करने के बाद, हमें यह सोचना था कि कॉलम का नाम कैसे दिया जाए। स्तंभ नाम के रूप में टैग या मीट्रिक का उपयोग करना कोई विकल्प नहीं था क्योंकि: Ⅰ। हमारे आंतरिक डेटा उपयोगकर्ताओं को मेट्रिक्स या टैग का नाम बदलने की आवश्यकता हो सकती है, लेकिन डोरिस 1.1.3 कॉलम नामों के संशोधन का समर्थन नहीं करता है। Ⅱ। टैग को अक्सर ऑनलाइन और ऑफलाइन लिया जा सकता है। यदि इसमें कॉलम जोड़ना और छोड़ना शामिल है, तो यह न केवल समय लेने वाला होगा बल्कि क्वेरी प्रदर्शन के लिए भी हानिकारक होगा। इसके बजाय, हम निम्न कार्य करते हैं: टैग और मेट्रिक्स के लचीले नाम बदलने के लिए, हम मेटाडेटा (नाम, विश्व स्तर पर अद्वितीय आईडी, स्थिति, आदि) को संग्रहीत करने के लिए MySQL तालिकाओं का उपयोग करते हैं। नामों में कोई भी बदलाव केवल मेटाडेटा में होगा लेकिन डोरिस में टेबल स्कीमा को प्रभावित नहीं करेगा। उदाहरण के लिए, अगर एक 4 की आईडी दी गई है, तो इसे डोरिस में a4 के कॉलम नाम के साथ स्टोर किया जाएगा। फिर अगर किसी क्वेरी में शामिल है, तो इसे SQL में a4 में बदल दिया जाएगा। song_name song_name टैग्स की ऑनलाइनिंग और ऑफलाइनिंग के लिए, हम टैग्स को इस आधार पर छाँटते हैं कि उनका कितनी बार उपयोग किया जा रहा है। कम से कम उपयोग किए जाने वालों को उनके मेटाडेटा में एक ऑफ़लाइन चिह्न दिया जाएगा। ऑफ़लाइन टैग के अंतर्गत कोई नया डेटा नहीं डाला जाएगा लेकिन उन टैग के अंतर्गत मौजूदा डेटा अभी भी उपलब्ध रहेगा। नए जोड़े गए टैग और मेट्रिक्स की रीयल-टाइम उपलब्धता के लिए, हम नाम आईडी के मानचित्रण के आधार पर डोरिस टेबल में कुछ आईडी कॉलम प्रीबिल्ड करते हैं। ये आरक्षित आईडी कॉलम नए जोड़े गए टैग और मेट्रिक्स को आवंटित किए जाएंगे। इस प्रकार, हम टेबल स्कीमा परिवर्तन और परिणामी ओवरहेड्स से बच सकते हैं। हमारा अनुभव बताता है कि टैग और मेट्रिक्स जोड़े जाने के 10 मिनट बाद ही उनके अंतर्गत डेटा उपलब्ध हो सकता है। उल्लेखनीय रूप से, हाल ही में जारी डोरिस 1.2.0 लाइट स्कीमा चेंज का समर्थन करता है, जिसका अर्थ है कि कॉलम जोड़ने या हटाने के लिए, आपको केवल FE में मेटाडेटा को संशोधित करने की आवश्यकता है। साथ ही, जब तक आपने टेबल के लिए लाइट स्कीमा चेंज को सक्षम किया है, तब तक आप डेटा टेबल में कॉलम का नाम बदल सकते हैं। यह हमारे लिए एक बड़ी मुसीबत बचाने वाला है। तिथि लेखन का अनुकूलन करें यहां कुछ अभ्यास दिए गए हैं, जिन्होंने हमारे दैनिक ऑफ़लाइन डेटा अंतर्ग्रहण समय को 75% तक कम कर दिया है और हमारा CUMU संघनन स्कोर 600+ से 100 हो गया है। फ़्लिंक प्री-एग्रीगेशन: जैसा कि ऊपर बताया गया है। राइटिंग बैच का ऑटो-साइज़िंग: फ़्लिंक संसाधन उपयोग को कम करने के लिए, हम डेटा को एक काफ्का विषय में विभिन्न डोरिस तालिकाओं में लिखने के लिए सक्षम करते हैं और डेटा राशि के आधार पर बैच आकार के स्वचालित परिवर्तन का एहसास करते हैं। डोरिस डेटा लेखन का अनुकूलन: टैबलेट और बाल्टियों के आकार के साथ-साथ प्रत्येक परिदृश्य के लिए संघनन मापदंडों को ठीक करें: max_XXXX_compaction_thread max_cumulative_compaction_num_singleton_deltas बीई कमिट लॉजिक का अनुकूलन: बीई सूचियों की नियमित कैशिंग करें, उन्हें बीई नोड्स बैच द्वारा बैच के लिए प्रतिबद्ध करें, और महीन भार संतुलन ग्रैन्युलैरिटी का उपयोग करें। प्रश्नों में डोरी-ऑन-ईएस का प्रयोग करें हमारे लगभग 60% डेटा प्रश्नों में समूह लक्ष्यीकरण शामिल है। समूह लक्ष्यीकरण फिल्टर के रूप में टैग के एक सेट का उपयोग करके हमारे लक्षित डेटा को खोजना है। यह हमारे डेटा प्रोसेसिंग आर्किटेक्चर के लिए कुछ आवश्यकताएं रखता है: एपीपी उपयोगकर्ताओं से संबंधित समूह लक्ष्यीकरण में बहुत जटिल तर्क शामिल हो सकते हैं। इसका मतलब है कि सिस्टम को एक साथ फिल्टर के रूप में सैकड़ों टैग का समर्थन करना चाहिए। अधिकांश समूह लक्ष्यीकरण परिदृश्यों के लिए केवल नवीनतम टैग डेटा की आवश्यकता होती है। हालाँकि, मीट्रिक प्रश्नों को ऐतिहासिक डेटा का समर्थन करने की आवश्यकता है। डेटा उपयोगकर्ताओं को समूह लक्ष्यीकरण के बाद मीट्रिक डेटा का और समग्र विश्लेषण करने की आवश्यकता हो सकती है। समूह लक्ष्यीकरण के बाद डेटा उपयोगकर्ताओं को टैग और मीट्रिक पर विस्तृत क्वेरी करने की भी आवश्यकता हो सकती है। विचार के बाद, हमने डोरिस-ऑन-ईएस को अपनाने का फैसला किया। डोरिस वह जगह है जहां हम प्रत्येक परिदृश्य के लिए मीट्रिक डेटा को एक विभाजन तालिका के रूप में संग्रहीत करते हैं, जबकि एलेस्टिक्स खोज सभी टैग डेटा संग्रहीत करता है। डोरिस-ऑन-ईएस समाधान डोरिस की वितरित क्वेरी योजना क्षमता और एलिस्टिक्स खोज की पूर्ण-पाठ खोज क्षमता को जोड़ती है। क्वेरी पैटर्न इस प्रकार है: SELECT tag, agg(metric) FROM Doris WHERE id in (select id from Es where tagFilter) GROUP BY tag जैसा कि दिखाया गया है, एलिस्टिक्स खोज में स्थित आईडी डेटा का उपयोग मीट्रिक विश्लेषण के लिए डोरिस में उप-क्वेरी में किया जाएगा। व्यवहार में, हम पाते हैं कि क्वेरी प्रतिक्रिया समय लक्ष्य समूह के आकार से संबंधित है। यदि लक्ष्य समूह में दस लाख से अधिक वस्तुएँ हैं, तो क्वेरी में 60 सेकंड तक का समय लगेगा। यदि यह और भी बड़ा है, तो टाइमआउट त्रुटि हो सकती है। जांच के बाद, हमने अपने दो सबसे बड़े समय बर्बाद करने वालों की पहचान की: I. जब डोरिस बीई एक लाख से अधिक वस्तुओं के लक्षित समूह के लिए एलियस्टिक्स खोज (डिफ़ॉल्ट रूप से एक समय में 1024 लाइनें) से डेटा खींचती है, तो नेटवर्क I/O ओवरहेड बहुत बड़ा हो सकता है। द्वितीय। डेटा खींचने के बाद, डोरिस बीई को शफल/ब्रॉडकास्ट के माध्यम से स्थानीय मीट्रिक टेबल के साथ जुड़ने के संचालन की आवश्यकता होती है, जिसमें बहुत अधिक खर्च हो सकता है। इस प्रकार, हम निम्नलिखित अनुकूलन करते हैं: एक क्वेरी सत्र चर जोड़ें जो निर्दिष्ट करता है कि अनुकूलन सक्षम करना है या नहीं। es_optimize ईएस में डेटा लेखन में, प्राथमिक कुंजी आईडी हैश होने के बाद बकेट नंबर को स्टोर करने के लिए एक बीके कॉलम जोड़ें। एल्गोरिथ्म डोरिस (CRC32) में बकेटिंग एल्गोरिथ्म के समान है। बकेट जॉइन एक्जीक्यूशन प्लान जनरेट करने के लिए डोरिस बीई का उपयोग करें, बीई स्कैननोड को बकेट नंबर भेजें और इसे ईएस तक नीचे धकेलें। क्वेरी किए गए डेटा को संपीड़ित करने के लिए ES का उपयोग करें; एकाधिक डेटा को एक में बदलें और नेटवर्क I/O ओवरहेड को कम करें। सुनिश्चित करें कि डोरिस बीई केवल स्थानीय मीट्रिक टेबल से संबंधित बकेट के डेटा को खींचती है और डोरिस बीई के बीच डेटा फेरबदल से बचने के लिए सीधे स्थानीय जॉइन ऑपरेशन करती है। परिणामस्वरूप, हम बड़े समूह लक्ष्यीकरण के लिए क्वेरी प्रतिक्रिया समय को 60 सेकंड से घटाकर आश्चर्यजनक रूप से 3.7 सेकंड कर देते हैं। सामुदायिक जानकारी से पता चलता है कि डोरिस 2.0.0 संस्करण के बाद से इन्वर्टेड इंडेक्सिंग का समर्थन करने जा रहा है, जो जल्द ही जारी होने वाला है। इस नए संस्करण के साथ, हम पाठ प्रकारों, समतुल्यता या पाठों, संख्याओं और डेटाटाइम की श्रेणी फ़िल्टरिंग पर पूर्ण-पाठ खोज करने में सक्षम होंगे, और फ़िल्टरिंग में AND, OR, NOT तर्क को आसानी से संयोजित कर सकेंगे क्योंकि उलटा अनुक्रमण सरणी प्रकारों का समर्थन करता है। डोरिस की इस नई सुविधा से एक ही कार्य में इलास्टिक्स खोज की तुलना में 3 ~ 5 गुना बेहतर प्रदर्शन देने की उम्मीद है। डेटा के प्रबंधन को परिष्कृत करें डोरिस की ठंडे और गर्म डेटा पृथक्करण की क्षमता डेटा प्रोसेसिंग में हमारी लागत में कमी की रणनीतियों की नींव प्रदान करती है। डोरिस के टीटीएल तंत्र के आधार पर, हम केवल मौजूदा वर्ष के डेटा को डोरिस में संग्रहीत करते हैं और कम भंडारण लागत के लिए टीडीडब्ल्यू में इससे पहले ऐतिहासिक डेटा डालते हैं। हम विभिन्न डेटा विभाजनों के लिए प्रतियों की संख्या बदलते हैं। उदाहरण के लिए, हम हाल के तीन महीनों के डेटा के लिए तीन कॉपी सेट करते हैं, जिसका अक्सर उपयोग किया जाता है, छह महीने से पुराने डेटा के लिए एक कॉपी और बीच के डेटा के लिए दो कॉपी सेट करते हैं। डोरिस हॉट डेटा को कोल्ड डेटा में बदलने का समर्थन करता है, इसलिए हम केवल पिछले सात दिनों के डेटा को SSD में स्टोर करते हैं और उससे पुराने डेटा को कम खर्चीले स्टोरेज के लिए HDD में ट्रांसफर करते हैं। निष्कर्ष यहाँ नीचे तक स्क्रॉल करने और इस लम्बे पठन को पूरा करने के लिए धन्यवाद। हमने खुशी-खुशी, सीखे गए सबक और कुछ अभ्यास साझा किए हैं जो क्लिकहाउस से डोरिस में हमारे संक्रमण के दौरान आपके लिए कुछ महत्वपूर्ण हो सकते हैं। हम वास्तव में अपाचे डोरिस समुदाय और सेलेक्टडीबी टीम की मदद की सराहना करते हैं, लेकिन हम अभी भी थोड़ी देर के लिए उनका पीछा कर रहे होंगे क्योंकि हम ठंडे और गर्म डेटा की ऑटो-पहचान का एहसास करने का प्रयास करते हैं, अक्सर उपयोग किए जाने वाले टैग/मेट्रिक्स की पूर्व-गणना, मटेरियलाइज्ड व्यूज का उपयोग करके कोड लॉजिक का सरलीकरण, और इसी तरह आगे भी।
