जानिए क्यों डॉक्यूमेंट डेटाबेस उन स्थितियों में बेहतर हैं जहाँ डेटा मॉडल अक्सर बदलते हैं: लचीले स्कीमा, तेज़ इटरेशन, नैचुरल JSON स्टोरेज और किन ट्रेडऑफ़्स की योजना बनानी चाहिए।
एक डॉक्यूमेंट डेटाबेस डेटा को सेल्फ-कॉन्टेंड “डॉक्यूमेंट” के रूप में स्टोर करता है, आम तौर पर JSON-जैसे फॉर्मेट में। एक ही बिजनेस ऑब्जेक्ट को कई टेबलों में फैलाने की बजाय, एक डॉक्यूमेंट उसके बारे में सबकुछ रख सकता है—फील्ड्स, सबफ़ील्ड्स और ऐरे—ठीक वैसे जैसे कई ऐप्स कोड में डेटा को पहले से ही दर्शाते हैं।
users कलेक्शन या orders कलेक्शन)।एक ही कलेक्शन के डॉक्यूमेंट्स एक जैसे दिखने जरूरी नहीं हैं। एक user डॉक्यूमेंट में 12 फील्ड हो सकते हैं, दूसरे में 18—और दोनों साथ-साथ रह सकते हैं।
एक यूज़र प्रोफ़ाइल की कल्पना करें। आप name और email से शुरुआत करते हैं। अगले महीने मार्केटिंग चाहती है preferred_language। फिर कस्टमर सक्सेस timezone और subscription_status मांगता है। बाद में आप social_links (एक ऐरे) और privacy_settings (एक नेस्टेड ऑब्जेक्ट) जोड़ते हैं।
एक डॉक्यूमेंट डेटाबेस में, आप आम तौर पर नए फील्ड तुरंत लिखना शुरू कर सकते हैं। पुराने डॉक्यूमेंट वैसा ही रह सकते हैं जब तक आप उन्हें बैकफिल करने का निर्णय न लें (या न लें)।
यह लचीलापन प्रोडक्ट वर्क को तेज कर सकता है, लेकिन ज़िम्मेदारी आपकी एप्लिकेशन और टीम पर शिफ्ट हो जाती है: आपको स्पष्ट कन्वेंशन्स, वैकल्पिक वैलिडेशन नियम और विचारशील क्वेरी डिज़ाइन की ज़रूरत होगी ताकि गंदा, असंगत डेटा न बने।
आगे, हम देखेंगे कि कुछ मॉडल इतनी बार क्यों बदलते हैं, लचीले स्कीमा कैसे घर्षण कम करते हैं, डॉक्यूमेंट्स असल ऐप क्वेरीज से कैसे मिलते हैं, और रिलेशनल पर डॉक्यूमेंट स्टोरेज चुनने से पहले किन ट्रेडऑफ़्स पर विचार करना चाहिए—या हाइब्रिड अप्रोच कब उपयुक्त है।
डेटा मॉडल दुर्लभ ही स्थिर रहते हैं क्योंकि प्रोडक्ट आम तौर पर स्थिर नहीं रहता। जो "सिर्फ यूज़र प्रोफ़ाइल स्टोर करो" के रूप में शुरू हुआ, वह जल्दी ही प्रेफरेंसेस, नोटिफिकेशन्स, बिलिंग मेटाडेटा, डिवाइस जानकारी, कंसेंट फ़्लैग्स और दर्जनों अन्य डिटेल्स बन जाता है जो पहली वर्शन में मौजूद नहीं थे।
अधिकांश मॉडल चर्न केवल सीखने का परिणाम है। टीमें फ़ील्ड्स जोड़ती हैं जब वे:
ये परिवर्तन अक्सर क्रमिक और बार-बार होते हैं—छोटी जोड़ियाँ जो औपचारिक “बड़े माईग्रेशन” के रूप में शेड्यूल करना मुश्किल होती हैं।
रीयल डेटाबेसेज़ में इतिहास होता है। पुराने रिकॉर्ड वही शेप रखते हैं जिस रूप में उन्हें लिखा गया था, जबकि नए रिकॉर्ड लेटेस्ट शेप अपनाते हैं। आपके पास ऐसे ग्राहक हो सकते हैं जिन्हें marketing_opt_in आने से पहले बनाया गया था, ऑर्डर्स जो delivery_instructions सपोर्ट होने से पहले बने थे, या इवेंट्स जिनमें नया source फ़ील्ड परिभाषित होने से पहले लॉग किए गए थे।
तो आप एक “मॉडल” नहीं बदल रहे होते—आप कई वर्ज़न्स को एक साथ सपोर्ट कर रहे होते हैं, कभी-कभी महीनों तक।
जब कई टीमें समानांतर में शिप करती हैं, डेटा मॉडल एक साझा सरफेस एरिया बन जाता है। एक पेमेंट्स टीम फ्रॉड सिग्नल जोड़ सकती है जबकि ग्रोथ टीम एट्रिब्यूशन डेटा जोड़ती है। माइक्रोसर्विसेज में, हर सर्विस “कस्टमर” कॉन्सेप्ट को अलग जरूरतों के साथ स्टोर कर सकती है, और वे जरूरतें स्वतंत्र रूप से विकसित होती हैं।
बिना समन्वय के, "एकल परफेक्ट स्कीमा" एक बॉटलनेक बन जाता है।
बाहरी सिस्टम अक्सर ऐसे पेलोड भेजते हैं जो आंशिक रूप से ज्ञात, नेस्टेड या असंगत होते हैं: वेबहुक इवेंट्स, पार्टनर मेटाडेटा, फॉर्म सबमिशन्स, डिवाइस टेलीमेट्री। भले ही आप महत्वपूर्ण हिस्सों को नॉर्मलाइज़ कर लें, अक्सर आप मूल संरचना को ऑडिट, डिबग या भविष्य उपयोग के लिए रखना चाहते हैं।
ये सभी ताकतें ऐसी स्टोरेज की ओर धकेलती हैं जो बदलाव को gracefully सहन कर सके—खासकर जब शिपिंग स्पीड मायने रखती हो।
जब एक प्रोडक्ट अभी आकार खोज रहा होता है, डेटा मॉडल शायद ही "किया हुआ" होता है। नए फ़ील्ड्स आते हैं, पुराने ऑप्शनल बन जाते हैं, और अलग ग्राहक थोड़ी अलग जानकारी चाहते हैं। डॉक्यूमेंट डेटाबेस ऐसे पलों में लोकप्रिय होते हैं क्योंकि वे आपको बिना हर बदलाव को एक डेटाबेस माईग्रेशन प्रोजेक्ट में बदलने की अनुमति देते हैं।
JSON डॉक्यूमेंट्स के साथ, नया प्रॉपर्टी लिखना नए रिकॉर्ड्स पर उतना ही सरल हो सकता है। मौजूदा डॉक्यूमेंट तब तक अप्रभावित रहते हैं जब तक आप बैकफिल करने का निर्णय न लें। इसका मतलब है कि एक छोटा एक्सपेरिमेंट—जैसे एक नया प्रेफरेंस सेटिंग इकट्ठा करना—स्कीमा बदलने, डिप्लॉय विंडो और बैकफिल जॉब समन्वय के बिना ही शुरू किया जा सकता है।
कभी-कभी आपके पास वास्तव में वैरिएंट्स होते हैं: एक “फ्री” अकाउंट में कम सेटिंग्स होती हैं बनिस्बत “एंटरप्राइज़” अकाउंट के, या एक प्रोडक्ट टाइप को अतिरिक्त एट्रिब्यूट्स चाहिए। डॉक्यूमेंट डेटाबेस में यह स्वीकार्य हो सकता है कि एक ही कलेक्शन के डॉक्यूमेंट्स के शेप अलग-अलग हों, बशर्ते आपकी एप्लिकेशन उन्हें पढ़ना जानती हो।
बजाय कि सब कुछ एक कठोर संरचना में जबरन फिट करें, आप रख सकते हैं:
id, userId, createdAt)लचीला स्कीमा “कोई नियम नहीं” नहीं कहता। एक सामान्य पैटर्न यह है कि गायब फ़ील्ड्स को “डिफ़ॉल्ट उपयोग करें” के रूप में ट्रीट किया जाए। आपकी एप्लिकेशन पढ़ते समय (या लिखते समय) समझदारी से डिफ़ॉल्ट्स लगा सकती है, ताकि पुराने डॉक्यूमेंट भी सही तरह से व्यवहार करें।
फीचर फ्लैग्स अक्सर अस्थायी फ़ील्ड्स और आंशिक रोलआउट्स लाते हैं। लचीले स्कीमा छोटे कोहोर्ट पर बदलाव भेजना, केवल फ़्लैग किए गए यूज़र्स के लिए अतिरिक्त स्टेट स्टोर करना, और जल्दी इटरेट करना आसान बनाते हैं—बिना स्कीमा वर्क पर ब्लॉक हुए बगैर।
कई प्रोडक्ट टीमें स्वाभाविक रूप से “एक चीज जो यूज़र स्क्रीन पर देखता है” की भाषा में सोचती हैं। एक प्रोफ़ाइल पेज, एक ऑर्डर डिटेल व्यू, एक प्रोजेक्ट डैशबोर्ड—प्रत्येक आम तौर पर एक सिंगल ऐप ऑब्जेक्ट से मेल खाता है। डॉक्यूमेंट डेटाबेस उस मानसिक मॉडल को सपोर्ट करते हैं क्योंकि वे उस ऑब्जेक्ट को एक JSON डॉक्यूमेंट के रूप में स्टोर करने देते हैं, जिससे एप्लिकेशन को स्टोरेज के साथ कम ट्रांसलेशन करना पड़ता है।
रिलेशनल टेबल्स के साथ, वही फीचर अक्सर कई तालिकाओं, फॉरेन-कीज़ और जॉइन लॉजिक में बँट जाता है। वह संरचना शक्तिशाली है, पर जब ऐप पहले से ही डेटा को नेस्टेड ऑब्जेक्ट के रूप में रखता है तो यह एक अतिरिक्त समारोह जैसा लग सकता है।
डॉक्यूमेंट डेटाबेस में, आप अक्सर ऑब्जेक्ट को लगभग वैसे ही परसिस्ट कर सकते हैं:
user डॉक्यूमेंट जो आपके User क्लास/टाइप से मेल खाता हैproject डॉक्यूमेंट जो आपके Project स्टेट मॉडल से मेल खाता हैकम ट्रांसलेशन का मतलब आम तौर पर कम मैपिंग बग्स और फील्ड्स बदलने पर तेज़ इटरेशन होता है।
असली ऐप डेटा शायद ही कभी फ्लैट होता है। पते, प्रेफरेंसेस, नोटिफिकेशन सेटिंग्स, सेव्ड फ़िल्टर्स, UI फ्लैग्स—ये सभी नेस्टेड होना स्वाभाविक है।
पैरेंट डॉक्यूमेंट के अंदर नेस्टेड ऑब्जेक्ट्स स्टोर करने से संबंधित मान पास-पास रहते हैं, जो "एक रिकॉर्ड = एक स्क्रीन" क्वेरीज के लिए मदद करता है: एक डॉक्यूमेंट फ़ेच करें, एक व्यू रेंडर करें। इससे जॉइन की ज़रूरत और उससे आने वाले परफ़ॉर्मेंस सरप्राइज़ कम हो सकते हैं।
जब हर फीचर टीम अपने डॉक्यूमेंट्स की शेप की जिम्मेदारी लेती है, तो ज़िम्मेदारियाँ साफ़ हो जाती हैं: जो टीम फीचर शिप करती है वही उसका डेटा मॉडल भी विकसित करती है। यह माइक्रोसर्विसेज या मॉड्यूलर आर्किटेक्चर में अच्छा काम करता है, जहाँ स्वतंत्र बदलाव लगातार होते हैं।
डॉक्यूमेंट डेटाबेस अक्सर उन टीमों के अनुकूल होते हैं जो बार-बार शिप करती हैं क्योंकि छोटे डेटा एडिशन्स के लिए आमतौर पर समन्वित “स्टॉप-द-वर्ल्ड” डेटाबेस बदलाव की ज़रूरत नहीं पड़ती।
यदि प्रोडक्ट मैनेजर "बस एक और एट्रिब्यूट" (जैसे preferredLanguage या marketingConsentSource) माँगता है, तो डॉक्यूमेंट मॉडल आपको आम तौर पर वह फ़ील्ड तुरंत लिखना शुरू करने देता है। आपको हमेशा माईग्रेशन शेड्यूल करने, टेबल्स लॉक करने, या कई सेवाओं के बीच रिलीज़ विंडो नेगोशिएट करने की आवश्यकता नहीं होती।
इससे स्प्रिन्ट को ब्लॉक करने वाले टास्कों की संख्या घट जाती है: डेटाबेस उस समय उपयोगी रहता है जबकि एप्लिकेशन विकसित हो रही होती है।
JSON-जैसे डॉक्यूमेंट्स में ऑप्शनल फ़ील्ड जोड़ना आम तौर पर बैकवर्ड-कंपैटिबल होता है:
यह पैटर्न डिप्लॉयमेंट्स को शांत बनाता है: आप पहले राइट पाथ रोल आउट कर सकते हैं (नया फ़ील्ड स्टोर करना शुरू करें), फिर बाद में रीड पाथ और UI अपडेट करें—बिना हर मौजूदा डॉक्यूमेंट को तुरंत अपडेट किए।
रीयल सिस्टम शायद ही कभी सभी क्लाइंट्स को एक साथ अपग्रेड करते हैं। आपके पास हो सकता है:
डॉक्यूमेंट डेटाबेस के साथ, टीमें अक्सर फ़ील्ड्स को एडिटिव और ऑप्शनल मानकर "मिक्स्ड वर्ज़न्स" के लिए डिज़ाइन करती हैं। नए राइटर्स डेटा जोड़ सकते हैं बिना पुराने रीडर्स को तोड़े।
एक व्यवहारिक डिप्लॉयमेंट पैटर्न इस तरह दिखता है:
यह दृष्टिकोण वेलोसिटी को ऊँचा रखता है और डेटाबेस बदलाव व एप्लिकेशन रिलीज़ के बीच समन्वय की लागत घटाता है।
टीमें डॉक्यूमेंट डेटाबेस इसलिए पसंद करती हैं क्योंकि आप डेटा को वैसे ही मॉडल कर सकते हैं जैसे आपकी एप्लिकेशन उसे आम तौर पर पढ़ती है। किसी कॉन्सेप्ट को कई तालिकाओं में फैलाने और बाद में फिर से जोड़ने के बजाय, आप अक्सर एक “पूरा” ऑब्जेक्ट एक ही जगह (JSON डॉक्यूमेंट) में स्टोर कर सकते हैं।
डेनॉर्मलाइज़ेशन का मतलब है संबंधित फ़ील्ड्स को डुप्लिकेट या एम्बेड करना ताकि कॉमन क्वेरीज़ एक ही डॉक्यूमेंट रीड से उत्तर पा सकें।
उदाहरण के लिए, एक ऑर्डर डॉक्यूमेंट ग्राहक स्नैपशॉट फ़ील्ड्स (नाम, खरीद के समय ईमेल) और लाइन आइटम्स का एम्बेडेड ऐरे शामिल कर सकता है। यह डिजाइन "मेरे आख़िरी 10 ऑर्डर दिखाओ" जैसी क्वेरीज़ को तेज़ और सरल बना सकती है, क्योंकि UI पेज रेंडर करने के लिए कई लुकअप की ज़रूरत नहीं रखता।
जब किसी स्क्रीन या API उत्तर के लिए डेटा एक डॉक्यूमेंट में रहता है, तब अक्सर मिलता है:
यह रीड-हेवी पाथ्स पर लेटेंसी घटाने में मदद करता है—खासकर प्रोडक्ट फीड्स, प्रोफ़ाइल्स, कार्ट्स, और डैशबोर्ड्स में।
एम्बेडिंग आम तौर पर उपयोगी है जब:
रेफ़रेंसिंग अक्सर बेहतर है जब:
कोई सार्वभौमिक "सर्वोत्तम" डॉक्यूमेंट शेप नहीं है। एक मॉडल जिसे एक क्वेरी के लिए ऑप्टिमाइज़ किया गया है, वह किसी और को धीमा या महँगा बना सकता है। सबसे भरोसेमंद तरीका यह है कि आप अपने वास्तविक क्वेरीज से शुरू करें—जो आपकी एप्लिकेशन वाकई में फ़ेच करती है—और उन रीड पाथ्स के चारों ओर डॉक्यूमेंट्स को आकार दें, फिर उपयोग बदलने पर मॉडल की पुनः समीक्षा करें।
schema-on-read का मतलब है कि आप हर फ़ील्ड और टेबल शेप को पहले से परिभाषित करने के बजाय पढ़ते समय हर डॉक्यूमेंट की संरचना व्याख्यायित करते हैं। व्यवहार में, यह आपको एक नई फ़ीचर शिप करने देता है जो preferredPronouns या नेस्टेड shipping.instructions जोड़ता है बिना पहले डेटाबेस माईग्रेशन समन्वय किए।
अधिकांश टीमें अब भी एक “अपेक्षित शेप” मन में रखती हैं—सिर्फ इसका प्रवर्तन बाद में और चयनात्मक रूप से होता है। एक ग्राहक डॉक्यूमेंट में phone हो सकता है तो किसी में नहीं। एक पुराना ऑर्डर discountCode को स्ट्रिंग के रूप में स्टोर कर सकता है, जबकि नए ऑर्डर्स एक समृद्ध discount ऑब्जेक्ट स्टोर करते हों।
लचीलापन अराजकता नहीं होना चाहिए। सामान्य दृष्टिकोण:
id, createdAt, या status की आवश्यकता और हाई-रिस्क फ़ील्ड्स के प्रकार निर्धारित करना।थोड़ी सी संगति का बहुत फायदा होता है:
camelCase, ISO-8601 टाइमस्टैम्प)schemaVersion: 3) ताकि रीडर्स पुराने और नए शेप्स को सुरक्षित रूप से हैंडल कर सकेंजैसे ही मॉडल स्थिर होता है—आम तौर पर जब आप यह समझ लेते हैं कि किन फ़ील्ड्स वास्तव में कोर हैं—उन फ़ील्ड्स और क्रिटिकल रिलेशनशिप्स के आसपास सख्त वैलिडेशन लागू करें। एक्सपेरिमेंटल या वैकल्पिक फ़ील्ड्स को लचीला रखें, ताकि डेटाबेस तेज़ इटरेशन का समर्थन करे बिना लगातार माईग्रेशन की ज़रूरत पड़े।
जब आपका प्रोडक्ट साप्ताहिक रूप से बदलता है, तो केवल "करेंट" शेप ही मायने नहीं रखता—यह भी जरूरी है कि यह कैसे पहुँचा। डॉक्यूमेंट डेटाबेस चेंज हिस्ट्री रखने के लिए स्वाभाविक रूप से उपयुक्त हैं क्योंकि वे सेल्फ-कॉन्टेंड रिकॉर्ड्स को स्टोर करते हैं जो बदले बिना पुरानी चीज़ों को फिर से लिखने के दबाव में नहीं डालते।
एक सामान्य तरीका है चेंज को इवेंट स्ट्रीम के रूप में स्टोर करना: हर इवेंट एक नया डॉक्यूमेंट होता है जिसे आप जोड़ते हैं (बदलाव के लिए पुराने रो को इन-प्लेस अपडेट करने की बजाय)। उदाहरण: UserEmailChanged, PlanUpgraded, या AddressAdded।
क्योंकि हर इवेंट अपना पूरा JSON डॉक्यूमेंट है, आप उस पल का पूरा संदर्भ कैप्चर कर सकते हैं—किसने किया, क्या ट्रिगर था, और कोई मेटाडेटा जो बाद में काम आ सकता है।
इवेंट परिभाषाएँ शायद ही स्थिर रहें। आप source="mobile", experimentVariant, या नया नेस्टेड ऑब्जेक्ट जैसे paymentRiskSignals जोड़ सकते हैं। डॉक्यूमेंट स्टोरेज के साथ, पुराने इवेंट्स बस उन फ़ील्ड्स को छोड़ सकते हैं और नए इवेंट्स उन्हें शामिल कर सकते हैं।
आपके रीडर्स (सर्विसेस, जॉब्स, डैशबोर्ड्स) गायब फ़ील्ड्स को सुरक्षित रूप से डिफ़ॉल्ट कर सकते हैं, बजाय इसके कि लाखों ऐतिहासिक रिकॉर्ड्स का बैकफिल और माईग्रेट करें बस एक अतिरिक्त एट्रिब्यूट पेश करने के लिए।
उपभोक्ताओं को पूर्वानुमेय रखने के लिए कई टीमें हर डॉक्यूमेंट में schemaVersion (या eventVersion) रखती हैं। इससे क्रमिक रोलआउट संभव होता है:
"क्या हुआ" का एक टिकाऊ इतिहास ऑडिट से परे उपयोगी होता है। एनालिटिक्स टीमें किसी भी बिंदु पर स्टेट को फिर से बना सकती हैं, और सपोर्ट इंजीनियर इवेंट्स को रिप्ले करके या ठीक payload देखकर बग के कारण पता लगा सकते हैं। महीनों में यह रूट-कॉज़ विश्लेषण को तेज़ बनाता है और रिपोर्टिंग को अधिक भरोसेमंद करता है।
डॉक्यूमेंट डेटाबेस बदलाव को आसान बनाते हैं, पर वे डिज़ाइन कार्य को खत्म नहीं करते—वे उसे शिफ्ट कर देते हैं। प्रतिबद्ध होने से पहले यह स्पष्ट होना अच्छा है कि आप लचीलापन के लिए क्या दे रहे हैं।
कई डॉक्यूमेंट डेटाबेस ट्रांज़ैक्शन्स सपोर्ट करते हैं, पर मल्टी-डॉक्यूमेंट ट्रांज़ैक्शन्स सीमित, धीमे, या रिलेशनल DBs की तुलना में महँगे हो सकते हैं—खासकर उच्च-स्केल पर। यदि आपका कोर वर्कफ़्लो कई रिकॉर्ड्स पर "ऑल-ऑर-नथिंग" अपडेट्स मांगता है (उदा., एक साथ ऑर्डर, इन्वेंटरी और लेज़र अपडेट करना), तो अपने DB के हैंडलिंग और प्रदर्शन/जटिलता लागत की जाँच करें।
क्योंकि फ़ील्ड्स ऑप्शनल होते हैं, टीमें अनजाने में एक ही कॉन्सेप्ट की कई वर्ज़न्स बना सकती हैं (उदा., address.zip बनाम address.postalCode)। यह डाउनस्ट्रीम फीचर्स तोड़ सकता है और बग्स को पकड़ना मुश्किल बना देता है। व्यवहारिक समाधान यह है कि प्रमुख डॉक्यूमेंट टाइप्स के लिए एक साझा कॉन्ट्रैक्ट परिभाषित करें (भले ही वह हल्का हो) और वहां जहां ज़रूरी हो वैकल्पिक वैलिडेशन नियम जोड़ें—जैसे पेमेंट स्टेटस, प्राइसिंग, या परमिशन्स।
यदि डॉक्यूमेंट्स स्वतंत्र रूप से विकसित होते हैं, तो एनालिस्ट्स को कई फ़ील्ड नेम्स और गायब मानों के लिए लॉजिक लिखना पड़ सकता है। उन टीमों के लिए जो भारी रिपोर्टिंग पर निर्भर हैं, आपको एक योजना चाहिए जैसे:
रिलेटेड डेटा (जैसे ऑर्डर्स में कस्टमर स्नैपशॉट) एम्बेड करने से रीड्स तेज़ होते हैं, पर जानकारी डुप्लिकेट होती है। जब कोई साझा डेटा बदलता है, तो आपको निर्णय लेना होगा: हर जगह अपडेट करें, इतिहास रखें, या अस्थायी असंगति सहें। यह निर्णय इरादतन लेना चाहिए—अन्यथा आप सूक्ष्म डेटा ड्रिफ्ट का जोखिम उठाते हैं।
डॉक्यूमेंट डेटाबेस उन टीमों के लिए बेहतरीन होते हैं जिनके परिवर्तन लगातार होते हैं, पर वे उन टीमों को इनाम देते हैं जो मॉडलिंग, नेमिंग और वैलिडेशन को चल रहे प्रोडक्ट कार्य के रूप में मानती हैं—एक बार का सेटअप नहीं।
डॉक्यूमेंट डेटाबेस डेटा को JSON डॉक्यूमेंट्स के रूप में स्टोर करते हैं, जो उन स्थितियों में नेचुरल फिट हैं जहाँ आपके फ़ील्ड्स ऑप्शनल हों, बार-बार बदलते हों, या ग्राहक/डिवाइस/प्रोडक्ट लाइन के हिसाब से अलग हों। एक ही कठोर टेबल शेप में हर रिकॉर्ड को ज़बरदस्ती फिट करने के बजाय, आप डेटा मॉडल को धीरे-धीरे विकसित कर सकते हैं और टीमों को आगे बढ़ते रख सकते हैं।
प्रोडक्ट डेटा शायद ही कभी स्थिर रहता है: नए साइज, मटेरियल्स, कंप्लायंस फ्लैग्स, बंडल्स, रीजनल डिस्क्रिप्शन्स और मार्केटप्लेस-विशिष्ट फील्ड्स बार-बार आते रहते हैं। JSON डॉक्यूमेंट्स में नेस्टेड डेटा के साथ, एक “प्रोडक्ट” को कोर फील्ड्स (SKU, price) रखते हुए कैटेगरी-विशिष्ट एट्रिब्यूट्स की अनुमति दी जा सकती है बिना हफ्तों की स्कीमा रीडिज़ाइन के।
प्रोफ़ाइल्स अक्सर छोटे से शुरू होकर बढ़ते हैं: नोटिफिकेशन सेटिंग्स, मार्केटिंग कंसेंट्स, ऑनबोर्डिंग जवाब, फीचर फ्लैग्स, और पर्सनलाइज़ेशन सिग्नल्स। डॉक्यूमेंट डेटाबेस में, यूज़र्स के पास अलग-अलग फ़ील्ड्स का सेट हो सकता है बिना मौजूदा रीड्स को तोड़े। यह स्कीमा लचीलापन एजाइल विकास में मदद करता है, जहाँ एक्सपेरिमेंट्स फ़ील्ड्स जल्दी जोड़ और हटा सकते हैं।
आधुनिक CMS सिर्फ "एक पेज" नहीं है। यह ब्लॉक्स और कंपोनेंट्स का मिश्रण है—हीरो सेक्शन्स, FAQs, प्रोडक्ट करौसेल्स, एम्बेड्स—हर एक की अपनी संरचना होती है। पेजेस को JSON डॉक्यूमेंट्स के रूप में स्टोर करने से एडिटर्स और डेवलपर्स नए कंपोनेंट टाइप्स पेश कर सकते हैं बिना हर ऐतिहासिक पेज को तुरंत माईग्रेट किए।
टेलीमेट्री अक्सर फर्मवेयर वर्ज़न, सेंसर पैकेज, या निर्माता के हिसाब से भिन्न होती है। डॉक्यूमेंट डेटाबेस ऐसे विकसित होते मॉडल्स को अच्छी तरह हैंडल करते हैं: हर इवेंट केवल वही शामिल कर सकता है जो डिवाइस जानता है, जबकि schema-on-read एनालिटिक्स टूल्स को फ़ील्ड्स के मौजूद होने पर उन्हें व्याख्यायित करने देता है।
यदि आप NoSQL बनाम SQL पर निर्णय ले रहे हैं, तो ये वही परिदृश्य हैं जहाँ डॉक्यूमेंट डेटाबेस तेज़ इटरेशन और कम घर्षण के साथ अधिक मूल्य दे सकते हैं।
जब आपका डेटा मॉडल अभी भी सेट हो रहा है, तो "कافی अच्छा और बदलने में आसान" "कागज़ पर परफेक्ट" से बेहतर होता है। ये व्यावहारिक आदतें आपकी गति बनाए रखती हैं बिना डेटाबेस को एक जंक ड्रॉअर बना देने के।
प्रत्येक फीचर की शुरुआत उन प्रमुख रीड्स और राइट्स को लिख कर करें जिन्हें आप प्रोडक्शन में उम्मीद करते हैं: जो स्क्रीन आप रेंडर करेंगे, जो API उत्तर आप लौटाएंगे, और जो अपडेट्स आप अक्सर करेंगे।
यदि एक यूज़र एक्शन अक्सर "order + items + shipping address" चाहिए, तो ऐसा डॉक्यूमेंट मॉडल करें जो उस रीड को न्यूनतम अतिरिक्त फेच के साथ सर्व कर सके। यदि दूसरा एक्शन "स्टेटस के हिसाब से सभी ऑर्डर्स" मांगता है, तो सुनिश्चित करें कि आप उस पाथ के लिए क्वेरी या इंडेक्स कर सकते हैं।
एम्बेडिंग (नेस्टिंग) डेटा तब बढ़िया है जब:
रेफ़रेंसिंग सुरक्षित है जब:
आप दोनों मिला कर भी रख सकते हैं: रीड स्पीड के लिए स्नैपशॉट एम्बेड करें, अपडेट के लिए सोर्स-ऑफ-ट्रुथ का रेफ़रेंस रखें।
भले ही स्कीमा लचीला हो, जिन फील्ड्स पर आप निर्भर करते हैं उनके लिए हल्के नियम (टाइप्स, आवश्यक IDs, अलाउड स्टेटस) जोड़ें। schemaVersion (या docVersion) फ़ील्ड शामिल करें ताकि आपकी एप्लिकेशन पुराने डॉक्यूमेंट्स को सहजता से हैंडल कर सके और उन्हें समय के साथ माईग्रेट कर सके।
माइग्रेशन्स को एक बार की घटना न समझें—उन्हें आवधिक रखरखाव मानें। जैसे ही मॉडल परिपक्व होता है, छोटे बैकफ़िल्स और क्लीनअप शेड्यूल करें (अनयूज्ड फील्ड्स, रीनैम किए हुए कीज़, डेनॉर्मलाइज़्ड स्नैपशॉट्स) और पहले/बाद के प्रभाव को मापें। एक साधारण चेकलिस्ट और हल्का माईग्रेशन स्क्रिप्ट बहुत काम आ जाते हैं।
डॉक्यूमेंट डेटाबेस और रिलेशनल डेटाबेस के बीच चुनाव करना "कौन बेहतर है" से कम और आपके प्रोडक्ट किस तरह के बदलाव ज्यादा अनुभव करता है उससे ज़्यादा जुड़ा है।
डॉक्यूमेंट डेटाबेस अच्छा विकल्प है जब आपका डेटा शेप बार-बार बदलता है, विभिन्न रिकॉर्ड्स में अलग फ़ील्ड्स हो सकते हैं, या टीमें बिना हर स्प्रिंट में स्कीमा माईग्रेशन समन्वय किए फीचर्स शिप करना चाहती हैं।
वे तब भी अच्छा मेल खाते हैं जब आपकी एप्लिकेशन नैचुरली "पूरा ऑब्जेक्ट" के साथ काम करती है—जैसे ऑर्डर (कस्टमर info + आइटम्स + डिलीवरी नोट्स) या यूज़र प्रोफ़ाइल (सेटिंग्स + प्रेफ़रेंसेस + डिवाइस info) को JSON डॉक्यूमेंट के रूप में स्टोर करना।
रिलेशनल डेटाबेस तब चमकते हैं जब आपको चाहिए:
यदि आपकी टीम का काम ज्यादातर क्रॉस-टेबल क्वेरीज और एनालिटिक्स ऑप्टिमाइज़ेशन है, SQL अक्सर दीर्घकालिक सरल घर होता है।
कई टीमें दोनों का उपयोग करती हैं: "कोर सिस्टम ऑफ़ रिकॉर्ड" (बिलिंग, इन्वेंटरी, एंटाइटलमेंट्स) के लिए रिलेशनल और तेजी से बदलने वाले या रीड-ऑप्टिमाइज़्ड व्यूज़ (प्रोफ़ाइल्स, कंटेंट मेटाडेटा, प्रोडक्ट कैटलॉग) के लिए डॉक्यूमेंट स्टोर। माइक्रोसर्विसेज में यह स्वाभाविक रूप से मेल खा सकता है: हर सर्विस उस स्टोरेज मॉडल को चुनती है जो उसकी बाउंडरीज़ के अनुरूप हो।
यह भी याद रखने योग्य है कि हाइब्रिड रिलेशनल DB के अंदर भी मौजूद हो सकता है। उदाहरण के लिए, PostgreSQL JSON/JSONB का उपयोग करके सेमी-स्ट्रक्चर्ड फील्ड्स को स्टॉर कर सकता है साथ ही मजबूत टाइप वाले कॉलम भी रख सकता है—उपयोगी जब आप ट्रांज़ैक्शनल कंसिस्टेंसी और विकसित एट्रिब्यूट्स दोनों चाहते हों।
अगर आपका स्कीमा साप्ताहिक बदल रहा है, तो बॉटलनेक अक्सर एंड-टू-एंड लूप होता है: मॉडल अपडेट करना, APIs, UI, माईग्रेशन्स (अगर हों), और बदलाओं को सुरक्षित रूप से रोल आउट करना। Koder.ai ऐसे इटरेशन के लिए डिजाइन किया गया है। आप चैट में फीचर और डेटा शेप बयान कर सकते हैं, एक काम करने वाला वेब/बैकएंड/मोबाइल इम्प्लीमेंटेशन जनरेट कर सकते हैं, और जब आवश्यक हो उसे परिष्कृत कर सकते हैं।
व्यवहार में, टीमें अक्सर रिलेशनल कोर से शुरू करती हैं (Koder.ai का बैकएंड स्टैक Go के साथ PostgreSQL है) और जहाँ उपयुक्त होता है वहाँ डॉक्यूमेंट-स्टाइल पैटर्न इस्तेमाल करती हैं (उदा., JSONB लचीले एट्रिब्यूट्स या इवेंट पेलोड्स के लिए)। Koder.ai की स्नैपशॉट्स और रोलबैक भी मदद करती हैं जब एक एक्सपेरिमेंटल डेटा शेप को जल्दी रिवर्ट करने की ज़रूरत पड़े।
कमीट करने से पहले एक छोटा मूल्यांकन चलाएँ:
यदि आप विकल्पों की तुलना कर रहे हैं, तो स्कोप को तंग और टाइम-बॉक्स्ड रखें—फिर उस मॉडल को बढ़ाएँ जो आपको कम सरप्राइज़ के साथ शिप करने में मदद करे।
अगर आप स्टोरेज ट्रेडऑफ़्स का मूल्यांकन करने पर और जानकारी चाहते हैं, तो देखिए /blog/document-vs-relational-checklist।
एक डॉक्यूमेंट डेटाबेस हर रिकॉर्ड को एक सेल्फ-कॉन्टेंड JSON-जैसी डॉक्यूमेंट के रूप में स्टोर करता है (नेस्टेड ऑब्जेक्ट और ऐरे शामिल)। एक व्यवसायिक ऑब्जेक्ट को कई तालिकाओं में बाँटने के बजाय, आप अक्सर पूरा ऑब्जेक्ट एक ऑपरेशन में पढ़ते और लिखते हैं, आमतौर पर एक कलेक्शन के भीतर (उदाहरण: users, orders).
तेज़ी से बदलते प्रोडक्ट्स में नई गुण-अवश्यताएँ लगातार आती हैं (प्रेफरेंस, बिलिंग मेटाडेटा, कंसेंट फ़्लैग, एक्सपेरिमेंट फ़ील्ड)। लचीले स्कीमा आपको नए फ़ील्ड तुरंत लिखने देते हैं, पुराने डॉक्यूमेंट्स को वैसा ही रहने देते हैं, और बाद में बैकफिल करने का विकल्प देते हैं—इस तरह छोटे बदलाव बड़े माईग्रेशन प्रोजेक्ट में नहीं बदलते।
जरूरी नहीं कि बिलकुल कोई स्कीमा न हो। ज़्यादातर टीमें अब भी “अपेक्षित रूप” रखती हैं, पर प्रवर्तन (enforcement) बदलकर निम्न स्थानों पर होता है:
इस तरह लचीलापन बना रहता है जबकि गंदे, असंगत डॉक्यूमेंट्स कम होते हैं।
नए फ़ील्ड्स को एडिटिव और ऑप्शनल मानें:
यह प्रोडक्शन में मिश्रित डेटा वर्शन का समर्थन करता है बिना डाउनटाइम वाले भारी माईग्रेशन के।
अपने सबसे सामान्य रीड्स के लिए मॉडल बनाइए: यदि किसी स्क्रीन या API को “order + items + shipping address” चाहिए, तो व्यवहार्य होने पर उन सबको एक डॉक्यूमेंट में रखें। इससे राउंड-ट्रिप्स कम होते हैं और जॉइन-भारी एसेंबली की ज़रूरत घटती है, जिससे रीड-हेवी पाथ्स पर लेटेंसी सुधरती है।
जब चाइल्ड डेटा आम तौर पर पैरेंट के साथ पढ़ा जाता है और आकार में बाउंडेड होता है (उदा., 20 आइटम तक), तो एम्बेडिंग का उपयोग करें।
जब संबंधित डेटा बड़ा/असीमित हो, कई पैरेंट्स द्वारा शेयर किया जाता हो, या वह अक्सर बदलता हो तो रेफ़रेंसिंग बेहतर है।
आप दोनों मिला कर भी रख सकते हैं: तेज़ रीड के लिए स्नैपशॉट एम्बेड करें और अपडेट्स के लिए सोर्स-ऑफ-ट्रुथ का रेफ़रेंस रखें।
यह इस तरह मदद करता है कि “एक फ़ील्ड जोड़ना” डिप्लॉयमेंट्स को अधिक बैकवर्ड-कंपैटिबल बनाता है:
यह कई सेवाओं या पुराने मोबाइल क्लाइंट्स के साथ विशेष रूप से उपयोगी है।
हल्के गार्डरेल शामिल करें:
id, createdAt, status)आम दृष्टिकोणों में शामिल है: एपेंड-ओनली इवेंट डॉक्यूमेंट्स (हर परिवर्तन एक नया डॉक्यूमेंट), और वर्शनिंग (eventVersion/schemaVersion)। भविष्य के इवेंट्स में नए फ़ील्ड्स जोड़ना इतिहास को फिर से लिखे बिना संभव है, जबकि कंज्यूमर्स धीरे-धीरे दोनों वर्ज़न्स पढ़ते हैं।
मुख्य ट्रेडऑफ़्स:
कई टीमें हाइब्रिड अपनाती हैं: सख्त सिस्टम-ऑफ-रिकॉर्ड के लिए रिलेशनल और तेजी से बदलने वाले/रीड-ऑप्टिमाइज़्ड व्यूज़ के लिए डॉक्यूमेंट स्टोर।
camelCase, ISO-8601 टाइमस्टैम्प)schemaVersion/docVersion फ़ील्डये कदम address.zip बनाम address.postalCode जैसी ड्रिफ्ट से बचाते हैं।