मल्टीटेनेंट बनाम एकाधिक डीबी

Question

मैं एक कस्टम सीआरएम समाधान विकसित कर रहा हूं जिसे वेब/सास मॉडल के माध्यम से बेचा जाएगा। मैं इस समाधान का उपयोग कर दसियों या सैकड़ों ग्राहकों की उम्मीद करता हूं। मैं एमएस एसक्यूएल का उपयोग डीबी इंजन के रूप में करूँगा।

विकल्प 1 में एक एकल डीबी होना है, और टेबल पर एक TenantId कॉलम, एक उपयुक्त अनुक्रमणिका शामिल है और प्रत्येक डीबी एक्सेस पर 'tenantId = {...}' का उपयोग करें।

विकल्प 2 प्रत्येक ग्राहक के लिए व्यक्तिगत डीबी होना है, TenantId और जहां खंडों की आवश्यकता से परहेज करना है।

मुझे उम्मीद है कि प्रत्येक ग्राहक के पास लाखों रिकॉर्ड होंगे, लाखों नहीं।

जैसा कि मैंने इसे देखा, वहां डेटा पेजों की कुल संख्या होगी, जो भी विकल्प मैं जाता हूं। निर्णय इस बात पर केंद्रित लगता है कि एसक्यूएल एकाधिक डीबी के प्रबंधन में बेहतर है, या TenantId और अनुक्रमणिका के साथ एक डीबी बेहतर है। प्रारंभ में समाधान एक डीबी सर्वर पर चलाएगा, लेकिन अंत में SAN में स्थानांतरित हो जाएगा।

क्या किसी के पास इस पर कोई विचार है?

Answer 1

Multi-Tenant Data Architecture शीर्षक वाला एक दिलचस्प एमएसडीएन आलेख है, जिसे आप देखना चाहते हैं।

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

• कितने भावी किरायेदारों आप लक्षित करना करते हैं? प्राधिकरण के साथ संभावित उपयोग का आकलन करने में सक्षम होने के करीब हो सकता है, लेकिन परिमाण के आदेशों के संदर्भ में सोचें: क्या आप सैकड़ों किरायेदारों के लिए आवेदन बना रहे हैं? हजारों? हजारों में से ? अधिक? जितना बड़ा आप अपने किरायेदार आधार की अपेक्षा करते हैं, अधिक संभावना है कि आप पर अधिक साझा दृष्टिकोण पर विचार करना चाहेंगे।

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

• कितने समवर्ती अंत उपयोगकर्ताओं आप औसत किरायेदार का समर्थन करने की उम्मीद करते हैं? जितना बड़ा नंबर, अधिक पृथक दृष्टिकोण उपयुक्त उपयोगकर्ता आवश्यकताओं को पूरा करने के लिए होगा।

• आप की पेशकश ऐसे प्रति-किरायेदार बैकअप के रूप में किसी भी प्रति-किरायेदार वैल्यू-एडेड सेवाएं, और क्षमता को बहाल करने की उम्मीद करते हैं? एक और पृथक दृष्टिकोण के माध्यम से ऑफ़र करने के लिए ऐसी सेवाएं आसान हैं।

ध्यान दें कि "साझा दृष्टिकोण" विकल्प 1, और "पृथक दृष्टिकोण" है आपके मामले में, विकल्प 2 है। जब आप पहले दो बिंदुओं की बात करते हैं तो आप किसी भी तरफ पक्षपात नहीं कर रहे हैं, इसलिए मुझे लगता है कि मैं पिछले दो बिंदुओं पर अपने फैसले का आधार रखूंगा।

Answer 2

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

एक डीबी साझा करने का एकमात्र कारण मैं देखता हूं कि आपके पास बहुत अधिक ग्राहक हैं और प्रति ग्राहक पंक्तियों की बहुत कम संख्या है।