3.4 डेटा आर्किटेक्चर और स्टोरेज

अवलोकन और प्रेरणा

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

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

यह अध्याय प्रमुख स्टोरेज प्रतिमानों और हर एक का उपयोग कब करें, पॉलीग्लॉट पर्सिस्टेंस के अनुशासन, डेटा मॉडलिंग और अक्सर कम आँकी जाने वाली स्कीमा विकास और माइग्रेशन की समस्या, कैशिंग और CDN (कंटेंट डिलीवरी नेटवर्क) के साथ अमान्यकरण (invalidation) की कुख्यात रूप से कठिन समस्या, और जब आप उन्हें पैमाने पर ले जाते हैं तो लेन-देन, लॉकिंग, और समवर्तीता (concurrency) कैसे व्यवहार करती हैं, यह सब कवर करता है। मूल विचार सरल है: कोई सार्वभौमिक डेटाबेस नहीं है। ट्रेड-ऑफ़ हैं, और अच्छे डेटा आर्किटेक्चर का मतलब है इन्हें सचेत रूप से चुनना, एक बार में एक वर्कलोड के लिए।

मुख्य सिद्धांत

• डेटा को एक्सेस पैटर्न के अनुरूप मॉडल करें, न कि इसके उलट। स्टोरेज को इस आधार पर डिज़ाइन करें कि डेटा कैसे पढ़ा और लिखा जाएगा, न कि किसी अमूर्त “सही” मॉडल के आसपास।
• सभी पर राज करने वाला कोई एक डेटाबेस नहीं है। अलग-अलग वर्कलोड अलग-अलग इंजन चाहते हैं; पैमाने पर पॉलीग्लॉट पर्सिस्टेंस सामान्य बात है।
• सिस्टम ऑफ़ रिकॉर्ड के लिए सटीकता पहले। प्रामाणिक डेटा के लिए, टिकाऊपन और कॉन्सिस्टेंसी गैर-परक्राम्य हैं; प्रदर्शन को इनके इर्द-गिर्द अनुकूलित करें, इनके माध्यम से नहीं।
• स्कीमा बदलेगी, इसलिए इसकी योजना बनाएँ। माइग्रेशन एक प्रथम-श्रेणी, निरंतर इंजीनियरिंग गतिविधि हैं, न कि एक-बारगी काम।
• अपने डेटा को एक सेवा सीमा के पीछे स्वामित्व में रखें। हर बाउंडेड कॉन्टेक्स्ट (अपनी स्पष्ट सीमा वाला एक स्व-निहित डोमेन मॉडल) अपने डेटा का स्वामी होता है; डेटाबेस साझा करना टीमों को जोड़ देता है और स्वायत्तता को नष्ट कर देता है।
• कैशिंग एक प्रदर्शन-जीत के भेष में एक कॉन्सिस्टेंसी की समस्या है। हर कैश स्टेलनेस (बासीपन) और अमान्यकरण का जोखिम पेश करता है; इसे जानबूझकर संभालें।
• डीनॉर्मलाइज़ेशन एक पाप नहीं, एक व्यापार है। पठन प्रदर्शन के लिए डेटा को दोहराना वैध है यदि आप कॉन्सिस्टेंसी के परिणामों के स्वामी हैं।
• कॉन्सिस्टेंसी और पैमाना एक-दूसरे का व्यापार करते हैं। ट्रांज़ैक्शनल गारंटी जितनी मज़बूत होगी, उसे वितरित करना उतना ही कठिन होगा; केवल वही खरीदें जो वर्कलोड को चाहिए।

सिफारिशें

वर्कलोड से स्टोरेज प्रतिमान चुनें

