बहु-किरायेदार SaaS आर्किटेक्चर: सीटीओ को क्या जानना आवश्यक है

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

यह निर्णय आपके डेटाबेस स्कीमा, आपकी परिनियोजन पाइपलाइन, आपकी अनुपालन कहानी और वर्षों तक आपकी लागत संरचना को आकार देता है। इसे गलत समझें, और जब आपका रोडमैप रुक जाएगा तो आपको एक अलग मॉडल पर माइग्रेट करने में छह महीने लगेंगे।

विचार करने लायक तीन मॉडल हैं। प्रत्येक अलग-अलग तरीकों से लागत, अलगाव और परिचालन जटिलता को दूर करता है।

तीन बहु-किरायेदार वास्तुकला मॉडल

1. डेटाबेस-प्रति-किरायेदार

प्रत्येक किरायेदार को अपना स्वयं का डेटाबेस मिलता है। एप्लिकेशन परत किरायेदार पहचानकर्ता के आधार पर प्रश्नों को सही डेटाबेस पर रूट करती है, जिसे आमतौर पर उपडोमेन, एपीआई कुंजी या जेडब्ल्यूटी दावे से हल किया जाता है।

यह सबसे मजबूत आइसोलेशन मॉडल है. किरायेदार ए का डेटा किरायेदार बी के डेटा से एक अलग डेटाबेस में रहता है। क्वेरी बग के लिए किरायेदारों के बीच पंक्तियों को लीक करने का कोई तरीका नहीं है, क्योंकि पंक्तियाँ अलग-अलग कनेक्शन पर अलग-अलग डेटाबेस में मौजूद हैं।

लाभ:

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

नुकसान:

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

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

2. साझा डेटाबेस, स्कीमा पृथक्करण

एक डेटाबेस, लेकिन प्रत्येक किरायेदार को अपना स्वयं का स्कीमा (नेमस्पेस) मिलता है। PostgreSQL में, इसका मतलब है कि प्रत्येक किरायेदार के पास अपने स्वयं के स्कीमा नाम के तहत तालिकाओं का एक अलग सेट है: tenant_abc.users, tenant_xyz.users। एप्लिकेशन प्रश्नों को सही स्कीमा पर रूट करने के लिए प्रत्येक कनेक्शन पर search_path सेट करता है।

यह बीच का रास्ता है. आपको अलग-अलग डेटाबेस की तुलना में कम लागत पर, साझा तालिकाओं की तुलना में बेहतर अलगाव मिलता है।

लाभ:

• डेटाबेस-प्रति-किरायेदार से सस्ता। एक डेटाबेस इंस्टेंस, एक कनेक्शन पूल, एक मॉनिटरिंग स्टैक।
• सभ्य अलगाव. स्कीमा एक नामस्थान सीमा प्रदान करती हैं। एक स्कीमा में गलत कॉन्फ़िगर की गई क्वेरी दूसरे स्कीमा की तालिकाओं तक नहीं पहुंच सकती (मान लीजिए कि आपने search_path सही ढंग से सेट किया है)।
• प्रति-किरायेदार बैकअप pg_dump --schema के माध्यम से संभव है।
• डेटाबेस-प्रति-किरायेदार की तुलना में माइग्रेशन आसान है। आप प्रति स्कीमा एक बार माइग्रेशन चलाते हैं, लेकिन सभी स्कीमा एक ही डेटाबेस में रहते हैं, इसलिए टूलींग आसान है।

नुकसान:

• स्कीमा बहाव. जब कुछ स्कीमा पर माइग्रेशन विफल हो जाता है लेकिन अन्य पर सफल हो जाता है, तो अंत में आप किरायेदारों के साथ अपनी स्कीमा के विभिन्न संस्करण चला रहे होते हैं। इसे डिबग करना दयनीय है।
• PostgreSQL हजारों स्कीमा को अच्छी तरह से संभाल नहीं पाता है। पिछले 5,000-10,000 स्कीमा में, आप pg_catalog लुकअप, धीमी pg_dump बार और ऑटोवैक्यूम विवाद में प्रदर्शन में गिरावट का सामना करेंगे।
• साझा डेटाबेस के समान ही शोर-शराबा वाला जोखिम। एक किरायेदार की महंगी क्वेरी अभी भी उसी CPU और I/O के लिए प्रतिस्पर्धा करती है।
• टूलींग समर्थन असंगत है. ओआरएम और माइग्रेशन फ्रेमवर्क में स्कीमा-प्रति-किरायेदार पैटर्न के लिए समर्थन के विभिन्न स्तर होते हैं।

इसके लिए सर्वोत्तम:50-5,000 किरायेदारों के साथ मध्य-बाज़ार SaaS जहां आपको पंक्ति-स्तरीय सुरक्षा की तुलना में बेहतर अलगाव की आवश्यकता होती है, लेकिन अलग-अलग डेटाबेस की लागत को उचित नहीं ठहराया जा सकता है।

