मध्यम स्तर के डेटा आर्किटेक्चर को समझना

रिलेशनल, डॉक्यूमेंट और कॉलमनर एनालिटिकल डेटा प्रतिमानों में से चुनने के लिए वर्कलोड के एक्सेस पैटर्न और संचालन की बाध्यताओं का मूल्यांकन करें।

11 min

Activities: 0 of 2

डेटा लेआउट और एक्सेस पैटर्न का मेल

डेटा प्लेटफ़ॉर्म चुनना मूल रूप से अपने सॉफ़्टवेयर के रीड और राइट एक्सेस पैटर्न को इस बात से मिलाने का अभ्यास है कि इंजन डिस्क और मेमोरी में बाइट कैसे व्यवस्थित करता है।

जब कोई एप्लिकेशन किसी इकाई को पढ़ता है, तो वह विशेष डिस्क पेज को इंजन के बफ़र कैश में माँगता है। यदि आप ऐसा प्रतिमान चुनते हैं जिसका डिस्क लेआउट आपकी क्वेरी प्रोफ़ाइल से टकराता है, तो आपका हार्डवेयर अपना अधिकांश I/O बजट अप्रासंगिक फ़ील्ड लाने या बहु-पेज संदर्भों को पार करने में खर्च करता है:

  • पंक्ति-उन्मुख रिलेशनल (Row-oriented Relational, RDBMS): रिकॉर्ड को लगातार रखता है (पंक्ति 1: [ID, नाम, बैलेंस], पंक्ति 2: [ID, नाम, बैलेंस])। एकल पंक्ति के एटॉमिक बदलाव और इंडेक्स-संचालित पॉइंट लुकअप के लिए आदर्श।
  • डॉक्यूमेंट (एग्रीगेट-उन्मुख NoSQL, Document): आत्मनिर्भर पदानुक्रम (JSON/BSON ट्री) को एक लगातार रिकॉर्ड के रूप में रखता है। तब आदर्श जब कोई इकाई और उसकी सभी नेस्टेड चाइल्ड हमेशा साथ बनाई, पढ़ी और अपडेट की जाती हों।
  • कॉलम-उन्मुख एनालिटिकल (Column-oriented Analytical, OLAP): रिकॉर्डों में मान कॉलम के अनुसार रखता है (पहले सभी ID, फिर सभी नाम, फिर सभी बैलेंस)। केवल दो-तीन लक्षित फ़ील्ड पर लाखों पंक्तियाँ स्कैन करने के लिए आदर्श, बिना पूरे रिकॉर्ड मेमोरी में लोड किए।

प्रतिमान की यांत्रिकी और वर्कलोड के समझौते

इसके लिए सर्वोत्तम: सख़्त रिलेशनल इंटीग्रिटी, एक से अधिक इकाइयों के ट्रांज़ैक्शनल अपडेट, और अप्रत्याशित तदर्थ (ad-hoc) क्वेरी।

यांत्रिक समझौता: एकल पंक्ति के अपडेट केवल एक मेमोरी ब्लॉक छूते हैं, जिससे कम लेटेंसी के रैंडम राइट बने रहते हैं। लेकिन 100,000,000 पंक्तियों पर एक मीट्रिक (जैसे SUM(total_amount)) जोड़ने के लिए स्टोरेज इंजन को पूरी पंक्ति के टपल डिस्क से मेमोरी में खींचने पड़ते हैं, जिससे भारी I/O बोझ बनता है।

वास्तविक मामले: बेमेल एक्सेस पैटर्न

केस 1: बिलिंग सिस्टम में डॉक्यूमेंट का जाल

एक SaaS फिनटेक स्टार्टअप ने सब्सक्रिप्शन इनवॉइस डॉक्यूमेंट डेटाबेस में रखे। हर इनवॉइस में ग्राहक विवरण, ऐतिहासिक लाइन आइटम, भुगतान इवेंट और रिफ़ंड मेटाडेटा था। उपयोगकर्ता पोर्टल में पॉइंट रीड एक मिलीसेकंड से भी कम में हो जाती थीं। लेकिन जब लेखा टीम ने महीने के अंत का कर मिलान करना चाहा (4 मिलियन इनवॉइस पर देश के अनुसार VAT जोड़ना), तो क्वेरी टाइमआउट हो गई।

क्योंकि इंजन को केवल एक संख्यात्मक फ़ील्ड (tax_rate) पार्स करने के लिए पूरे JSON डॉक्यूमेंट RAM में लोड करने पड़े, इसलिए मेमोरी कुछ ही सेकंड में खत्म हो गई। संचालन की स्थिरता बहाल करने के लिए टीम को कर खाता-बही को द्वितीयक इंडेक्स वाली अपरिवर्तनीय रिलेशनल टेबल में निकालना पड़ा।