हर वर्कलोड को उस मॉडल से मिलाएँ जो उसके अनुरूप हो। रिलेशनल डेटाबेस मज़बूत कॉन्सिस्टेंसी, जॉइन, और परिपक्व ट्रांज़ैक्शन देते हैं; ये सिस्टम ऑफ़ रिकॉर्ड और जटिल अखंडता नियमों वाली किसी भी चीज़ के लिए डिफ़ॉल्ट हैं। डॉक्यूमेंट स्टोर पदानुक्रमित, स्कीमा-लचीले डेटा के लिए उपयुक्त हैं जिन्हें एक इकाई के रूप में पढ़ा जाता है (एक पूरा ऑर्डर, एक पूरी प्रोफ़ाइल)। की-वैल्यू स्टोर सरल लुकअप (सत्र, फ़ीचर फ़्लैग, कैश) के लिए अत्यधिक गति देते हैं। ग्राफ़ डेटाबेस वहाँ उत्कृष्ट होते हैं जहाँ संबंध ही क्वेरी हैं (धोखाधड़ी के गिरोह, संगठन चार्ट, अधिकार, आपूर्ति शृंखलाएँ)। कॉलमनर स्टोर उन विश्लेषणात्मक क्वेरी को शक्ति देते हैं जो अरबों पंक्तियों में कुछ कॉलम स्कैन करती हैं (डेटा वेयरहाउस, रिपोर्टिंग)। टाइम-सीरीज़ डेटाबेस अपेंड-भारी, टाइमस्टैम्प्ड डेटा के लिए अनुकूलित होते हैं (मेट्रिक्स, टेलीमेट्री, इंटरनेट ऑफ़ थिंग्स (IoT) सेंसर, बाज़ार डेटा)। एक इंजन से हर काम कराने के प्रलोभन का विरोध करें। रिलेशनल डेटाबेस को क्यू के रूप में, या डॉक्यूमेंट स्टोर को लेजर के रूप में उपयोग करना तकलीफ़ को आमंत्रित करता है।

जानबूझकर पॉलीग्लॉट पर्सिस्टेंस अपनाएँ

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

डेटा मॉडल करें और स्कीमा विकास को निरंतर मानें

सिस्टम ऑफ़ रिकॉर्ड के लिए पहले से डेटा मॉडलिंग में निवेश करें। अखंडता की रक्षा के लिए नॉर्मलाइज़ करें, फिर सिद्ध पठन हॉट स्पॉट के लिए चुनिंदा रूप से डीनॉर्मलाइज़ करें। मॉडल जो भी हो, स्कीमा हमेशा विकसित होती रहती है, इसलिए माइग्रेशन को सुरक्षित और नियमित बनाएँ। सोर्स कंट्रोल में जाँचे गए और डिप्लॉयमेंट पाइपलाइन के माध्यम से लागू किए गए वर्ज़नयुक्त, स्वचालित, केवल-आगे-बढ़ने वाले माइग्रेशन स्क्रिप्ट का उपयोग करें। बड़ी टेबल पर ज़ीरो-डाउनटाइम परिवर्तनों के लिए, एक्सपैंड-कॉन्ट्रैक्ट (समानांतर परिवर्तन) पैटर्न का उपयोग करें: नया कॉलम या टेबल जोड़ें, बैकफ़िल और डुअल-राइट करें, रीडर को माइग्रेट करें, फिर पुराने आकार को हटाएँ। कभी भी एक भी तोड़ने वाला अल्टर न करें। डिप्लॉय में स्कीमा परिवर्तनों को पश्चगामी-अनुकूल (backward-compatible) बनाएँ ताकि पुराना और नया कोड एक साथ चल सकें। इवेंट-सोर्स्ड या मैसेज-आधारित सिस्टम में, अपने इवेंट और मैसेज स्कीमा को स्पष्ट रूप से वर्ज़न करें और पुराने इवेंट्स को अपकास्ट करने का समर्थन करें (पढ़ते समय उन्हें वर्तमान स्कीमा में बदलना)।

कैशिंग और अमान्यकरण को खुली आँखों से डिज़ाइन करें

