डेल्हीवरी का डेटा मार्ट - ओएलटीपी से एचटीएपी तक प्रवासन यात्रा

भारत में डिजिटल कॉमर्स के लिए अग्रणी पूर्ति मंच के रूप में, डेल्हीवरी साल के 365 दिन, प्रतिदिन दस लाख पैकेज पूरा करता है। इसके 24 स्वचालित सॉर्ट सेंटर, 101 हब, 3,100+ डायरेक्ट डिलीवरी सेंटर, 1000+ पार्टनर सेंटर, 11,000+ फ्लीट और 60,000+ टीम के सदस्य IoT उपकरणों के विशाल नेटवर्क की बदौलत सुचारू रूप से चलते हैं। हर सेकंड हजारों डेटा इवेंट और संदेश हमारी पाइपलाइनों में आ और जा रहे हैं। यह टेराबाइट्स में एक विशाल दैनिक डेटा मात्रा के बराबर है, जो हमारे और हमारे हितधारकों के लिए परिचालन दृश्यता को महत्वपूर्ण बनाता है।

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

हालाँकि, इस चुनौतीपूर्ण पैमाने के साथ, विश्लेषणात्मक कार्यभार के लिए क्षमता प्रदान करते हुए डेटा अखंडता और कम विलंबता को बनाए रखना एक बड़ी चुनौती थी।

इस ब्लॉग में, मैं अपने डेटा मार्ट को अमेज़ॅन ऑरोरा से TiDB, एक हाइब्रिड ट्रांजेक्शनल/एनालिटिकल प्रोसेसिंग (HTAP), वितरित SQL डेटाबेस में स्थानांतरित करते समय अपने सभी रुझानों को उजागर करने जा रहा हूं। उम्मीद है, यह पोस्ट डेटा इंजीनियरिंग नेताओं, डेटाबेस प्रशासकों, या डेटा आर्किटेक्ट्स को अंतर्दृष्टि प्रदान कर सकती है जो TiDB या किसी अन्य HTAP डेटाबेस में समान माइग्रेशन पर विचार कर रहे हैं।

ओएलटीपी, ओएलएपी और एचटीएपी

डेल्हीवरी में वास्तविक समय डेटा मार्ट मामले को बेहतर ढंग से समझने के लिए, आइए पहले तीन अवधारणाओं से परिचित हों जो हमारे उपयोग के मामले के मूल में हैं: ओएलटीपी, ओएलएपी और एचटीएपी:

• ओएलटीपी: ऑनलाइन लेनदेन प्रसंस्करण (ओएलटीपी) सिस्टम लेनदेन-उन्मुख अनुप्रयोगों के लिए डिज़ाइन किए गए हैं, जो एसीआईडी (परमाणुता, स्थिरता, अलगाव, स्थायित्व) गुणों के माध्यम से डेटा अखंडता सुनिश्चित करते हैं।
• ओएलएपी: ऑनलाइन एनालिटिकल प्रोसेसिंग (ओएलएपी) सिस्टम बड़े डेटा वॉल्यूम के उच्च गति, बहुआयामी विश्लेषण को सक्षम बनाता है, जो डेटा-संचालित निर्णय लेने में सहायता करता है।
• HTAP: हाइब्रिड ट्रांजेक्शन/एनालिटिकल प्रोसेसिंग (HTAP) OLTP और OLAP कार्यात्मकताओं को जोड़ती है, जिससे ट्रांजेक्शनल डेटा पर वास्तविक समय विश्लेषण की अनुमति मिलती है।

डेल्हीवरी में रीयल-टाइम डेटा मार्ट उपयोग मामला

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

हमारी वास्तविक समय डेटा मार्ट यात्रा 2020 में शुरू हुई जब हमने केंद्रीकृत डैशबोर्ड-विशेष रूप से EYE डैशबोर्ड की आवश्यकता की पहचान की। इस डैशबोर्ड का उद्देश्य जमीनी संचालन के लिए वास्तविक समय परिचालन दृश्यता प्रदान करना था, जिससे मिनट-दर-मिनट डेटा के आधार पर निर्णय लेने में सक्षम बनाया जा सके। उपयोग के उदाहरणों में शामिल हैं:

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

प्रारंभिक कार्यान्वयन और चुनौतियाँ

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

इस प्रकार, हमने शुरू में अपने डेटा मार्ट उपयोग के मामले की सेवा के लिए ऑरोरा (पोस्टग्रेएसक्यूएल) को चुना।