केस 2: ई-कॉमर्स एनालिटिक्स का गला घोंटना

एक ई-कॉमर्स मार्केटप्लेस अपने प्राइमरी OLTP PostgreSQL प्रोडक्शन रेप्लिका पर ही सीधे डैशबोर्ड रिपोर्टिंग चलाता था। जब भी मार्केटिंग लाखों चेकआउट इवेंट पर कोहोर्ट लाइफ़टाइम वैल्यू की गणना वाली रिपोर्ट चलाती, डिस्क सबसिस्टम में लाखों रैंडम पेज रीड कतार में लग जाते, साझा बफ़र पूल थ्रैश होता, और ग्राहक चेकआउट की लेटेंसी 35ms से बढ़कर 2.4s से अधिक हो जाती।

एनालिटिकल वर्कलोड को इवेंट-स्ट्रीम वाले कॉलमनर इंजन (ClickHouse/Snowflake) में अलग करने से ट्रांज़ैक्शनल कैश अलग हो गए और क्वेरी का समय 42 सेकंड से घटकर 120 मिलीसेकंड रह गया।

आम आर्किटेक्चर विफलताओं का निदान

वर्कलोड की विशेषताओं को इंजन प्रतिमानों से मिलाएँ

दिए गए एक्सेस पैटर्न और संचालन आवश्यकता को सबसे उपयुक्त डेटाबेस प्रतिमान से जोड़ें।

  • टेलीमेट्री मीट्रिक: 50,000 अपेंड प्रति सेकंड; दैनिक क्वेरी 500M पंक्तियों पर P99 पर्सेंटाइल की गणना करती हैं।
  • कोर बैंकिंग: दोहरी-प्रविष्टि खाता-बही, जिसे कई टेबल की सख़्त एटॉमिक ACID गारंटी और फ़ॉरेन की सत्यापन चाहिए।
  • कंटेंट प्रबंधन: बहुरूपी ब्लॉक वाले समृद्ध मीडिया लेख, जो सार्वजनिक प्रदर्शन के लिए URL स्लग से पूरे लाए जाते हैं।
  • यूज़र सेशन कैश: 15 मिनट में समाप्त होने वाले अस्थायी प्रमाणीकरण टोकन, जिनकी की-आधारित लुकअप एक मिलीसेकंड से भी कम में हो।

चयन का अनुमान-नियम: निर्णय त्रिकोण

अपना प्रतिमान चुनते समय तीन मुख्य आर्किटेक्चर अक्षों का मूल्यांकन करें:

  1. राइट टोपोलॉजी: क्या राइट अकेली अलग इकाइयों में एटॉमिक बदलाव हैं (डॉक्यूमेंट), कई इकाइयों के ट्रांज़ैक्शनल समझौते हैं (रिलेशनल), या उच्च थ्रूपुट के बैच अपेंड हैं (एनालिटिकल)?
  2. रीड ग्रैन्युलैरिटी: क्या रीड को पूरा ऑब्जेक्ट चाहिए (पंक्ति/डॉक्यूमेंट) या लाखों अलग फ़ील्ड पर एग्रीगेट प्रोजेक्शन (कॉलमनर)?
  3. स्कीमा स्थिरता: क्या स्कीमा सभी टेनेंट में एकसमान और बाध्य हैं, या ऑब्जेक्ट हर डोमेन इकाई के अनुसार गतिशील रूप से बदलते हैं?

What would you do?

आप एक लॉजिस्टिक्स SaaS के तकनीकी लीड हैं। प्रोडक्ट टीम 'ऑर्डर ट्रैकिंग और ऑडिट इंजन' बना रही है। आवश्यकताएँ: 1. 10,000 डिलीवरी ड्राइवर हर 10 सेकंड में GPS निर्देशांक भेजते हैं (86.4M रिकॉर्ड प्रतिदिन)। 2. डिस्पैचर कभी-कभी Driver_ID से एक ड्राइवर की अंतिम ज्ञात लोकेशन देखते हैं। 3. क्षेत्रीय निदेशक पूरी तिमाहियों (अरबों रिकॉर्ड) में औसत रूट टर्नअराउंड समय, निष्क्रिय देरी और ईंधन दक्षता मीट्रिक की गणना करने वाली तदर्थ क्वेरी चलाते हैं। आप इस फ़ीचर के लिए स्थायी स्टोरेज परत का आर्किटेक्चर कैसे बनाएँगे?
1 of 28

Checking your enrolment…