कैशिंग और CDN सबसे प्रभावशाली प्रदर्शन टूल हैं। एक CDN उपयोगकर्ताओं के पास एज से स्थिर और कैश करने योग्य सामग्री परोसता है, और एप्लिकेशन कैश डेटाबेस को बार-बार होने वाले पठन से बचाते हैं। लेकिन कठिन हिस्सा अमान्यकरण है: यह जानना कि कैश किया गया डेटा कब बासी हो चुका है। हर मामले के लिए एक रणनीति चुनें। जहाँ हल्की बासीपन स्वीकार्य और सबसे सरल हो वहाँ समय-आधारित समाप्ति (TTL) का उपयोग करें। जहाँ ताज़गी मायने रखती हो वहाँ स्पष्ट अमान्यकरण या राइट-थ्रू का उपयोग करें। जहाँ एप्लिकेशन जनसंख्या का प्रबंधन करता हो वहाँ कैश-असाइड का उपयोग करें। TTL को सचेत रूप से सेट करें, कैश स्टैम्पीड (कई क्लाइंट एक साथ एक ही समाप्त हो चुकी प्रविष्टि को फिर से बनाते हैं) से लॉकिंग या रिक्वेस्ट कोलेसिंग के साथ बचाव करें, और ठंडे कैश पर थंडरिंग हर्ड को रोकें। कभी भी ऐसे डेटा को कैश न करें जिसकी बासीपन सटीकता या अनुपालन विफलता का कारण बन सकती हो (अधिकार, बैलेंस, सहमति) बिना किसी स्पष्ट, परीक्षित अमान्यकरण पथ के। कैश की, TTL, और अमान्यकरण को डिज़ाइन की गई कलाकृतियों के रूप में मानें, न कि आकस्मिक कॉन्फ़िगरेशन के रूप में।

पैमाने के लिए ट्रांज़ैक्शन, लॉकिंग, और समवर्तीता का प्रबंधन करें

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

Store type	Best for	Strengths	Weaknesses
रिलेशनल	सिस्टम ऑफ़ रिकॉर्ड, जटिल अखंडता	ACID, जॉइन, परिपक्व टूलिंग	लेखन को क्षैतिज रूप से स्केल करना कठिन
डॉक्यूमेंट	समग्र पठन, लचीली स्कीमा	तेज़ पूर्ण-ऑब्जेक्ट पठन/लेखन, लचीला	कमज़ोर क्रॉस-डॉक्यूमेंट जॉइन/ट्रांज़ैक्शन
की-वैल्यू	सत्र, कैश, सरल लुकअप	अत्यधिक गति और पैमाना	कुंजी से आगे कोई क्वेरी नहीं
ग्राफ़	संबंध-भारी क्वेरी	तेज़ ट्रैवर्सल, अभिव्यंजक	विशिष्ट संचालन कौशल, स्केलिंग सीमाएँ
कॉलमनर	एनालिटिक्स, रिपोर्टिंग	तेज़ समग्र स्कैन, संपीड़न	पंक्ति-स्तरीय ट्रांज़ैक्शनल लेखन के लिए खराब
टाइम-सीरीज़	मेट्रिक्स, टेलीमेट्री, IoT	कुशल अपेंड और समय क्वेरी	संकीर्ण उद्देश्य

प्रमुख ट्रेड-ऑफ़ कॉन्सिस्टेंसी और समृद्ध क्वेरींग बनाम क्षैतिज स्केलेबिलिटी और गति है। रिलेशनल सिस्टम सबसे मज़बूत गारंटी और सबसे लचीली क्वेरी देते हैं, लेकिन कई मशीनों में लेखन को स्केल करना इनके लिए सबसे कठिन है। NoSQL (गैर-रिलेशनल) परिवार पैमाना और गति पाने के लिए जॉइन, ट्रांज़ैक्शन, या स्कीमा में ढील देते हैं। कैशिंग लेटेंसी के लिए ताज़गी का व्यापार करती है। शार्डिंग राइट थ्रूपुट के लिए क्रॉस-पार्टीशन ट्रांज़ैक्शन का व्यापार करती है। इनमें से कोई भी सार्वभौमिक रूप से सही नहीं है। कला हर वर्कलोड को उस वक्र के उस बिंदु पर रखने की है जिसकी उसकी सटीकता और प्रदर्शन की ज़रूरतें वास्तव में माँग करती हैं।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. हर महत्वपूर्ण डेटासेट के लिए, क्या हर कोई एक सिस्टम ऑफ़ रिकॉर्ड का नाम बता सकता है, या क्या कैश और प्रोजेक्शन को चुपचाप सत्य के रूप में माना जाता है? डेटा कोड से अधिक जीवित रहता है, और सबसे नुकसानदायक डेटा घटनाएँ ड्रिफ्ट से आती हैं: एक कैश, सर्च इंडेक्स, या रीड प्रोजेक्शन को प्रामाणिक समझ लिया जाता है और चुपचाप वास्तविक स्रोत से अलग हो जाता है। एक बड़ी टीम में यह तब होता है जब स्वामित्व अस्पष्ट होता है और कई सेवाएँ ओवरलैपिंग प्रतियाँ लिखती हैं, जिससे किसी घटना के दौरान कोई नहीं कह सकता कि कौन-सा मान सही है। अपने महत्वपूर्ण डेटा का एक मानचित्र लाएँ और हर आइटम के लिए, वह एकल स्टोर जो प्रामाणिक है, साथ ही वे व्युत्पन्न प्रतियाँ जिन्हें उससे फिर से बनाया जा सकना चाहिए। वित्त और सरकार में, यह साबित करने में सक्षम होना कि कौन-सा रिकॉर्ड कानूनी स्रोत है और बाकी का पुनर्निर्माण करना अक्सर एक नियामक आवश्यकता है, सुविधा नहीं। कोई भी चीज़ जिसे आप सिस्टम ऑफ़ रिकॉर्ड से फिर से नहीं बना सकते, वह स्वयं एक सिस्टम ऑफ़ रिकॉर्ड है, चाहे आपका इरादा ऐसा हो या न हो।