अरोरा के आसपास डेटा अंतर्ग्रहण प्रक्रिया

हमने स्पार्क स्ट्रीमिंग और ऑरोरा का उपयोग करके अपने वास्तविक समय डेटा मार्ट का निर्माण किया। हमारी स्टीमिंग पाइपलाइन बहुत सरल थी - काफ्का से डेटा पढ़ना, स्पार्क माइक्रो बैचों में डेटा संसाधित करना, और ऑरोरा में अप्सर्ट ऑपरेशन करना।

हमारा डेटाबेस एक बहुस्तरीय वास्तुकला का उपयोग करके तैयार किया गया था, जिसमें एक कच्ची परत, एक विभाजित परत और एक डेटा मार्ट परत शामिल है। उपयोगकर्ताओं के पास रॉ लेयर में डेटा देखने या संशोधित करने की पहुंच नहीं थी। विभाजित परत को सभी विभाजित तालिकाओं (आम तौर पर आयाम तालिकाएँ) को बनाए रखने के लिए रखा जाता है। नीचे हमारे डेटाबेस का एक सरल स्कीमा डिज़ाइन है:

अरोरा के साथ हमें चुनौतियों का सामना करना पड़ा

सिस्टम ने शुरू में अच्छा प्रदर्शन किया, जब तक कि उसे प्रति सेकंड 3K संदेशों से अधिक थ्रूपुट को संभालना नहीं पड़ा। इसने कई चुनौतियों की शुरुआत को चिह्नित किया:

• स्केलेबिलिटी सीमा: जैसे ही हमने प्रति सेकंड 3K संदेशों के थ्रूपुट को पार किया, ऑरोरा की इनपुट/आउटपुट ऑपरेशंस प्रति सेकंड (आईओपीएस) सीमाएं एक बाधा बन गईं। स्केलेबिलिटी बाधा ने हमारे परिचालन को प्रभावित करना शुरू कर दिया था।

  
  

• सूजन की समस्या: प्रत्येक रिकॉर्ड अद्यतन के कारण एक नया रिकॉर्ड और एक मृत टुपल (रिकॉर्ड का पिछला संस्करण) का निर्माण हुआ। जब इन मृत टुपल्स की उत्पादन दर सफाई प्रक्रिया से आगे निकल गई, तो सूजन हो गई। चूँकि VACUUM FULL स्टोरेज का दावा करने में सक्षम नहीं था, डिस्क का उपयोग लगातार बढ़ता गया। लगभग 5 टीबी डेटा के लिए, ऑरोरा 30+ टीबी स्टोरेज का उपयोग कर रहा था।

  
  

• रखरखाव का बोझ: सूजन की समस्या सीधे तौर पर हमारी रखरखाव चुनौतियों से जुड़ी हुई है। 70 से अधिक पाइपलाइनों और कुल राइट QPS 5k संदेश/सेकंड से अधिक होने के साथ, हमने पाया कि PostgreSQL की ऑटो क्लीनअप प्रक्रिया, ऑटो वैक्यूम, मृत टपल पीढ़ी की दर के साथ तालमेल रखने में विफल रही। इसलिए, डेटाबेस को पुनर्प्राप्त करने के लिए मैन्युअल रूप से VACUUM या VACUUM FULL चलाना आवश्यक है। PostgreSQL टूल जैसे pg_repack और pgcompacttable के साथ हमारे प्रयास भी असफल साबित हुए। नतीजतन, रखरखाव तेजी से जटिल और समय लेने वाला हो गया।

• लागत: पढ़ने और लिखने के कार्यभार को समायोजित करने के लिए, हमें उच्चतम उपलब्ध नोड्स (24XLarge) तक स्केल करना था। इससे तीन-नोड ऑरोरा क्लस्टर के लिए प्रति माह लगभग $100,000 का खर्च आया। इस पैमाने के साथ, IOPS ऑटो-स्केलिंग के कारण ऑरोरा महंगा साबित हुआ।

विकल्प की तलाश की जा रही है

ऑरोरा की सीमाओं को हल करने के लिए, हमने एक बेहतर विकल्प ढूंढने का निर्णय लिया जो निम्नलिखित आवश्यकताओं को पूरा करता हो:

• उच्च राइट क्यूपीएस के साथ स्केलेबल: डेटाबेस को कम से कम 10k+ राइट क्यूपीएस का समर्थन करना चाहिए और क्षैतिज रूप से स्केलेबल होना चाहिए।
• वास्तविक समय विश्लेषण: डेटाबेस को उच्च गति या वास्तविक समय OLAP क्षमताएं प्रदान करने में सक्षम होना चाहिए
• पूरी तरह से वितरित: उच्च उपलब्धता और दोष सहनशीलता प्रदान करने के लिए डेटाबेस को कई साइटों पर वितरित किया जाना चाहिए।
• मजबूत स्थिरता: डेटाबेस को मजबूत स्थिरता बनाए रखनी चाहिए, यह सुनिश्चित करते हुए कि सभी उपयोगकर्ता समान डेटा देखें।

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

नापनेवाला

स्पैनर Google द्वारा प्रदान की जाने वाली एक वितरित SQL डेटाबेस प्रबंधन और भंडारण सेवा है। यह पूरी तरह से Google क्लाउड प्लेटफ़ॉर्म (GCP) पर प्रबंधित है। हालाँकि, हमने पाया कि निम्नलिखित कारणों से स्पैनर हमारे आर्किटेक्चर के लिए एक अच्छा उपयोग मामला नहीं हो सकता है:

• स्पैनर स्कीमा का समर्थन नहीं करता.
• हमें ऐतिहासिक डेटा लोड करने के लिए उचित उपकरण नहीं मिले। हमने स्पैनर मूल्यांकन और माइग्रेशन के लिए एक ओपन-सोर्स टूल हार्बरब्रिज की खोज की। हालाँकि, इसमें 100 जीबी डेटा लोडिंग की सीमाएँ थीं।

युगाबाइट

YugabyteDB क्लाउड-नेटिव अनुप्रयोगों के लिए एक उच्च-प्रदर्शन लेनदेन संबंधी वितरित SQL डेटाबेस है, जिसे Yugabyte द्वारा विकसित किया गया है। यह डेटाबेस हमारे उपयोग के मामले के बहुत करीब है क्योंकि यह पूरी तरह से PostgreSQL अनुरूप, क्षैतिज रूप से स्केलेबल और पूरी तरह से वितरित था। दुर्भाग्य से, स्केलेबिलिटी के साथ इसकी सीमा के कारण यह उतना अच्छा काम नहीं कर सका, हमारे सफलता मानदंड ने प्रति सेकंड 7k+ लेनदेन की मांग की लेकिन युगाबाइट केवल 5k तक स्केल करने में सक्षम था।

हमने BigQuery जैसे अन्य संभावित उम्मीदवारों पर भी गौर किया, लेकिन उनमें से किसी ने भी हमारी आवश्यकताओं को पूरा नहीं किया।

TiDB के साथ लैंडिंग

उपरोक्त PostgreSQL विकल्पों के बाद, हमने अपनी आवश्यकताओं में HTAP जोड़ने का निर्णय लिया, जो हमें TiDB तक ले गया। यह आउट-ऑफ़-द-बॉक्स स्केलेबिलिटी, स्थिरता, उपलब्धता, मल्टी-साइट परिनियोजन टोपोलॉजी और कई अन्य सुविधाओं का समर्थन करता है। एक वितरित डेटाबेस के रूप में, TiDB में कई घटक होते हैं जो एक दूसरे के साथ संचार करते हैं और एक संपूर्ण TiDB प्रणाली बनाते हैं।

• TiDB: यह स्टेटलेस SQL प्रोसेसिंग घटक है जो उपयोगकर्ता को क्लाइंट-फेसिंग एंडपॉइंट प्रदान करता है। यह डेटा प्राप्त करने के लिए पीडी से कनेक्ट करने के लिए सही TiKV नोड का पता लगाता है।
• TiKV: यह एक वितरित ट्रांजेक्शनल कुंजी-मूल्य डेटा स्टोर है जो डेटा को बाएं-बंद-दाएं-खुले रेंज में रखता है। डेटा को कई प्रतिकृतियों के साथ टुकड़ों में रखा जाता है। TiKV प्रतिकृति के लिए रफ़ प्रोटोकॉल का उपयोग करता है।
• पीडी: प्लेसमेंट ड्राइवर (पीडी) क्लस्टर के मेटाडेटा जैसे शार्ड प्रतिकृति स्थानों को रखता है, और यह TiKV नोड्स में शार्ड को शेड्यूल करने के लिए भी जिम्मेदार है। पीडी लीडर ऐसे कार्यों को संभालता है जबकि अन्य नोड उच्च उपलब्धता बनाए रखते हैं।
• TiFlash: कॉलमर स्टोरेज एक्सटेंशन जो वास्तविक समय में TiKV से डेटा को दोहराने के लिए मल्टी-रफ़्ट लर्नर प्रोटोकॉल का उपयोग करता है, TiKV पंक्ति-आधारित स्टोरेज इंजन के बीच लगातार डेटा सुनिश्चित करता है।

