मल्टी-रिजन उपलब्धता के लिए PostgreSQL बनाम CockroachDB

आप वास्तव में किस समस्या को हल करने की कोशिश कर रहे हैं?

"मल्टी-रिजन उपलब्धता" अलग-अलग मकसदों के लिए इस्तेमाल होता है। इन मकसदों को मिलाकर रखना टीमों को गलत डेटाबेस चुनने पर ले जा सकता है।

PostgreSQL और CockroachDB की तुलना करने से पहले, लिखें (1) कौन सी खास विफलता से आप बचना चाहते हैं और (2) उस विफलता के दौरान उपयोगकर्ताओं को क्या अनुभव होना चाहिए।

ज़्यादातर टीमें इनमे से कुछ मिलीजुली चीज़ें चाहती हैं:

• जब कोई रीजन डाउन हो तो उच्च अपटाइम (फेलओवर)
• मुख्य रीजन से दूर उपयोगकर्ताओं के लिए तेज़ प्रतिक्रियाएँ (कम लेटेंसी)
• भौगोलिक नियमों से बंधा डेटा (लोकैलिटी या रेसिडेन्सी)
• लोड के तहत भी predictable व्यवहार, सिर्फ़ हैप्पी-पाथ टेस्ट नहीं

साझा लक्ष्य सीधा है: किसी दूसरे महाद्वीप का ग्राहक भी तेज़ और सही नतीजे पाए।

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

एक ठोस उदाहरण: जर्मनी में एक उपयोगकर्ता अपना शिपिंग पता अपडेट करता है और तुरंत चेकआउट करता है। अगर चेकआउट यूज़र को US रेप्लिका से पढ़ता है जो कुछ सेकंड पीछे है, तो ऑर्डर पुराने पते से जा सकता है। कुछ प्रोडक्ट्स इसे स्पष्ट UX और retries से सहन कर लेते हैं। अन्य (पेमेंट्स, इन्वेंटरी, अनुपालन) नहीं कर सकते।

कोई सार्वभौमिक सर्वोत्तम विकल्प नहीं है। सही उत्तर इस पर निर्भर करता है कि क्या बिल्कुल गलत नहीं हो सकता, क्या थोड़ा धीमा हो सकता है, और आपकी टीम रोज़ाना कितनी ऑपरेशनल जटिलता झेल सकती है।

"कई रीजन में उपलब्ध" के दो दृष्टिकोण

जब लोग PostgreSQL बनाम CockroachDB की तुलना मल्टी-रिजन उपयोग के लिए करते हैं, तो वे अक्सर दो अलग डिज़ाइनों की तुलना कर रहे होते हैं।

PostgreSQL के साथ सबसे सामान्य सेटअप सिंगल-प्राइमरी होता है। एक रीजन वह "घर" है जहाँ लिखावट होती है। अन्य रीजन रीड रेप्लिका चलाते हैं जो प्राइमरी से बदलाव कॉपी करते हैं। यदि प्राइमरी रीजन फेल हो जाए, तो आप किसी रेप्लिका को प्रमोट करते हैं और ऐप को उस पर पॉइंट करते हैं। यह अच्छा किया जाए तो बढ़िया काम कर सकता है, पर सिस्टम अभी भी एक मुख्य लिखने के स्थान और एक विचारपूर्वक फेलओवर योजना के आस-पास व्यवस्थित रहता है।

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

ऐप टीम के लिए बदलने वाली चीज़ SQL सिंटैक्स से कम और अपेक्षाओं से ज़्यादा है:

• Writes: PostgreSQL में लिखावटें प्राथमिक के पास सबसे तेज़ होती हैं। CockroachDB में लिखावटें अक्सर कई रेप्लिकाओं की सहमति चाहती हैं, जिसमें क्रॉस-रिजन कन्फर्मेशन शामिल हो सकता है।
• Reads: PostgreSQL लोकल रीड्स रेप्लिका से दे सकता है (स्टेलनस व्यापार के साथ)। CockroachDB कंसिस्टेंट रीड्स दे सकता है, पर डेटा के प्लेसमेंट के अनुसार समन्वय लागत देनी पड़ सकती है।
• Failures: PostgreSQL फेलओवर एक स्विच है जिसे आप ट्रिगर और मैनेज करते हैं। CockroachDB को कुछ रीजनल फेलियर्स के बीच चलते रहने के लिए बनाया गया है, पर सिर्फ उसकी रेप्लिकेशन और क्वोरम नियमों के भीतर।

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