2. आपके पास मौजूद हर डेटाबेस इंजन को चलाने, सुरक्षित करने, और बैकअप लेने की वास्तविक लागत क्या है, और क्या हर एक अभी भी अपनी जगह अर्जित कर रहा है? पॉलीग्लॉट पर्सिस्टेंस तब सही है जब वर्कलोड वास्तव में भिन्न हों, लेकिन हर इंजन एक स्थायी परिचालन प्रतिबद्धता है: पैचिंग, बैकअप, निगरानी, सुरक्षा समीक्षा, और ऐसा स्टाफ़ जो रात के 3 बजे इसे जानता हो। एक बड़ा संगठन ऐसे स्टोरों के चिड़ियाघर में भटक सकता है जो हर एक सुविधा के लिए अपनाए गए हों, और मामूली वाला हमेशा के लिए लागत जोड़ता है जबकि वह वर्कलोड परोसता है जिसे आप पहले से चलाया जा रहा स्टोर संभाल सकता था। हर इंजन, उसे उचित ठहराने वाला वर्कलोड, और उसके लिए कौन ऑन-कॉल है, इसकी सूची बनाएँ, फिर किसी ऐसी ज़रूरत के लिए अपनाए गए किसी को भी चिह्नित करें जिसे अब एक प्राथमिक स्टोर पूरा कर सकता है। नए डेटाबेस को अपनाने को एक ऊँची कसौटी पर खरा उतरना चाहिए, क्योंकि बाद में किसी को हटाने का मतलब एक और माइग्रेशन है। जो स्टोर आप रखते हैं उनमें परिचालन टूलिंग को मानकीकृत करना ही लागत को नीचे रखते हुए यह सुनिश्चित करने का तरीका है कि एक इंजन को हर काम न करना पड़े।

3. कहाँ कोई उपयोगकर्ता अपने ही लेखन के ठीक बाद किसी रेप्लिका से बासी मान पढ़ सकता है, और क्या यह उस वादे को तोड़ता है जो आपने उससे किया था? रीड रेप्लिका पठन को स्केल करते हैं लेकिन प्राथमिक से पीछे रहते हैं, इसलिए जो उपयोगकर्ता किसी प्रोफ़ाइल को अपडेट करता है और तुरंत उसे फिर से लोड करता है वह पुराना मान देख सकता है, जो एक बग की तरह पढ़ता है या, बैलेंस या सहमति फ़्लैग के लिए, एक अनुपालन विफलता की तरह। हर फ़्लो के लिए तय करें कि क्या रीड-योर-राइट्स मायने रखता है, और उन पठनों को प्राथमिक पर रूट करें या सेशन-कॉन्सिस्टेंसी तंत्र का उपयोग करें। रेप्लिका से परोसे जाने वाले फ़्लो की सूची लाएँ और चिह्नित करें कि किन पर उपयोगकर्ता लिखने के तुरंत बाद कार्रवाई करता है। बैलेंस, अधिकार, और सहमति के लिए, बासी पठन को सटीकता विफलता मानें, न कि केवल सौंदर्यबोधक। मुद्दा यह है कि हर वर्कलोड को वास्तव में जिस कॉन्सिस्टेंसी की ज़रूरत है वही खरीदें, और जो बासीपन आप स्वीकार करते हैं उसे आकस्मिक के बजाय स्पष्ट बनाएँ।