TiDB की निम्नलिखित विशेषताओं ने हमारी प्रमुख चुनौतियों का समाधान किया और हमारी परिचालन आवश्यकताओं को पूरा किया:

• आसान स्केलिंग

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

• ACID अनुरूप

  TiDB MySQL-अनुरूप है और बॉक्स से बाहर लेनदेन का समर्थन करता है। यह आशावादी और निराशावादी दोनों प्रकार के लेनदेन का समर्थन करता है। यह इसे अन्य डेटाबेस से विशिष्ट बनाता है।

• अत्यधिक उपलब्ध

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

• वास्तविक समय HTAP

  TiDB एक ही आर्किटेक्चर में पंक्ति भंडारण (TiKV) और स्तंभ भंडारण (TiFlash) दोनों को जोड़ती है, जिससे एक सुव्यवस्थित तकनीकी स्टैक बनता है जो परिचालन डेटा पर वास्तविक समय विश्लेषण का उत्पादन करना आसान बनाता है।

हमारा TiDB इन्फ्रास्ट्रक्चर

हमारा TiDB बुनियादी ढांचा अग्रणी क्लाउड सेवा प्रदाताओं के VM पर तैनात है। हम क्लस्टर और सभी प्रशासनिक कार्यों को प्रबंधित करने के लिए TiUP, TiDB के पैकेज मैनेजर का उपयोग करते हैं। हमारा क्लस्टर 3 उपलब्ध क्षेत्रों (एजेड) पर तैनात है।

हमारे क्लस्टर कॉन्फ़िगरेशन इस प्रकार हैं:

• पीडी: पीडी परत में मल्टी-एज़ में 3 नोड विभाजित हैं। पीडी लीडर ऐसे कार्यों को संभालता है जबकि अन्य नोड उच्च उपलब्धता बनाए रखते हैं।
• TiDB: TiDB परत में n2-highmem-8 परिवार के 9 नोड हैं। इन नोड्स को मेमोरी आवश्यकताओं के आधार पर चुना गया था, प्रत्येक TiDB नोड के लिए 64 जीबी रैम और 8 कोर सीपीयू आवंटित किए गए थे।
• TiKV: TiKV परत में n2-highmem-16 परिवार के 15 नोड हैं जिनमें 128 जीबी रैम और 16 vCORE सीपीयू हैं।

अपने TiDB क्लस्टर को कई AZ में तैनात करके और हमारी प्रोसेसिंग और मेमोरी आवश्यकताओं को पूरा करने के लिए सावधानीपूर्वक नोड प्रकारों का चयन करके, हमने एक मजबूत, अत्यधिक उपलब्ध बुनियादी ढांचा तैयार किया है जो हमारी उच्च डेटा थ्रूपुट आवश्यकताओं को संभालने में सक्षम है।

हमारे मामले के लिए TiDB ट्यूनिंग

इसे हमारे उपयोग के मामले में काम करने के लिए, हमने डेटाबेस को ट्यून करने के लिए पिंगकैप टीम के साथ मिलकर काम किया। हमारे द्वारा किए गए कुछ महत्वपूर्ण समायोजन यहां दिए गए हैं:

सूचकांक अनुकूलन

इंडेक्स शुरू करने से पहले निम्नलिखित पैरामीटर सेट करें।

 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 के अपने उपयोग को प्रभावी ढंग से सुव्यवस्थित करने में सक्षम थे, ताकि हम अपने वास्तविक समय डेटा मार्ट के लिए इष्टतम प्रदर्शन प्राप्त कर सकें।

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/

लेखक:

हरि किशन (वरिष्ठ इंजीनियरिंग प्रबंधक @ डेल्हीवरी)

आकाश दीप वर्मा (प्रौद्योगिकी निदेशक @ डेल्हीवरी)