सुसंगतता की गारंटी: आप किस पर भरोसा कर सकते हैं

सुसंगतता, सरल भाषा में: जब कोई रिकॉर्ड अपडेट करे तो सभी को वही सच्चाई दिखनी चाहिए।

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

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

दोनों सिस्टम serializable ट्रांज़ैक्शन्स का समर्थन कर सकते हैं (डेटाबेस समानांतर बदलावों को ऐसे बनाता है जैसे वे एक-एक करके हुए हों)। फर्क यह है कि काम कहां होता है: PostgreSQL अधिकतर लागत एक ही रीजन के अंदर उठाता है, जबकि वितरित सिस्टम यह लागत रीजनों के पार चुका सकता है।

कुछ प्रश्न ट्रेडऑफ़ को ठोस बनाते हैं:

• क्या उपयोगकर्ता कभी स्टेल रीड्स देख सकते हैं, भले ही कुछ सेकंड के लिए?
• क्या दो रीजन स्वतंत्र रूप से लिखने स्वीकार कर सकती हैं, या क्या हर लिखावट का ग्लोबली सहमति होना ज़रूरी है?
• यदि दो लोग एक ही रिकॉर्ड को एक ही समय में एडिट करते हैं तो क्या होता है? क्या आप कॉन्फ्लिक्ट्स की अनुमति देते हैं?
• कौन से एक्शन्स हर बार सही होने चाहिए (पेमेंट्स, परमिशन्स) बनाम "आख़िरकार ठीक" होने वाली चीज़ें (एनालिटिक्स)?
• क्या आपको एक वैश्विक सत्य चाहिए, या कुछ डेटा के लिए "स्थानीय सत्य" स्वीकार्य है?

लेटेंसी अपेक्षाएँ: उपयोगकर्ता क्या महसूस करेंगे

एक उपयोगी मानसिक मॉडल: दूरी समय जोड़ती है, और समन्वय और भी अधिक समय जोड़ता है। दूरी भौतिकी है। समन्वय उस टाइम का मतलब है जब डेटाबेस को "हो गया" कहने से पहले अन्य नोड्स के सहमति का इंतज़ार करना पड़ता है।

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

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

औसत लेटेंसी से निर्णय मत लें। p95 लेटेंसी को देखें (सबसे धीमे 5% अनुरोध)। उपयोगकर्ता उन रोकों को नोटिस करते हैं। एक पेज जो आमतौर पर 120 ms में लोड होता है पर दिन में कुछ बार 800 ms पर पहुंचता है, वह फ्लीकी महसूस होता है, भले ही औसत ठीक दिखे।

"तेज़" का मतलब आपके वर्कलोड पर निर्भर करता है। लिख-भारी ऐप्स समन्वय लागत को अधिक महसूस करते हैं। रीड-भारी ऐप्स तब अच्छा कर सकते हैं जब रीड्स लोकल हों। बड़े ट्रांज़ैक्शन, बहु-स्टेप वर्कफ़्लो और "हॉट" रो—जिन्हें कई उपयोगकर्ता अपडेट कर रहे हों—लेटेंसी को और बढ़ाते हैं।

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

ऑपरेशनल ट्रेडऑफ़: रोज़ाना आप क्या चलाएँगे

फीचर लिस्ट्स से ज़्यादा मायने रखता है कि क्या चीज़ें आपको रात में जगाती हैं और आपकी टीम को हर हफ्ते क्या करना पड़ता है।