4. क्या आप आज अपनी सबसे बड़ी, सबसे व्यस्त टेबल की स्कीमा को बिना डाउनटाइम के बदल सकते हैं, और किसने वास्तव में एक्सपैंड-कॉन्ट्रैक्ट चरणों का पूर्वाभ्यास किया है? स्कीमा हमेशा विकसित होती रहती है, और जो विफलता सबसे अधिक चोट पहुँचाती है वह एक बिग-बैंग अल्टर है जो एक विशाल टेबल को लॉक करता है, सेवा को स्थिर कर देता है, और साफ़-सुथरे ढंग से वापस रोल नहीं किया जा सकता। एक बड़ी टीम में जोखिम कई गुना बढ़ जाता है क्योंकि कई सेवाएँ एक ही आकार को पढ़ती हैं, इसलिए एक तोड़ने वाले परिवर्तन के लिए पुराने और नए कोड को एक चरणबद्ध डिप्लॉय में साथ-साथ चलाने की ज़रूरत होती है। प्रतिस्पर्धी खिंचाव गति है: एक ही अल्टर लिखने में तेज़ है, जबकि एक्सपैंड-कॉन्ट्रैक्ट (नया आकार जोड़ें, बैकफ़िल करें, डुअल-राइट करें, रीडर को माइग्रेट करें, पुराना आकार छोड़ें) अधिक चरण और अधिक धैर्य माँगता है। अपनी सबसे बड़ी टेबल लाएँ, एक ईमानदार अनुमान कि एक सरल अल्टर इसे कितनी देर लॉक करेगा, और एक विशिष्ट माइग्रेशन जिसे किसी ने सिद्धांत में नहीं बल्कि एक पूर्वाभ्यास में आरंभ से अंत तक चलाया हो। एंटरप्राइज़ और सरकारी सिस्टम में जो निरंतर चलते हैं और वैधानिक उपलब्धता लक्ष्य वहन करते हैं, माइग्रेशन के लिए डाउनटाइम एक उल्लंघन है, इसलिए एक्सपैंड-कॉन्ट्रैक्ट अनुशासन ही स्कीमा को बदलने की अनुमति पाने की कीमत है।

5. कौन-से कैश किए गए या प्रतिकृत मान, यदि बासी परोसे जाएँ, तो सौंदर्यबोधक विफलता के बजाय अनुपालन या सुरक्षा विफलता का कारण बनेंगे, और क्या उन सभी के अमान्यकरण पथों का परीक्षण किया गया है? कैशिंग एक प्रदर्शन की पोशाक पहने हुए सटीकता की समस्या है: खतरा धीमापन नहीं बल्कि किसी अधिकार, बैलेंस, सहमति फ़्लैग, या एक्सेस निर्णय को बदलने के बाद भी परोसना है। एक बड़े संगठन के लिए यह खतरा फैला हुआ है, क्योंकि कैश और एज लेयर टीमों में जमा होते जाते हैं और कोई एक व्यक्ति यह सूची नहीं बना सकता कि कहाँ क्या कैश किया गया है या कब वह साफ़ होता है। तनाव वास्तविक है: आक्रामक कैशिंग और लंबे TTL लेटेंसी खरीदते हैं और डेटाबेस की रक्षा करते हैं, जबकि सख्त ताज़गी की कीमत दोनों में चुकानी पड़ती है। कैश और CDN-परोसित डेटा की एक सूची लाएँ, जिसमें चिह्नित हो कि किन प्रविष्टियों का अनुपालन या सुरक्षा परिणाम है, साथ ही इस बात का प्रमाण कि उनमें से हर एक के अमान्यकरण पथ को केवल कॉन्फ़िगर करने के बजाय व्यवहार में परखा गया है। विनियमित और सार्वजनिक सेटिंग्स में, एक बासी सहमति या पात्रता मान एक ऑडिट योग्य विफलता है, इसलिए उन आइटम को एक स्पष्ट, परीक्षित अमान्यकरण पथ चाहिए या उन्हें बिल्कुल कैश नहीं किया जाना चाहिए।