3. पंक्ति-स्तरीय सुरक्षा के साथ सब कुछ साझा किया

सभी किरायेदार एक ही टेबल साझा करते हैं। प्रत्येक तालिका पर एक tenant_id कॉलम यह पहचानता है कि प्रत्येक पंक्ति का मालिक कौन सा किरायेदार है। PostgreSQL में पंक्ति-स्तरीय सुरक्षा (आरएलएस) नीतियां लागू करती हैं कि क्वेरीज़ केवल वर्तमान किरायेदार से संबंधित पंक्तियों को देख सकती हैं।

यह B2B SaaS उत्पादों के लिए सबसे आम मॉडल है जो विनियमित उद्यमों को नहीं बेचे जाते हैं।

लाभ:

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

नुकसान:

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

इसके लिए सर्वोत्तम:बिजनेस स्तर के नीचे B2B SaaS। सैकड़ों या हजारों किरायेदारों वाले उत्पाद जहां बुनियादी ढांचे की लागत अनुपालन प्रमाणपत्रों से अधिक मायने रखती है।

तुलना तालिका

हमने साझा-डेटाबेस मल्टी-टेनेंसी पर ड्रॉपटैक्सी का निर्माण कैसे किया

जब हमने बनायाड्रॉपटैक्सी, भारतीय ऑपरेटरों के लिए एक बहु-किरायेदार टैक्सी बुकिंग SaaS, हमने tenant_id कॉलम के साथ साझा डेटाबेस मॉडल को चुना।

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

यहां बताया गया है कि वास्तुकला व्यवहार में कैसी दिखती है:

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

मिडलवेयर के माध्यम से ब्रांडेड उपडोमेन।प्रत्येक आने वाला HTTP अनुरोध एक होनो मिडलवेयर परत से टकराता है जो Host हेडर पढ़ता है। मिडलवेयर उस डोमेन से मेल खाने वाले किरायेदार को खोजने के लिए डेटाबेस से पूछताछ करता है (टर्सो पर ड्रिज़ल ओआरएम के माध्यम से)। यदि उसे कोई मेल मिलता है, तो किरायेदार का पूरा कॉन्फ़िगरेशन अनुरोध संदर्भ में लोड हो जाता है। यदि ऐसा नहीं होता है, तो अनुरोध को 404 मिलता है। एस्ट्रो एसएसआर परत तब किरायेदार की ब्रांडिंग का उपयोग करके पृष्ठों को प्रस्तुत करती है, इसलिए आगंतुकों को सामान्य प्लेटफ़ॉर्म के बजाय एक स्टैंडअलोन टैक्सी बुकिंग साइट दिखाई देती है।

सभी किरायेदारों के लिए एकल तैनाती।एक Fly.io मशीन पूरे प्लेटफ़ॉर्म को चलाती है। एक डेटाबेस. एक कोडबेस. प्रति-किरायेदार की एकमात्र लागत DNS कॉन्फ़िगरेशन और डेटाबेस में पंक्तियाँ हैं जो उनकी सेटिंग्स संग्रहीत करती हैं।

यह मॉडल काम करता है क्योंकि उत्पाद विनियमित उद्योगों को सेवा नहीं देता है, डेटा संवेदनशीलता कम है (बुकिंग विवरण, वित्तीय रिकॉर्ड नहीं), और प्राथमिक स्केलिंग चिंता प्रति-किरायेदार डेटा वॉल्यूम के बजाय किरायेदार गणना है।

बहु-किरायेदार प्रणालियों के लिए व्यावहारिक पैटर्न

चाहे आप कोई भी मॉडल चुनें, ये पैटर्न उत्पादन बहु-किरायेदार प्रणालियों में दिखाई देते हैं।

किरायेदार समाधान मिडलवेयर

किरायेदार समाधान आपके अनुरोध पाइपलाइन के किनारे पर एक बार होना चाहिए, और समाधान किरायेदार को पूरे अनुरोध जीवनचक्र के माध्यम से प्रसारित होना चाहिए। सामान्य समाधान रणनीतियाँ:

• उपडोमेन:acme.yourapp.com acme किरायेदार को हल करता है। Host हेडर से पार्स करें।
• कस्टम डोमेन:app.acme.com एक डोमेन लुकअप तालिका के माध्यम से किरायेदार को मैप करता है।
• पथ उपसर्ग:yourapp.com/acme/dashboard यूआरएल से किरायेदार को निकालता है। उत्पादन में कम आम, लेकिन विकास के दौरान उपयोगी।
• जेडब्ल्यूटी/एपीआई कुंजी:एपीआई-प्रथम उत्पादों के लिए, किरायेदार पहचानकर्ता प्रमाणीकरण टोकन में रहता है। मिडलवेयर टोकन को मान्य करता है और किरायेदार का दावा निकालता है।