PostgreSQL ऑपरेशन्स परिचित और प्रत्याशित होते हैं। मल्टी-रिजन आमतौर पर यह भी मांगता है कि आप सपोर्टिंग हिस्सों—रेप्लिका, फेलओवर टूलिंग, या अलग-अलग रीजन क्लस्टर्स और ऐप-लेवल रूटिंग—को भी ऑपरेट करें। काम अक्सर योजना को साबित करने (फेलओवर ड्रिल्स, रिस्टोर) में होता है बजाय रोज़ के क्वेरी ट्यूनिंग के।

CockroachDB अधिकतर मल्टी-रिजन कहानी को डेटाबेस में ही धकेल देता है। इससे आसपास के घटकों की संख्या कम हो सकती है, पर इसका मतलब है कि आपको एक वितरित सिस्टम समझना होगा: नोड हेल्थ, रेप्लिकेशन, रिबैलेंसिंग, और क्लस्टर का तनाव के दौरान व्यवहार।

व्यवहार में, टीमें या तो सेटअप में वही मूल कार्य करती हैं:

• अपग्रेड्स की योजना बनाना और ड्राइवर्स, मॉनिटरिंग, और ऑटोमेशन का सत्यापन
• बैकअप लेना और रिस्टोर टेस्ट चलाना (सिर्फ बैकअप मौजूद होने की जांच नहीं)
• फेलओवर का अभ्यास और रनबुक स्टेप्स लिखना
• धीमी क्वेरियों की जांच करना और "बुरी क्वेरी" को क्रॉस-रिजन लेटेंसी से अलग करना
• स्टोरेज ग्रोथ और दीर्घकालिक कम्पैक्शन बिहेवियर पर नज़र रखना

फेलियर मोड अलग महसूस करते हैं। PostgreSQL के साथ, एक रीजन आउटेज अक्सर एक जान-बूझकर फेलओवर ट्रिगर करता है। आप पढ़ने-केवल मोड, बढ़ी हुई लेटेंसी, या घटित फ़ंक्शनालिटी को स्वीकार कर सकते हैं। वितरित डेटाबेस में कठिन मामला अक्सर नेटवर्क स्प्लिट होता है। सिस्टम सुसंगतता बचाने के लिए कुछ लिखावटों को तब तक अस्वीकार कर सकता है जब तक क्वोरम उपलब्ध न हो।

ऑब्ज़र्वेबिलिटी भी बदलती है। सिंगल प्राइमरी में आप अक्सर पूछते हैं, "यह क्वेरी धीमी क्यों है?" वितरित क्लस्टर में आप यह भी पूछेंगे, "यह डेटा कहाँ रखा गया था, और क्वेरी क्यों क्रॉस-रिजन गई?"

लागतें स्पष्ट और अप्रत्याशित दोनों तरीक़ों से बढ़ती हैं। दूसरे रीजन जोड़ने से नोड काउंट बढ़ सकता है, पर साथ ही मॉनिटरिंग, घटना जटिलता और उत्पाद टीमों को लेटेंसी व विफलता व्यवहार समझाने में भी समय बढ़ता है।

वितरित सेटअप में स्कीमा परिवर्तन और माइग्रेशन्स

स्कीमा परिवर्तन किसी भी डेटा के आकार के अपडेट को कहते हैं: फीचर के लिए नया कॉलम जोड़ना, फ़ील्ड का नाम बदलना, प्रकार बदलना (int से string), इंडेक्स जोड़ना, या नई टेबल लाना।

PostgreSQL में माइग्रेशन्स तेज़ हो सकते हैं, पर जोखिम अक्सर लॉक टाइम और लिखावटों को ब्लॉक करने का होता है। कुछ परिवर्तन पूरे टेबल को री-राइट कर देते हैं या अपेक्षा से लंबा लॉक रखते हैं, जो पीक ट्रैफ़िक के दौरान सामान्य डिप्लॉयमेंट को एक इन्सिडेंट में बदल सकता है।

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

कुछ आदतें माइग्रेशन्स को नीरस बनाए रखती हैं:

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