6. हर प्रामाणिक स्टोर के लिए आपकी प्रतिधारण, आर्काइवल, और डेटा-निवास रणनीति क्या है, और क्या आप इसे किसी ऑडिटर को साबित कर सकते हैं? डेटा कोड से अधिक जीवित रहता है और अक्सर उस टीम से भी अधिक जीवित रहता है जिसने इसे लिखा था, इसलिए असीमित वृद्धि और अस्पष्ट निवास नियम चुपचाप वह समस्या बन जाते हैं जिसका कोई स्वामी नहीं होता जब तक कि कोई टेबल अप्रबंधनीय न हो जाए या कोई रिकॉर्ड गलत क्षेत्राधिकार में न बैठ जाए। एक बड़ा संगठन कई स्टोर और क्षेत्रों में फैला होता है, और प्रतिस्पर्धी विचार लागत (हॉट स्टोरेज महँगा है, इसलिए आर्काइव और टियर करें), प्रदर्शन (फूली हुई टेबल हर चीज़ को धीमा कर देती हैं), और कानूनी कर्तव्य (वैधानिक प्रतिधारण न्यूनतम और निवास अधिकतम सीमाएँ जो टकरा सकती हैं) हैं। हर प्रामाणिक डेटासेट के लिए, प्रतिधारण अवधि, डेटा भौतिक रूप से कहाँ रहता है, आर्काइवल और डिलीशन तंत्र, और इसके लिए जवाबदेह व्यक्ति का नाम लाएँ। एंटरप्राइज़ और विशेष रूप से सरकारी सिस्टम के लिए, प्रतिधारण और निवास आमतौर पर ऑडिट और संप्रभुता आवश्यकताओं वाले कानूनी अधिदेश होते हैं, इसलिए यह साबित करने में सक्षम होना कि हर रिकॉर्ड कहाँ रहता है, कितने समय तक रखा जाता है, और कब नष्ट किया जाता है, एक विशेष सुविधा नहीं बल्कि संचालन का लाइसेंस है।

क्षेत्रीय दृष्टिकोण

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

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

एंटरप्राइज़। मुख्य चुनौती कई टीमों में पॉलीग्लॉट पर्सिस्टेंस की है: एक रिलेशनल सिस्टम ऑफ़ रिकॉर्ड के साथ सर्च, कैश, वेयरहाउस, और शायद ग्राफ़ या टाइम-सीरीज़ इंजन, हर एक साझा किए जाने के बजाय एक सेवा के स्वामित्व में। जो स्टोर आप रखते हैं उनमें परिचालन टूलिंग, बैकअप, और निगरानी को मानकीकृत करें, नए इंजन को अपनाने को एक ऊँची कसौटी पर रखें, और एक्सपैंड-कॉन्ट्रैक्ट माइग्रेशन और स्पष्ट कैश अमान्यकरण को डिफ़ॉल्ट बनाएँ। संपत्ति को स्पष्ट डेटा स्वामित्व के साथ एक पोर्टफ़ोलियो के रूप में प्रबंधित करें, ताकि कोई इंजन उस वर्कलोड से आगे न बचे जिसने उसे उचित ठहराया था और कोई टीम साझा डेटाबेस के माध्यम से जुड़ी न रहे।

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

उदाहरण

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

एंटरप्राइज़। एक रिटेल बैंक अपने प्रामाणिक लेजर को एक मज़बूती से सुसंगत रिलेशनल डेटाबेस में रखता है: हर पोस्टिंग एक उचित ACID ट्रांज़ैक्शन है, जो लेखन पैमाने के लिए खाता रेंज द्वारा शार्ड की गई है। इसके चारों ओर एक पॉलीग्लॉट संपत्ति बैठी है: ग्राहक लुकअप के लिए एक सर्च इंडेक्स, मोबाइल ऐप पर खाता सारांशों के लिए एक Redis कैश (राइट-थ्रू, छोटा TTL), नियामक और विश्लेषणात्मक रिपोर्टिंग के लिए एक कॉलमनर वेयरहाउस, और लेन-देन-नेटवर्क धोखाधड़ी पहचान के लिए एक ग्राफ़ डेटाबेस। लेजर में स्कीमा परिवर्तन डुअल-राइट के साथ एक्सपैंड-कॉन्ट्रैक्ट का उपयोग करते हैं ताकि 24/7 सिस्टम माइग्रेशन के लिए कभी डाउनटाइम न ले।

