भारत में डिजिटल कॉमर्स के लिए अग्रणी पूर्ति मंच के रूप में, डेल्हीवरी साल के 365 दिन, प्रतिदिन दस लाख पैकेज पूरा करता है। इसके 24 स्वचालित सॉर्ट सेंटर, 101 हब, 3,100+ डायरेक्ट डिलीवरी सेंटर, 1000+ पार्टनर सेंटर, 11,000+ फ्लीट और 60,000+ टीम के सदस्य IoT उपकरणों के विशाल नेटवर्क की बदौलत सुचारू रूप से चलते हैं। हर सेकंड हजारों डेटा इवेंट और संदेश हमारी पाइपलाइनों में आ और जा रहे हैं। यह टेराबाइट्स में एक विशाल दैनिक डेटा मात्रा के बराबर है, जो हमारे और हमारे हितधारकों के लिए परिचालन दृश्यता को महत्वपूर्ण बनाता है।
आवश्यकताओं को पहचानते हुए, हमने डेटा मार्ट बनाने का निर्णय लिया - केंद्रीकृत, अंततः सुसंगत डेटाबेस जो उपयोगकर्ताओं को पूर्व-एकत्रित व्यावसायिक डेटा तक त्वरित पहुंच प्रदान करते हैं। यह हमारे हितधारकों को संपूर्ण डेटा वेयरहाउस में खोज किए बिना व्यावसायिक अंतर्दृष्टि तक तुरंत पहुंचने की अनुमति देता है।
हालाँकि, इस चुनौतीपूर्ण पैमाने के साथ, विश्लेषणात्मक कार्यभार के लिए क्षमता प्रदान करते हुए डेटा अखंडता और कम विलंबता को बनाए रखना एक बड़ी चुनौती थी।
इस ब्लॉग में, मैं अपने डेटा मार्ट को अमेज़ॅन ऑरोरा से TiDB, एक हाइब्रिड ट्रांजेक्शनल/एनालिटिकल प्रोसेसिंग (HTAP), वितरित SQL डेटाबेस में स्थानांतरित करते समय अपने सभी रुझानों को उजागर करने जा रहा हूं। उम्मीद है, यह पोस्ट डेटा इंजीनियरिंग नेताओं, डेटाबेस प्रशासकों, या डेटा आर्किटेक्ट्स को अंतर्दृष्टि प्रदान कर सकती है जो TiDB या किसी अन्य HTAP डेटाबेस में समान माइग्रेशन पर विचार कर रहे हैं।
डेल्हीवरी में वास्तविक समय डेटा मार्ट मामले को बेहतर ढंग से समझने के लिए, आइए पहले तीन अवधारणाओं से परिचित हों जो हमारे उपयोग के मामले के मूल में हैं: ओएलटीपी, ओएलएपी और एचटीएपी:
रीयल-टाइम डेटा मार्ट पारंपरिक डेटा मार्ट से इस मायने में भिन्न होते हैं कि वे विशिष्ट अंतराल पर नहीं, बल्कि वास्तविक समय में डेटा ग्रहण करते हैं। ये डेटा मार्ट दिल्ली में जमीनी परिचालन निर्णय लेने के लिए महत्वपूर्ण हैं क्योंकि हम इन घटनाओं को सिंक्रनाइज़ करने में कोई देरी नहीं कर सकते हैं।
हमारी वास्तविक समय डेटा मार्ट यात्रा 2020 में शुरू हुई जब हमने केंद्रीकृत डैशबोर्ड-विशेष रूप से EYE डैशबोर्ड की आवश्यकता की पहचान की। इस डैशबोर्ड का उद्देश्य जमीनी संचालन के लिए वास्तविक समय परिचालन दृश्यता प्रदान करना था, जिससे मिनट-दर-मिनट डेटा के आधार पर निर्णय लेने में सक्षम बनाया जा सके। उपयोग के उदाहरणों में शामिल हैं:
हमने रेडशिफ्ट और स्नोफ्लेक जैसे डेटा वेयरहाउस टूल का उपयोग करके अपने उपयोग के मामलों को हल करने के बारे में सोचा, लेकिन मर्ज के साथ-साथ वास्तविक समय डेटा अंतर्ग्रहण के लिए डिज़ाइन पैटर्न और आवश्यकता को देखते हुए इनमें से किसी भी समाधान ने हमारे लिए काम नहीं किया।
इस प्रकार, हमने शुरू में अपने डेटा मार्ट उपयोग के मामले की सेवा के लिए ऑरोरा (पोस्टग्रेएसक्यूएल) को चुना।
हमने स्पार्क स्ट्रीमिंग और ऑरोरा का उपयोग करके अपने वास्तविक समय डेटा मार्ट का निर्माण किया। हमारी स्टीमिंग पाइपलाइन बहुत सरल थी - काफ्का से डेटा पढ़ना, स्पार्क माइक्रो बैचों में डेटा संसाधित करना, और ऑरोरा में अप्सर्ट ऑपरेशन करना।
हमारा डेटाबेस एक बहुस्तरीय वास्तुकला का उपयोग करके तैयार किया गया था, जिसमें एक कच्ची परत, एक विभाजित परत और एक डेटा मार्ट परत शामिल है। उपयोगकर्ताओं के पास रॉ लेयर में डेटा देखने या संशोधित करने की पहुंच नहीं थी। विभाजित परत को सभी विभाजित तालिकाओं (आम तौर पर आयाम तालिकाएँ) को बनाए रखने के लिए रखा जाता है। नीचे हमारे डेटाबेस का एक सरल स्कीमा डिज़ाइन है:
सिस्टम ने शुरू में अच्छा प्रदर्शन किया, जब तक कि उसे प्रति सेकंड 3K संदेशों से अधिक थ्रूपुट को संभालना नहीं पड़ा। इसने कई चुनौतियों की शुरुआत को चिह्नित किया:
स्केलेबिलिटी सीमा: जैसे ही हमने प्रति सेकंड 3K संदेशों के थ्रूपुट को पार किया, ऑरोरा की इनपुट/आउटपुट ऑपरेशंस प्रति सेकंड (आईओपीएस) सीमाएं एक बाधा बन गईं। स्केलेबिलिटी बाधा ने हमारे परिचालन को प्रभावित करना शुरू कर दिया था।
सूजन की समस्या: प्रत्येक रिकॉर्ड अद्यतन के कारण एक नया रिकॉर्ड और एक मृत टुपल (रिकॉर्ड का पिछला संस्करण) का निर्माण हुआ। जब इन मृत टुपल्स की उत्पादन दर सफाई प्रक्रिया से आगे निकल गई, तो सूजन हो गई। चूँकि VACUUM FULL स्टोरेज का दावा करने में सक्षम नहीं था, डिस्क का उपयोग लगातार बढ़ता गया। लगभग 5 टीबी डेटा के लिए, ऑरोरा 30+ टीबी स्टोरेज का उपयोग कर रहा था।
रखरखाव का बोझ: सूजन की समस्या सीधे तौर पर हमारी रखरखाव चुनौतियों से जुड़ी हुई है। 70 से अधिक पाइपलाइनों और कुल राइट QPS 5k संदेश/सेकंड से अधिक होने के साथ, हमने पाया कि PostgreSQL की ऑटो क्लीनअप प्रक्रिया, ऑटो वैक्यूम, मृत टपल पीढ़ी की दर के साथ तालमेल रखने में विफल रही। इसलिए, डेटाबेस को पुनर्प्राप्त करने के लिए मैन्युअल रूप से VACUUM या VACUUM FULL चलाना आवश्यक है। PostgreSQL टूल जैसे pg_repack और pgcompacttable के साथ हमारे प्रयास भी असफल साबित हुए। नतीजतन, रखरखाव तेजी से जटिल और समय लेने वाला हो गया।
ऑरोरा की सीमाओं को हल करने के लिए, हमने एक बेहतर विकल्प ढूंढने का निर्णय लिया जो निम्नलिखित आवश्यकताओं को पूरा करता हो:
उपरोक्त सभी आवश्यकताओं को ध्यान में रखते हुए, हमने शुरू में स्पैनर और युगाबाइट सहित कई पोस्टग्रेएसक्यूएल विकल्पों की खोज की क्योंकि हम अपने परिवर्तन प्रबंधन को न्यूनतम रखना चाहते थे।
स्पैनर Google द्वारा प्रदान की जाने वाली एक वितरित SQL डेटाबेस प्रबंधन और भंडारण सेवा है। यह पूरी तरह से Google क्लाउड प्लेटफ़ॉर्म (GCP) पर प्रबंधित है। हालाँकि, हमने पाया कि निम्नलिखित कारणों से स्पैनर हमारे आर्किटेक्चर के लिए एक अच्छा उपयोग मामला नहीं हो सकता है:
YugabyteDB क्लाउड-नेटिव अनुप्रयोगों के लिए एक उच्च-प्रदर्शन लेनदेन संबंधी वितरित SQL डेटाबेस है, जिसे Yugabyte द्वारा विकसित किया गया है। यह डेटाबेस हमारे उपयोग के मामले के बहुत करीब है क्योंकि यह पूरी तरह से PostgreSQL अनुरूप, क्षैतिज रूप से स्केलेबल और पूरी तरह से वितरित था। दुर्भाग्य से, स्केलेबिलिटी के साथ इसकी सीमा के कारण यह उतना अच्छा काम नहीं कर सका, हमारे सफलता मानदंड ने प्रति सेकंड 7k+ लेनदेन की मांग की लेकिन युगाबाइट केवल 5k तक स्केल करने में सक्षम था।
हमने BigQuery जैसे अन्य संभावित उम्मीदवारों पर भी गौर किया, लेकिन उनमें से किसी ने भी हमारी आवश्यकताओं को पूरा नहीं किया।
उपरोक्त PostgreSQL विकल्पों के बाद, हमने अपनी आवश्यकताओं में HTAP जोड़ने का निर्णय लिया, जो हमें TiDB तक ले गया। यह आउट-ऑफ़-द-बॉक्स स्केलेबिलिटी, स्थिरता, उपलब्धता, मल्टी-साइट परिनियोजन टोपोलॉजी और कई अन्य सुविधाओं का समर्थन करता है। एक वितरित डेटाबेस के रूप में, TiDB में कई घटक होते हैं जो एक दूसरे के साथ संचार करते हैं और एक संपूर्ण TiDB प्रणाली बनाते हैं।
TiDB की निम्नलिखित विशेषताओं ने हमारी प्रमुख चुनौतियों का समाधान किया और हमारी परिचालन आवश्यकताओं को पूरा किया:
आसान स्केलिंग
TiDB आर्किटेक्चर डिज़ाइन कंप्यूटिंग को स्टोरेज से अलग करता है, जिससे आप आवश्यकतानुसार कंप्यूटिंग या स्टोरेज क्षमता को ऑनलाइन बढ़ा या बढ़ा सकते हैं। स्केलिंग प्रक्रिया एप्लिकेशन संचालन और रखरखाव कर्मचारियों के लिए पारदर्शी है।
ACID अनुरूप
TiDB MySQL-अनुरूप है और बॉक्स से बाहर लेनदेन का समर्थन करता है। यह आशावादी और निराशावादी दोनों प्रकार के लेनदेन का समर्थन करता है। यह इसे अन्य डेटाबेस से विशिष्ट बनाता है।
अत्यधिक उपलब्ध
TiKV डेटा को कई प्रतिकृतियों में संग्रहीत करता है और लेनदेन लॉग प्राप्त करने के लिए मल्टी-रफ़्ट प्रोटोकॉल का उपयोग करता है। कोई लेन-देन तभी किया जा सकता है जब डेटा अधिकांश प्रतिकृतियों में सफलतापूर्वक लिखा गया हो। जब कुछ प्रतिकृतियां नष्ट हो जाती हैं तो यह मजबूत स्थिरता और उच्च उपलब्धता की गारंटी देता है।
वास्तविक समय HTAP
TiDB एक ही आर्किटेक्चर में पंक्ति भंडारण (TiKV) और स्तंभ भंडारण (TiFlash) दोनों को जोड़ती है, जिससे एक सुव्यवस्थित तकनीकी स्टैक बनता है जो परिचालन डेटा पर वास्तविक समय विश्लेषण का उत्पादन करना आसान बनाता है।
हमारा TiDB बुनियादी ढांचा अग्रणी क्लाउड सेवा प्रदाताओं के VM पर तैनात है। हम क्लस्टर और सभी प्रशासनिक कार्यों को प्रबंधित करने के लिए TiUP, TiDB के पैकेज मैनेजर का उपयोग करते हैं। हमारा क्लस्टर 3 उपलब्ध क्षेत्रों (एजेड) पर तैनात है।
हमारे क्लस्टर कॉन्फ़िगरेशन इस प्रकार हैं:
अपने TiDB क्लस्टर को कई AZ में तैनात करके और हमारी प्रोसेसिंग और मेमोरी आवश्यकताओं को पूरा करने के लिए सावधानीपूर्वक नोड प्रकारों का चयन करके, हमने एक मजबूत, अत्यधिक उपलब्ध बुनियादी ढांचा तैयार किया है जो हमारी उच्च डेटा थ्रूपुट आवश्यकताओं को संभालने में सक्षम है।
इसे हमारे उपयोग के मामले में काम करने के लिए, हमने डेटाबेस को ट्यून करने के लिए पिंगकैप टीम के साथ मिलकर काम किया। हमारे द्वारा किए गए कुछ महत्वपूर्ण समायोजन यहां दिए गए हैं:
इंडेक्स शुरू करने से पहले निम्नलिखित पैरामीटर सेट करें।
SET @@global.tidb_ddl_reorg_worker_cnt = 16; SET @@global.tidb_ddl_reorg_batch_size = 4096;
सूचकांक निर्माण के बाद डिफ़ॉल्ट मानों पर रीसेट करें।
SET @@global.tidb_ddl_reorg_worker_cnt = 4; SET @@global.tidb_ddl_reorg_batch_size = 256;
यह मुख्य रूप से विभाजित तालिकाओं के लिए महत्वपूर्ण है। यह क्वेरी स्टेटमेंट में फ़िल्टर स्थितियों का विश्लेषण करता है और जब उनमें कोई आवश्यक डेटा नहीं होता है तो विभाजन को हटा देता है।
SET @@session.tidb_partition_prune_mode = 'dynamic';
यदि अधिक मात्रा में डेटा अंतर्ग्रहण किया जाता है तो कभी-कभी TiDB में ऑटो विश्लेषक विफल हो जाता है। उस स्थिति में, सभी क्वेरीज़ गलत निष्पादन योजना का उपयोग कर सकती हैं और पूरी तालिका को स्कैन कर सकती हैं। ऐसी स्थिति से बचने के लिए हमने TiDB कॉन्फ़िगरेशन में निम्नलिखित परिवर्तन किए:
set global tidb_max_auto_analyze_time = 86400; set global tidb_enable_pseudo_for_outdated_stats = off; set global tidb_sysproc_scan_concurrency = 15;
यदि आप विभाजित तालिकाओं के साथ काम कर रहे हैं, तो हमारा सुझाव है कि आप विश्लेषण विफलताओं से बचने के लिए एक समय में एक विभाजन के लिए विश्लेषण तालिका संचालन मैन्युअल रूप से चलाएं।
इस तरह के समायोजन के माध्यम से, हम TiDB के अपने उपयोग को प्रभावी ढंग से सुव्यवस्थित करने में सक्षम थे, ताकि हम अपने वास्तविक समय डेटा मार्ट के लिए इष्टतम प्रदर्शन प्राप्त कर सकें।
बेहतर क्वेरी प्रदर्शन
हमने 400+ क्वेरीज़ को बेंचमार्क किया है और पाया है कि सभी क्वेरीज़ SLA के भीतर चल रही हैं। हमने P95 क्वेरीज़ के प्रदर्शन में 15-20% की वृद्धि भी देखी है।
आसान प्रवास
हमने अपनी तालिका के सभी ऐतिहासिक डेटा को पोस्टग्रेज से TiDB में स्थानांतरित करने के लिए TiDB लाइटिंग टूल का उपयोग किया। इस टूल का उपयोग करना बहुत आसान है और यह बहुत तेज़ है। हम लगभग 2-3 घंटों के भीतर टेराबाइट डेटा लोड करने में सक्षम थे। हालाँकि, यह ध्यान देने योग्य है कि इतने बड़े डेटा को लोड करने से पहले बहुत अधिक ट्यूनिंग की आवश्यकता होती है।
मजबूत समर्थन
हम उत्पादन बुनियादी ढांचे की स्थापना के दौरान कुछ बाधाओं से गुज़रे लेकिन पिंगकैप सपोर्ट टीम ने बहुत महत्वपूर्ण भूमिका निभाई और कार्यभार की प्रकृति के लिए क्लस्टर को ट्यून करने में हमारी मदद की।
इस पोस्ट में, हमने वास्तविक समय डेटा मार्ट के हमारे उपयोग के मामले और TiDB में माइग्रेशन यात्रा के साथ ऑरोरा का उपयोग करने की चुनौतियों का पता लगाया है। हमने इस बात पर भी चर्चा की कि दिल्लीवेरी बड़े पैमाने पर TiDB का उपयोग कैसे कर रही है।
TiDB के साथ हमारी सफलता के बावजूद, हम स्वीकार करते हैं कि कोई भी समाधान सही नहीं है, और उपयोग के मामले के आधार पर प्रभावशीलता भिन्न हो सकती है। TiDB में, हमने सुधार के लिए कुछ क्षेत्रों पर ध्यान दिया, जिसमें भौतिक विचारों और मूल कोटा प्रबंधन के लिए आउट-ऑफ़-द-बॉक्स समर्थन की कमी शामिल है। हालाँकि, उचित समाधान और समायोजन के साथ, हम इन सीमाओं को प्रभावी ढंग से संबोधित करने में कामयाब रहे हैं।
अब तक, हमने अपने उत्पादन परिवेश में TiDB को तैनात किया है। हमारे बेंचमार्क के आधार पर, TiDB हमें 100ms से कम विलंबता के साथ प्रति सेकंड हजारों अनुरोधों को संभालने में सक्षम बनाता है। आगे बढ़ते हुए, हम अधिक उपयोग के मामलों का पता लगाना जारी रखेंगे जिनके लिए एक मजबूत, लगातार वितरित डेटाबेस की आवश्यकता होती है।
https://docs.pingcap.com/tidb/stable/tidb-lightning-overview
https://reorg.github.io/pg_repack/
https://github.com/dataegret/pgcompacttable
https://cloud.google.com/spanner
https://www.yugabyte.com/yugabytedb/
https://cloud.google.com/bigquery/
https://docs.pingcap.com/tidb/dev/transaction-overview
https://proxysql.com/
हरि किशन (वरिष्ठ इंजीनियरिंग प्रबंधक @ डेल्हीवरी)
आकाश दीप वर्मा (प्रौद्योगिकी निदेशक @ डेल्हीवरी)