हल किए गए किरायेदार को अनुरोध-स्कोप संदर्भ में संग्रहीत करें (होनो का c.set(), एक्सप्रेस का req.tenant, या गो में थ्रेड-स्थानीय चर)। किरायेदार को फिर से हल करने के लिए किसी डाउनस्ट्रीम कोड की आवश्यकता नहीं होनी चाहिए।

कनेक्शन पूलिंग

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

समाधान जो उत्पादन में काम करते हैं:

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

साझा-डेटाबेस मॉडल के लिए, एकल कनेक्शन पूल ठीक काम करता है। प्रत्येक कनेक्शन चेकआउट पर किरायेदार संदर्भ सत्र स्तर (आरएलएस के लिए SET app.current_tenant, स्कीमा पृथक्करण के लिए SET search_path) पर सेट हो जाता है।

किरायेदार-स्कोप्ड कैशिंग

आपकी कैश कुंजियों को टैनेंट उपसर्ग की आवश्यकता है। यदि आप "डैशबोर्ड डेटा" कुंजी को किसी किरायेदार तक सीमित किए बिना कैश करते हैं, तो आप किरायेदार ए के डैशबोर्ड डेटा को किरायेदार बी को प्रदान करेंगे। यह स्पष्ट लगता है, लेकिन यह उत्पादन में सबसे आम बहु-किरायेदारी बग है।

tenant:{tenant_id}:resource:{resource_type}:{resource_id} जैसे कुंजी प्रारूप का उपयोग करें। यदि आप रेडिस का उपयोग कर रहे हैं, तो छोटी तैनाती के लिए प्रति किरायेदार अलग रेडिस डेटाबेस (0-15 डिफ़ॉल्ट रूप से उपलब्ध हैं) या बड़े तैनाती के लिए कुंजी उपसर्ग पर विचार करें।

पृष्ठभूमि कार्य अलगाव

पृष्ठभूमि नौकरियों (ईमेल भेजना, रिपोर्ट तैयार करना, डेटा आयात) को किरायेदार संदर्भ को एनक्यू साइट से कार्यकर्ता तक प्रचारित करने की आवश्यकता होती है। जब आप किसी कार्य की कतार बनाते हैं, तो कार्य पेलोड में tenant_id शामिल करें। कार्यकर्ता को वही टैनेंट संदर्भ सेट करना चाहिए जो आपका HTTP मिडलवेयर कार्य को संसाधित करने से पहले प्रदान करता है।

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

बहु-किरायेदारी संस्करण के रूप में मल्टी-पोर्टल

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

यह एक उपयोगी पैटर्न है जब आपके "किरायेदार" अलग-अलग संगठन नहीं हैं बल्कि एक संगठन के भीतर अलग-अलग भूमिकाएँ निभाते हैं। बहु-किरायेदारी आदिम (स्कोप्ड डेटा एक्सेस, प्रति-भूमिका मिडलवेयर, संदर्भ प्रसार) समान रहते हैं।

निर्णय रूपरेखा: अपना मॉडल कैसे चुनें

सही मॉडल तीन चर पर निर्भर करता है: अनुपालन आवश्यकताएँ, अपेक्षित किरायेदार संख्या, और बुनियादी ढाँचा बजट।

अनुपालन से शुरुआत करें.यदि आपके ग्राहक विनियमित उद्योगों (वित्त, स्वास्थ्य सेवा, सरकार) में हैं, या यदि आपके अनुबंध में डेटा रेजिडेंसी खंड शामिल हैं, तो डेटाबेस-प्रति-किरायेदार सबसे सुरक्षित विकल्प है। लागत प्रीमियम उद्यम अनुबंधों में एक पंक्ति वस्तु है जिसके लिए आपके ग्राहक भुगतान करने की अपेक्षा करते हैं।

किरायेदारों की संख्या में कारक.यदि आप 100 से कम किरायेदारों की अपेक्षा करते हैं और प्रत्येक किरायेदार सार्थक राजस्व उत्पन्न करता है, तो डेटाबेस-प्रति-किरायेदार व्यवहार्य है। यदि आप PostgreSQL पर हैं और माइग्रेशन टूलिंग में निवेश कर सकते हैं, तो 100 और 5,000 के बीच स्कीमा पृथक्करण काम करता है। 5,000 से ऊपर, आरएलएस के साथ साझा टेबल व्यावहारिक विकल्प है। किरायेदारों की उच्च संख्या के कारण अन्य मॉडलों का बुनियादी ढाँचा अर्थशास्त्र ध्वस्त हो जाता है।

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

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

बचने योग्य सामान्य गलतियाँ

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

लघु संस्करण

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

अक्सर पूछे जाने वाले प्रश्नों