सरकार। एक राष्ट्रीय वाहन रजिस्ट्री वैधानिक प्रतिधारण और पूर्ण ऑडिट इतिहास के साथ एक रिलेशनल सिस्टम ऑफ़ रिकॉर्ड में प्रामाणिक रिकॉर्ड संग्रहित करती है। सार्वजनिक-सामना वाले “वाहन जाँचें” लुकअप एक रीड रेप्लिका और एक छोटे TTL वाले एज कैश से परोसे जाते हैं, क्योंकि थोड़ा बासी सार्वजनिक डेटा स्वीकार्य है और पठन मात्रा लेखन को बौना कर देती है। डेटा निवास कानून के अनुसार सभी रिकॉर्ड को देश के भीतर रहना चाहिए, इसलिए हर स्टोर को संप्रभु क्षेत्रों में प्रोविज़न किया जाता है और CDN को केवल गैर-व्यक्तिगत डेटा कैश करने के लिए कॉन्फ़िगर किया जाता है। परिवहन नीति द्वारा अनिवार्य नए फ़ील्ड जोड़ने वाले माइग्रेशन पाइपलाइन के माध्यम से पश्चगामी-अनुकूल रूप से लागू किए जाते हैं ताकि विधायी समय-सीमाओं के दौरान सेवा उपलब्ध रहे।

बिज़नेस केस: प्रेरणाएँ, ROI, और TCO

डेटा आर्किटेक्चर निर्णयों की सॉफ़्टवेयर में सबसे लंबी और सबसे बड़ी लागत पूँछें होती हैं, क्योंकि एक बार जब सिस्टम और इंटीग्रेशन इन पर निर्भर हो जाते हैं तो डेटा और इसकी स्कीमा को बदलना सबसे कठिन चीज़ें होती हैं। अच्छी प्रथा (जानबूझकर स्टोर चयन, अनुशासित माइग्रेशन, डिज़ाइन की गई कैशिंग, और उपयुक्त शार्डिंग) को अपनाने की लागत अधिकांशतः वरिष्ठ इंजीनियरिंग समय और कुछ अतिरिक्त परिचालन टूलिंग है। इसे न अपनाने की लागत एक अकेले अतिभारित डेटाबेस के रूप में सामने आती है जो पूरे व्यवसाय को धीमा कर देता है, जब गलत स्टोर बहुत देर से खोजा जाता है तो आपातकालीन री-प्लेटफ़ॉर्मिंग, एक बिगड़े हुए माइग्रेशन से लंबे आउटेज, और, सबसे नुकसानदायक, एक गलत-अमान्यकृत कैश या खोए हुए ट्रांज़ैक्शन से डेटा भ्रष्टाचार या अनुपालन उल्लंघन।

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

