How Coralogix cut processing times from 30 seconds to 86 milliseconds with a PostgreSQL to ScyllaDB migration. गति के बारे में Coralogix एक वास्तविक समय स्ट्रीमिंग विश्लेषण पाइपलाइन का उपयोग करता है, जो निगरानी, विज़ुअलाइज़ेशन और अलार्म करने की क्षमताओं को प्रदान करता है, जो इंडेक्सिंग की आवश्यकता नहीं है। कॉरपोरेट Coralogix के मुख्य विभेदकों में से एक एक वितरित पूछताछ इंजन है जो रिमोट स्टोरेज में एक ग्राहक के आर्केजिंग से मैप किए गए डेटा पर तेजी से पूछताछ करता है। प्रारंभ में इसे आधारभूत ऑब्जेक्ट स्टोरेज के शीर्ष पर एक स्टेटलेस पूछताछ इंजन के रूप में डिज़ाइन किया गया था, लेकिन पूछताछ निष्पादन के दौरान पार्केट मेटाडेटा को पढ़ना एक अस्वीकार्य लाटेशन हिट का परिचय दिया। पार्किंग मूल मेटास्टोर कार्यान्वयन, PostgreSQL पर बनाया गया, उनकी जरूरतों के लिए पर्याप्त तेजी से नहीं था. इसलिए, टीम ने एक नई कार्यान्वयन की कोशिश की – इस बार, PostgreSQL के बजाय ScyllaDB के साथ. स्पॉइलर: यह काम किया। उन्होंने प्रभावशाली प्रदर्शन लाभ हासिल किया – 30 सेकंड से 86 मिलीसेकंड तक पूछताछ प्रसंस्करण समय को कम किया। ScyllaDB Summit 24 पर हमारे साथ शामिल हों ताकि आप यह सुन सकें कि टीमें अपने सबसे कठिन डेटाबेस चुनौतियों का सामना कैसे कर रही हैं. Disney, Discord, Expedia, Supercell, Paramount और अधिक सभी एजेंडे पर हैं। ScyllaDB Summit 2024 अब एक Wrap है! Update: मेटास्टोर प्रेरणा और आवश्यकताएं मेटास्टोर कार्यान्वयन के विवरण में जाने से पहले, चलो एक कदम वापस लेते हैं और सबसे पहले एक मेटास्टोर बनाने के लिए तर्क को देखते हैं। "हमने शुरुआत में इस प्लेटफार्म को आधारभूत ऑब्जेक्ट स्टोरेज के शीर्ष पर एक स्टेटलेस पूछताछ इंजन के रूप में डिज़ाइन किया - लेकिन हमने जल्दी से महसूस किया कि पूछताछ संचालन के दौरान पार्केट मेटाडेटा को पढ़ने की लागत पूछताछ के समय का एक बड़ा प्रतिशत है," डेन हैरिस ने समझाया। उन्होंने एक समाधान की कल्पना की जो: उच्च स्केलेबलता और प्रसारण के लिए एक टूटे हुए प्रारूप में Parquet मेटाडेटा को संग्रहीत करें प्रत्येक पूछताछ के लिए स्कैन करने के लिए फ़ाइलों को कुशलता से पहचानने के लिए फ्लोम फ़िल्टर का उपयोग करें लेन-देन कमिट लॉग का उपयोग लेन-देन में मौजूदा डेटा को जोड़ने, अपडेट करने और प्रतिस्थापन करने के लिए। मुख्य आवश्यकताओं में कम लाटेनता, पढ़ने / लिखने की क्षमता दोनों के संदर्भ में स्केलेबलता और आधारभूत भंडारण की स्केलेबलता शामिल थी. और आवश्यक चरम स्केलेबलता को समझने के लिए, इस पर विचार करें: प्रति घंटे 2,000 Parquet फ़ाइल उत्पन्न करता है (50,000 प्रति दिन), प्रति दिन कुल 15 TB, केवल Parquet मेटाडेटा में 20 GB का परिणाम . एक ही ग्राहक एक दिन के लिए एक ही ग्राहक एक दिन के लिए प्रारंभिक PostgreSQL अनुप्रयोग "हमने पोस्टग्रेस पर प्रारंभिक कार्यान्वयन शुरू किया, उस समय यह समझते हुए कि एक गैर-प्रसारित इंजन लंबे समय तक पर्याप्त नहीं होगा," डेन ने स्वीकार किया। कि मूल कार्यान्वयन में "ब्लॉक" जैसे महत्वपूर्ण जानकारी संग्रहीत थी, जो एक पंक्ति समूह और एक पार्केट फ़ाइल का प्रतिनिधित्व करती थी। Block url: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Row group: 0, 1, 2 … Min timestamp Max timestamp Number of rows Total size … पढ़ने के लिए अनुकूलित करने के लिए, उन्होंने प्रभावी डेटा काटने के लिए फ्लोम फ़िल्टर का उपयोग किया। डेन ने विस्तार से कहा, "अभी तक, हम पूर्ण पाठ खोज की तरह कुछ का समर्थन करना चाहते हैं। मूल रूप से, जब हम अपने सिस्टम में इन फ़ाइलों को इंजेक्ट करते हैं, तो हम फ़ाइल में पाए जाने वाले सभी अलग-अलग टोकनों के लिए फ्लोम फ़िल्टर का निर्माण कर सकते हैं। इसके अलावा, उन्होंने प्रत्येक Parquet फ़ाइल के लिए स्तंभ मेटाडेटा संग्रहीत किया। Block URL Row Group Column Name Column metadata (blob) डेन ने समझाया: "हम जो फ़ाइल लिख रहे हैं वे काफी व्यापक हैं, कभी-कभी 20,000 स्तंभ तक। ScyllaDB का उपयोग करना इसके बाद, चलो ScyllaDB कार्यान्वयन को देखते हैं जैसा कि डेन के टीम के साथी, सेबस्टेन वर्क्रूइज़ द्वारा वर्णित किया गया है। ब्लॉक डेटा मॉडलिंग नए कार्यान्वयन के लिए ब्लॉक मॉडलिंग को फिर से देखा जाना पड़ा. यहाँ एक ब्लॉक यूआरएल का एक उदाहरण है: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet हिम्मत का हिस्सा ग्राहक के शीर्ष स्तर के बक्से है; बक्से के अंदर, वस्तुओं को घंटे के अनुसार विभाजित किया जाता है. इस मामले में, प्राथमिक कुंजी के रूप में क्या उपयोग किया जाना चाहिए? लेकिन कुछ ग्राहकों के पास अन्य ग्राहकों की तुलना में बहुत अधिक पार्केट फ़ाइल हैं, और वे चीजों को संतुलित रखना चाहते थे ((ब्लॉक यूआरएल, पंक्ति समूह))? यह एक निश्चित ब्लॉक को अद्वितीय रूप से पहचानता है, लेकिन एक निश्चित दिन के लिए सभी ब्लॉकों को सूचीबद्ध करना मुश्किल होगा क्योंकि टाइमस्टैम कुंजी में नहीं है ((Table url, time))? यह काम करता है क्योंकि यदि आपके पास पूछने के लिए 24 घंटे हैं, तो आप काफी आसानी से पूछ सकते हैं ((Table url, time), block url, row group)? यही उन्होंने चुना है. ब्लॉक url और row group को क्लास्टिंग कुंजी के रूप में जोड़कर, वे आसानी से एक घंटे के भीतर एक विशिष्ट ब्लॉक प्राप्त कर सकते हैं, जो ब्लॉक और row groups को अपडेट या हटाने की प्रक्रिया को भी सरल बनाता है। ब्लूम फ़िल्टर Chunking और डेटा मॉडलिंग अगली चुनौती: यह कैसे सत्यापित करें कि कुछ बिट्स सेट किए गए हैं, यह देखते हुए कि ScyllaDB इसके लिए बॉक्स-ऑफ-ऑफ कार्यों की पेशकश नहीं करता है। टीम ने फ्लोम फ़िल्टर को पढ़ने और उन्हें एप्लिकेशन में संसाधित करने का फैसला किया। हालांकि, याद रखें कि वे प्रति ग्राहक प्रति दिन 50,000 ब्लॉक के साथ काम कर रहे हैं, प्रत्येक ब्लॉक में फ्लोम फ़िल्टर भाग के लिए 262 KB होता है। यह कुल 12 जीबी है – एक पूछताछ के लिए एप्लिकेशन में वापस खींचने के लिए बहुत अधिक। लेकिन उन्हें हर बार पूरे फ्लोम फ़िल्टर को पढ़ने की आवश्यकता नहीं थी; उन्हें केवल इसके हिस्सों की ज़रूरत थी, पूछताछ संचालन के दौरान डेटा मॉडलिंग के लिए, एक विकल्प का उपयोग करना था प्राथमिक कुंजी के रूप में। यह 8192 बैट प्रति फ्लोम फ़िल्टर के 32 बैट का उत्पन्न करेगा, जिसके परिणामस्वरूप प्रति विभाजन के बारे में 262 KB के साथ एक समान वितरण होगा। एक ही विभाजन में प्रत्येक फ्लोम फ़िल्टर के साथ, एक ही बैच पूछताछ के साथ डेटा डालना और हटाना आसान होगा। लेकिन एक पकड़ है जो पढ़ने की दक्षता को प्रभावित करता है: आपको फ्लोम फ़िल्टर को पढ़ने से पहले ब्लॉक के आईडी को जानने की आवश्यकता होगी। इसके अलावा, दृष्टिकोण में 50K ब्लॉक 50K विभाजनों का उपयोग करना शामिल होगा। और जैसा कि सेबियन ने नोट किया, "स्काइलडब्ब की तरह कुछ तेजी से, यह अभी भी 50K विभाजनों के लिए से (block_url, row_group, chunk index ) एक और विकल्प (जिस पर उन्होंने अंततः फैसला किया): ध्यान दें कि यह ब्लॉकों के समान विभाजन कुंजी है, जिसमें विभाजन कुंजी के लिए एक इंडेक्स जोड़ा गया है जो पूछताछ इंजन द्वारा आवश्यक nth टोकन का प्रतिनिधित्व करता है. इस दृष्टिकोण के साथ, एक 24 घंटे की विंडो में 5 टोकन स्कैन 120 विभाजनों का परिणाम देता है - पिछले डेटा मॉडलिंग विकल्प की तुलना में एक प्रभावशाली सुधार। ((table url, time, chunk index), ब्लॉक url, row group) इसके अलावा, इस दृष्टिकोण को अब फ्लोम फ़िल्टर को पढ़ने से पहले ब्लॉक आईडी की आवश्यकता नहीं है - जो तेजी से पढ़ने की अनुमति देता है। बेशक, हमेशा समझौता होते हैं। यहां, ब्लॉक फ्लोम फ़िल्टर दृष्टिकोण के कारण, उन्हें एकल फ्लोम फ़िल्टर को 8192 अद्वितीय विभाजनों में विभाजित करना पड़ता है। यह पिछले विभाजन दृष्टिकोण की तुलना में निषेचन की गति को प्रभावित करता है जो सभी फ्लोम फ़िल्टर टुकड़ों को एक बार में निषेध करने की अनुमति देता है। हालांकि, एक घंटे के भीतर एक दिए गए ब्लॉक को तेजी से पढ़ने की क्षमता तेजी से लिखने की तुलना में उनके लिए अधिक महत्वपूर्ण है - इसलिए डेटा मॉडलिंग बुरे आश्चर्य की बात नहीं है, SQL से NoSQL करने के लिए स्थानांतरण में कुछ परीक्षण और त्रुटि सहित डेटा मॉडलिंग पुन: कार्य शामिल था. उदाहरण के लिए, सेंस्टेन ने साझा किया, "एक दिन, मुझे एहसास हुआ कि हम मिन और मैक्स टाइमस्टैम्प्स को गड़बड़ कर चुके थे - और मुझे आश्चर्य हुआ कि मैं इसे कैसे ठीक करने जा रहा था. मैंने सोचा कि शायद मैं स्तंभों को पुनः नामित कर सकता हूं और फिर किसी तरह इसे फिर से काम कर सकता हूं. लेकिन, यहां आप एक स्तंभ को पुनः नामित नहीं कर सकते हैं यदि यह एक क्लॉस्टिंग कुंजी का हिस्सा है. मैंने सोचा कि मैं निश्चित रूप से नए स्तंभों को जोड़ सकता हूं और सभी पंक्तियों को अपडेट करने के लिए आखिरकार, उन्होंने तालिका को काटने का फैसला किया और फिर से शुरू करने का फैसला किया. इस फ्रंट पर उनका सबसे अच्छा सलाह यह है कि पहली बार सही हो जाए. 🙂 प्रदर्शन लाभ डेटा मॉडलिंग के लिए आवश्यक काम के बावजूद, प्रवास ने अच्छी तरह से भुगतान किया। प्रत्येक नोड वर्तमान में 4-5 TB को संभालता है। वे वर्तमान में P99 लेटेन के साथ प्रति सेकंड लगभग 10K लिख रहे हैं, जो लगातार एक मिलीसेकंड से नीचे है। ब्लॉक लिस्टिंग एक घंटे में लगभग 2000 पार्केट फ़ाइलों का परिणाम देता है; उनके फ्लोम फ़िल्टर के साथ, उन्हें 20 मिलीसेकंड से भी कम समय में संसाधित किया जाता है। 50K फ़ाइलों के लिए, यह 500 मिलीसेकंड से कम है। वे बिट्स की जाँच भी करते हैं. लेकिन, 50K पार्केट फ़ाइलों के लिए, 500 मिलीसेकंड उनकी जरूरतों के लिए ठीक है. कॉलम मेटाडेटा प्रसंस्करण में, P50 काफी अच्छा है, लेकिन एक उच्च रीढ़ लाटेनता है. सेबस्टेन ने समझाया: "समय यह है कि यदि हमारे पास 50K पार्केट फ़ाइलें हैं, तो हमारे निष्पादक इन सभी को समानांतर रूप से प्राप्त कर रहे हैं. इसका मतलब है कि हमारे पास एक साथ कई पूछताछ हैं और हम सबसे अच्छे डिस्क का उपयोग नहीं कर रहे हैं. हम मानते हैं कि यह समस्या की जड़ में है। ScyllaDB सेटअप उल्लेखनीय रूप से, Coralogix ने पहली बार ScyllaDB की खोज से केवल 2 महीनों में डेटा के टेराबाइट के साथ उत्पादन में प्रवेश करने के लिए चले गए (और यह एक SQL को NoSQL माइग्रेशन था जिसमें डेटा मॉडलिंग काम की आवश्यकता थी, बहुत अधिक सरल Cassandra या DynamoDB माइग्रेशन नहीं)। Rust पर शीर्ष पर लिखा गया है और उन्होंने पाया , और क्योंकि Coralogix के लिए अपने ग्राहकों को एक कम लागत के निरीक्षण विकल्प की पेशकश करना महत्वपूर्ण है, Coralogix टीम अपने ScyllaDB बुनियादी ढांचे के अनुकूल मूल्य प्रदर्शन से खुश थी: एक 3-नोड क्लस्टर के साथ: ScyllaDB Rust ड्राइवर Kubernetes के लिए ScyllaDB ऑपरेटर ScyllaDB निगरानी ScyllaDB प्रबंधक 8 वीसीपी 32 जीबी मेमोरी हथियार / Graviton ईबीएस वॉल्यूम (gp3) 500 एमबीपीएस बैंडविड्थ और 12k आईओपीएस के साथ ARM का उपयोग करने से लागत कम हो जाती है, और EBS (gp3) वॉल्यूम का उपयोग करने का निर्णय अंततः उपलब्धता, लचीलापन और मूल्य प्रदर्शन पर आ गया. उन्होंने स्वीकार किया, "यह एक विवादास्पद निर्णय है - लेकिन हम इसे काम करने की कोशिश कर रहे हैं और हम देखेंगे कि हम कब तक संभाल सकते हैं। सीखने के सबक इनमें से कुछ महत्वपूर्ण सबक यहां सीखे गए हैं... ScyllaDB के साथ काम करने और Postgres के साथ काम करने में सबसे बड़ा अंतर यह है कि आपको अपने विभाजन और विभाजन आकार के बारे में काफी सावधानीपूर्वक सोचना होगा। Keep an eye on partition sizes: आपको पढ़ने / लिखने के पैटर्न के बारे में भी सावधानीपूर्वक सोचने की जरूरत है. क्या आपका कार्य भार पढ़ने के लिए भारी है? क्या इसमें पढ़ने और लिखने के अच्छे मिश्रण शामिल हैं? या, यह ज्यादातर लिखने के लिए भारी है? Coralogix के कार्य भार काफी लिखने के लिए भारी हैं क्योंकि वे लगातार डेटा को अवशोषित कर रहे हैं, लेकिन उन्हें पढ़ने के लिए प्राथमिकता देने की आवश्यकता है क्योंकि पढ़ने की लाटेंशन उनके व्यवसाय के लिए सबसे महत्वपूर्ण है। Think about read/write patterns: टीम ने स्वीकार किया कि उन्हें ईबीएस का उपयोग न करने के लिए चेतावनी दी गई थी: "हमने नहीं सुना, लेकिन हमें शायद करना चाहिए. यदि आप स्काइललाडीबी का उपयोग करने पर विचार कर रहे हैं, तो शायद यह एक अच्छा विचार होगा कि EBS वॉल्यूम का उपयोग करने की कोशिश करने के बजाय स्थानीय एसएसडी हैं। Avoid EBS: भविष्य की योजनाएं: Rust के साथ WebAssembly UDFs भविष्य में, वे पर्याप्त बड़े टुकड़ों को लिखने और अनावश्यक डेटा को पढ़ने के बीच मध्यम भूमि खोजना चाहते हैं. वे टुकड़ों को ~8,000 पंक्तियों में विभाजित कर रहे हैं और मानते हैं कि वे उन्हें 1,000 पंक्तियों में और भी विभाजित कर सकते हैं, जो उनके इनपुट को तेज कर सकते हैं. उनका अंतिम लक्ष्य ScyllaDB पर और भी अधिक काम अपलोड करना है उनके मौजूदा रस्ट कोड के साथ, यूडीएफ को एकीकृत करना एप्लिकेशन में डेटा को वापस भेजने की आवश्यकता को खत्म करेगा, जो समायोजनों और संभावित सुधारों के लिए लचीलापन प्रदान करेगा। WebAssembly के साथ उपयोगकर्ता परिभाषित कार्य (UDFs) Sebastian साझा करता है, "हम पहले से ही सब कुछ रूस्ट में लिखा है. यह वास्तव में अच्छा होगा अगर हम यूडीएफ का उपयोग करना शुरू कर सकते हैं ताकि हमें एप्लिकेशन में कुछ भी वापस भेजने की ज़रूरत न हो। पूरी तकनीकी बातचीत देखें आप पूरी तकनीकी बातचीत देख सकते हैं और हमारी तकनीकी बातचीत पुस्तकालय में डेक के माध्यम से स्केम कर सकते हैं। Cynthia Dunlop के बारे में राय Cynthia ScyllaDB में सामग्री रणनीति के वरिष्ठ निदेशक है. वह 20 से अधिक वर्षों से सॉफ्टवेयर विकास और गुणवत्ता इंजीनियरिंग के बारे में लिख रहा है।