उदाहरण: आप EU उपयोगकर्ताओं के लिए preferred_language जोड़ते हैं। कॉलम जोड़ें, एक रिलीज़ के लिए दोनों पुराने और नए फील्ड लिखें, फिर UI अपडेट करें नई फ़ील्ड पढ़ने के लिए, और केवल तभी पुराना हटाएँ। मल्टी-रिजन सेटअप में staged रोलआउट तब कम आश्चर्य लाते हैं जब रीजन अलग-अलग स्पीड से पकड़ते हैं।

जल्दी वितरित होने की असली लागत

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

अगर आप अपने लक्ष्यों को एक सिंगल प्राइमरी रीजन से पूरा कर सकते हैं, तो शुरुआत में सरल बने रहना अक्सर जीतता है। कम घटक, स्पष्ट विफलताएँ, और तेज़ डिबगिंग—ये सब फ़ायदे हैं। हायरिंग भी आसान होती है क्योंकि गहरी PostgreSQL विशेषज्ञता आम है, और लोकल डेवलपमेंट और CI भी सरल रहते हैं।

टीमें अक्सर पहले केंद्रीकृत रहती हैं क्योंकि यह तेज़ इटरेशन, सरल रोलबैक और अधिक प्रत्याशित प्रदर्शन का समर्थन करता है। ऑन-कॉल भी आसान होता है जब सिस्टम में कम घटक हों।

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

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

एक उपयोगी नियम: पहले मांग को वैध करें, फिर तब वितरित करें जब दर्द मापनीय हो। सामान्य ट्रिगर हैं: किसी रीजन में लगातार SLO मिस होना, लेटेंसी के कारण लगातार यूज़र ड्रॉप-ऑफ, या अनुपालन आवश्यकताएँ जो डील्स रोकती हैं।

यदि आप AppMaster जैसा टूल इस्तेमाल कर रहे हैं, तो पहले सरल डिप्लॉयमेंट से शुरू करना मददगार हो सकता है जबकि आप वर्कफ़्लो और डेटा मॉडल पर काम करें, और फिर जब प्रोडक्ट और ट्रैफ़िक पैटर्न सिद्ध हों तो मल्टी-रिजन योजना पर जाएँ।

चुनने के लिए चरण-दर-चरण तरीका

"मल्टी-रिजन" कुछ संख्याओं और कुछ यूज़र फ्लोज़ में तब स्पष्ट होता है जब आप इसे बदल दें।

चरण-दर-चरण

1. साधारण शब्दों में RPO और RTO लिखें। उदाहरण: "यदि एक रीजन डाइ, हम 1 मिनट तक का डेटा खो सकते हैं (RPO), और हमें 15 मिनट में वापस आना चाहिए (RTO)।" यदि आप प्रतिबद्ध लिखावट खोने को बर्दाश्त नहीं कर सकते, तो स्पष्ट रूप से लिख दें।
2. जहाँ उपयोगकर्ता हैं उन्हें मैप करें, और लिख-आवश्यक क्रियाओं को चिन्हित करें। अपनी रीजनें और शीर्ष एक्शन्स की सूची बनाएं: साइन-अप, चेकआउट, पासवर्ड रीसेट, टिप्पणी पोस्ट करना, फीड देखना। सभी लिखावटें समान महत्वपूर्ण नहीं हैं।
3. प्रत्येक फीचर के लिए सुसंगतता ज़रूरतें सेट करें। पेमेंट्स, इन्वेंटरी, और अकाउंट बैलेंस आमतौर पर सख्त सहीपन चाहते हैं। फीड्स, एनालिटिक्स, और "last seen" अक्सर थोड़ी देरी स्वीकार करते हैं।
4. लेटेंसी बजट सेट करें और टार्गेट रीजन से टेस्ट करें। तय करें कि "पर्याप्त तेज़" का मतलब क्या है (उदाहरण के लिए, प्रमुख एक्शन्स के लिए 200–400 ms), फिर उन रीजन से राउंड-ट्रिप टाइम नापें जो मायने रखते हैं।
5. अपरेटिंग मॉडल चुनें जिसे आपकी टीम संभाल सकती है। ऑन-कॉल समय, डेटाबेस कौशल, और जटिलता सहने की सीमा के बारे में ईमानदार रहें।