• लेवल 1: प्रारंभ (Initiate)। हर उद्देश्य के लिए एक डेटाबेस उपयोग किया जाता है। स्कीमा परिवर्तन मैनुअल और तदर्थ हैं, बिना किसी माइग्रेशन अनुशासन के। कैशिंग आकस्मिक है और अमान्यकरण बाद का विचार है। प्रदर्शन समस्याओं को एक बड़ी मशीन खरीदकर प्रतिक्रियात्मक रूप से हल किया जाता है, और कोई भी किसी दिए गए डेटासेट के सिस्टम ऑफ़ रिकॉर्ड का विश्वसनीय रूप से नाम नहीं बता सकता।
• लेवल 2: विकास (Develop)। कुछ स्टोरेज विकल्प जानबूझकर किए जाते हैं और एक कैश या वेयरहाउस सामने आया है, लेकिन प्रथा टीम के अनुसार भिन्न होती है। माइग्रेशन वर्ज़नयुक्त हैं फिर भी कभी-कभी डाउनटाइम की ज़रूरत होती है, और एक्सपैंड-कॉन्ट्रैक्ट का उपयोग वही करता है जिसे यह पता हो। कई सेवाएँ अभी भी एक डेटाबेस साझा करती हैं, और कैशिंग रणनीतियाँ एक टीम से दूसरी में भिन्न होती हैं।
• लेवल 3: मानकीकरण (Standardize)। पॉलीग्लॉट पर्सिस्टेंस को वर्कलोड से मिलाया जाता है, हर स्टोर एक सेवा के स्वामित्व में है और कभी साझा नहीं किया जाता। स्वचालित, पश्चगामी-अनुकूल, ज़ीरो-डाउनटाइम एक्सपैंड-कॉन्ट्रैक्ट माइग्रेशन पूरे संगठन में दस्तावेज़ीकृत, लागू मानक हैं। कैशिंग रणनीतियाँ, TTL, और अमान्यकरण पथ स्पष्ट डिज़ाइन कलाकृतियाँ हैं, और हर डेटासेट के लिए एकल सिस्टम ऑफ़ रिकॉर्ड दस्तावेज़ीकृत है, जिससे व्युत्पन्न प्रतियाँ फिर से बनाई जा सकती हैं।
• लेवल 4: प्रबंधन (Manage)। डेटा संपत्ति को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है। आप माइग्रेशन अवधि और रोलबैक दर, रीड-योर-राइट्स आवश्यकताओं के विरुद्ध रेप्लिकेशन लैग, कैश हिट अनुपात और बासीपन घटनाएँ, प्रति-स्टोर परिचालन लागत, और लक्षित पर्सेंटाइल पर क्वेरी लेटेंसी को ट्रैक करते हैं, फिर संख्याओं पर कार्रवाई करते हैं। प्रतिधारण और निवास को वैधानिक आवश्यकताओं के विरुद्ध ऑडिट किया जाता है, व्युत्पन्न डेटा की सटीकता को निरंतर सत्यापित किया जाता है, और हर इंजन को उस वर्कलोड के विरुद्ध अपनी लागत उचित ठहरानी होती है जिसकी वह सेवा करता है।
• लेवल 5: ऑर्केस्ट्रेशन (Orchestrate)। डेटा आर्किटेक्चर में निरंतर सुधार होता है और यह पूरे संगठन में क्षमता, लागत, और जोखिम योजना के साथ एकीकृत है। एक्सेस पैटर्न और लागत बदलने पर शार्डिंग, कैशिंग, और कॉन्सिस्टेंसी विकल्पों को प्रति वर्कलोड पुनःसंतुलित किया जाता है, और जो स्टोर अब अपनी जगह अर्जित नहीं करते उन्हें नियोजित माइग्रेशन के माध्यम से रिटायर किया जाता है। स्कीमा विकास, आर्काइवल, और निवास पूरी तरह स्वचालित और अनुकूलनीय हैं, ताकि संपत्ति आपातकालीन री-प्लेटफ़ॉर्मिंग के बिना नए अधिदेशों और लोड के अनुसार खुद को फिर से आकार दे सके।

चर्चा के लिए विचार

1. आपके वर्तमान स्टोरों में से कौन-सा ऐसा काम कर रहा है जिसके लिए इसे डिज़ाइन नहीं किया गया था, और सही इंजन क्या होगा?
2. क्या आप आज अपनी सबसे बड़ी टेबल पर ज़ीरो डाउनटाइम के साथ एक स्कीमा परिवर्तन कर सकते हैं? यदि नहीं, तो क्यों नहीं?
3. आपका सिस्टम कहाँ ऐसा डेटा कैश करता है जिसकी बासीपन अनुपालन या सटीकता विफलता का कारण बन सकती है?
4. कौन-सी सेवाएँ एक डेटाबेस साझा करती हैं, और हर एक को अपना खुद का देने में क्या लगेगा?
5. कहाँ एक एकल लिखने योग्य डेटाबेस आपकी स्केलिंग सीमा है, और क्या रीड-रेप्लिकेशन या शार्डिंग सही अगला कदम है?
6. आपकी प्रतिधारण और आर्काइवल रणनीति क्या है, और इसके लिए कौन जवाबदेह है?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Martin Kleppmann, Designing Data-Intensive Applications
• Pramod Sadalage and Martin Fowler, NoSQL Distilled
• Pramod Sadalage and Scott Ambler, Refactoring Databases: Evolutionary Database Design
• C. J. Date, An Introduction to Database Systems
• Joe Celko, SQL for Smarties
• Vlad Mihalcea, High-Performance Java Persistence (ट्रांज़ैक्शन, आइसोलेशन, समवर्तीता)
• Eric Evans, Domain-Driven Design (बाउंडेड कॉन्टेक्स्ट और डेटा स्वामित्व)
• Werner Vogels, “Eventually Consistent”