एक त्वरित उदाहरण

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

यदि आप AppMaster पर बनाते हैं, तो विज़ुअल बिज़नेस प्रोसेस में लॉजिक रखने से बाद में डिप्लॉयमेंट रीजन या डेटाबेस रणनीति बदलना कम दर्दनाक हो सकता है।

उदाहरण परिदृश्य: एक ही प्रोडक्ट पर US और EU ग्राहक

कल्पना कीजिए एक B2B SaaS जहाँ एक अकाउंट में टीम मेंबर न्यूयॉर्क और बर्लिन दोनों हैं। सभी एक ही टिकट, इनवॉइस, और उपयोग सीमा देखते हैं। बिलिंग साझा है, इसलिए एक पेमेंट इवेंट का तुरंत पूरे अकाउंट की पहुँच पर असर होना चाहिए।

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

CockroachDB जैसे मल्टी-रिजन वितरित डेटाबेस के साथ, आप दोनों रीजन के पास डेटा रख सकते हैं और एक लॉजिकल डेटाबेस बनाए रख सकते हैं। ट्रेडऑफ़ यह है कि कई लिखावटों और कुछ रीड्स को सुसंगत रहने के लिए रीजनों के पार समन्वय करना पड़ता है। वह अतिरिक्त क्रॉस-रिजन राउंड ट्रिप सामान्य रास्ते का हिस्सा बन जाता है, विशेषकर साझा रिकॉर्ड्स जैसे अकाउंट सेटिंग्स और बिलिंग के लिए।

अक्सर काम आने वाला चरणबद्ध प्लान:

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

यदि आप AppMaster पर बनाते हैं, तो विज़ुअल बिज़नेस प्रोसेसेस में लॉजिक रखने से बाद में डिप्लॉयमेंट रीजन या डेटाबेस रणनीति बदलना कम मुश्किल हो जाता है।

टीमों द्वारा की जाने वाली आम गलतियाँ

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

एक और सामान्य जाल यह है कि सुसंगतता की अपेक्षाओं को मिलाया जाता है बिना इसे मानते हुए। टीमें बैलेंस, इन्वेंटरी, और परमिशन्स के लिए सख्त सटीकता चाहती हैं, पर ऐप के अन्य हिस्सों को "काफी ठीक" मानती हैं। फिर यूज़र एक स्क्रीन पर एक मान देखते हैं और अगले स्टेप पर दूसरा।

ध्यान देने योग्य पैटर्न:

• सभी लिखावटों को लोकल महसूस कराने की उम्मीद रखना भले ही वे क्रॉस-रिजन कन्फर्मेशन मांगती हों
• eventual consistency को सिर्फ UI विवरण मानना और बाद में पता लगना कि यह व्यापार नियम तोड़ता है (रिफंड, कोटा, एक्सेस कंट्रोल)
• ऑपरेशनल वास्तविकता को पहले इन्सिडेंट के बाद सीखना (बैकअप, अपग्रेड, नोड हेल्थ, रीजन फ़ेल्योर)
• धीमे ट्रांज़ैक्शन्स को डिबग करने में लगने वाले समय को कम आंके क्योंकि लॉग और डेटा रीजन-ओवर-रीजन फैला होता है
• पहली पसंद को स्थायी निर्णय मान लेना बजाय एक विकास पथ की योजना बनाने के

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

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

कन्फर्म करने से पहले एक त्वरित चेकलिस्ट

किसी दिशा का चुनाव करने से पहले तय करें कि आपके उत्पाद के लिए "अच्छा" क्या है। मल्टी-रिजन सेटअप वास्तविक समस्याएँ हल कर सकता है, पर वे लेटेंसी, सुसंगतता और ऑपरेशन्स के बारे में लगातार विकल्प थोपता है।

चेकलिस्ट संक्षेप और विशिष्ट रखें:

• अपनी शीर्ष 3 यूज़र क्रियाएँ पहचानें (उदा.: साइन-इन, चेकआउट, साझा रिकॉर्ड अपडेट) और उन उपयोगकर्ताओं के लोकेशन नोट करें।
• तय करें कि किन चीज़ों को रीजनों में मजबूत रूप से सुसंगत रहना चाहिए और किन्हें देरी सहनी चाहिए।
• अपनी विफलता कहानी साधारण शब्दों में लिखें: "अगर रीजन X 1 घंटे के लिए डाउन है, तो Y रीजन के उपयोगकर्ता A और B कर सकते हैं, पर C नहीं।"
• बैकअप, रिस्टोर टेस्टिंग, अपग्रेड्स, और मॉनिटरिंग के लिए मालिकाना तय करें।
• स्टेज्ड रोलआउट के साथ ऐप संगत रखने वाला स्कीमा परिवर्तन योजना बनाएं।

यदि आप कोई नो-कोड प्लेटफ़ॉर्म जैसे AppMaster इस्तेमाल कर रहे हैं, तो यह चेकलिस्ट बिल्ड नोट्स में पहले डालने से आपके डेटा मॉडल, बिज़नेस लॉजिक और रोलआउट स्टेप्स बदलते आवश्यकताओं के साथ संरेखित रहते हैं।

अगले कदम: अपनी धारणाओं का परीक्षण करें और बिल्ड पथ चुनें

अधिकतर टीमों को दिन एक पर वितरित डेटाबेस नहीं चाहिए। उन्हें भविष्यवाणी योग्य व्यवहार, सरल ऑपरेशन, और बढ़ने का स्पष्ट तरीका चाहिए।

यह निर्णय आमतौर पर एक सवाल पर घूमता है: क्या आपको कोर वर्कफ़्लो के लिए कई रीजनों में सही, सक्रिय लिखावटें चाहिए?

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

अपनी पसंद को दबाव में परखने का व्यावहारिक तरीका एक फोकस्ड प्रूफ है जो असली वर्कफ़्लो इस्तेमाल करे।

एक छोटा प्रूफ प्लान (1–2 दिन)

• हर मायने रखने वाली रीजन से p95 लेटेंसी नापें (रीड और राइट)।
• एक विफलता मोड सिमुलेट करें (नोड बंद करें, रीजन ट्रैफ़िक ब्लॉक करें) और रिकॉर्ड करें क्या टूटता है।
• 2–3 क्रिटिकल ट्रांज़ैक्शन्स एंड-टू-एंड चलाएं (साइनअप, चेकआउट, प्रोफ़ाइल अपडेट) और retries, timeouts, और यूज़र-नज़र आने वाली त्रुटियाँ देखें।
• एक अपेक्षित स्कीमा परिवर्तन आज़माएँ (कॉलम जोड़ना, इंडेक्स जोड़ना)। समय लें और नोट करें क्या ब्लॉक होता है।

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

एक सामान्य बिल्ड पथ है PostgreSQL से शुरू करना, स्कीमा साफ रखना (स्पष्ट प्राइमरी कीज़, कम क्रॉस-टेबल राइट hotspots), और डिजाइन ऐसा रखना कि रीजन-विशिष्ट डेटा बाद में विभाजित करना आसान हो।

यदि आप AppMaster इस्तेमाल कर रहे हैं, तो आप Data Designer में PostgreSQL स्कीमा मॉडल कर सकते हैं और प्रोडक्शन-रेडी एप्स जेनरेट कर सकते हैं जिन्हें आप अपने चुने हुए क्लाउड पर डिप्लॉय करके यह सत्यापित कर सकें कि मल्टी-रिजन राइट्स वास्तव में आवश्यक हैं या नहीं। यदि आप उस रास्ते का पता लगाना चाहते हैं, तो AppMaster पर appmaster.io पर एक साधारण तरीका है पूरा स्टैक (बैकेंड, वेब, और मोबाइल) प्रोटोटाइप करने का बिना बहुत जल्दी जटिल मल्टी-रिजन आर्किटेक्चर अपनाए।