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


20

हमारे पास कई ग्राहक हैं, जिनकी प्रणाली कुछ कार्यक्षमता साझा करती है, लेकिन इनमें काफी विविधता भी है। ग्राहकों की संख्या बढ़ रही है - हमेशा एक स्वस्थ चीज! - और उनके व्यवसायों के बीच विविधता भी बढ़ रही है।

वर्तमान में एक ASP.Net (वेब ​​फ़ॉर्म) वेब साइट (वेब ​​प्रोजेक्ट के विपरीत) है, जिसमें प्रत्येक किरायेदार के लिए उप-फ़ोल्डर हैं, उस किरायेदार के गैर-मानक पृष्ठों के साथ। एक अलग मॉडल प्रोजेक्ट है, जो डेटाबेस एक्सेस और बिजनेस लॉजिक से संबंधित है।

जो बेहतर है - और सबसे महत्वपूर्ण बात यह है कि क्यों - (ए) प्रति ग्राहक 1 डेटाबेस के साथ, केवल उस ग्राहक से जुड़ी सुविधाओं के साथ; या (बी) सभी ग्राहकों द्वारा साझा किया गया एक एकल डेटाबेस, जहां केवल एक ही ग्राहक द्वारा तालिकाओं का एक सबसेट उपयोग किया जाता है।

व्यवसाय के भीतर मुख्य चिंताएं खत्म हो गई हैं:

  • कई परिसंपत्तियों का रखरखाव - बैकअप, संस्करण नियंत्रण और पसंद
  • जितना संभव हो उतना फिर से उपयोग को बढ़ावा देना

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


क्या ऐसा कोई मौका है, जो Azure जैसे PaaS क्लाउड वातावरण में चला जाएगा? यदि हां, तो आप पर्यावरण के लिए सर्वोत्तम प्रथाओं पर भी विचार करना चाहेंगे। पिछली बार जब मैंने देखा, तो एमएस ने एज़्योर पर मल्टीटैनेंट सॉफ्टवेयर के लिए कई डेटाबेस की सिफारिश की थी।
हार्पर शेल्बी

पूछने के लिए धन्यवाद। मैं इसी तरह की बातें सोच रहा था, लेकिन आप के रूप में सवाल के रूप में प्रारूप में सक्षम नहीं किया गया है।
मैथअटैक

आपको आयेंडे की बहु-टेनेंसी ब्लॉग श्रृंखला पढ़नी चाहिए। वह बहु बनाम एकल डेटाबेस के बारे में कुछ बहुत अच्छे बिंदु बनाता है।
सेबज़्ज़

जवाबों:


12

यहां अन्य स्रोतों से शोध पर प्रकाश डाला गया है (मूल रूप से प्रश्न के संशोधन 2 से ):


10

यदि आप SQL सर्वर का उपयोग कर रहे हैं, तो एक डेटाबेस का उपयोग करें लेकिन स्कीमा का उपयोग करें। सामान के लिए dbo का उपयोग करें जो सभी ग्राहकों के लिए सामान्य है और प्रत्येक क्लाइंट के लिए एक स्कीमा बनाएं और उस क्लाइंट से उपयोगकर्ताओं के लिए डिफ़ॉल्ट स्कीमा बनाएं। अब आपके पास dbo स्कीमा में एक सामान्य ऑब्जेक्ट (एक getBudget proc कह सकते हैं) और एक ही नाम के साथ उनके स्कीमा में क्लाइंट के लिए एक कस्टमाइज़ किया जा सकता है।


+1 यह भी आप MSDTC कॉन्फ़िगर और संबद्ध भूमि के ऊपर (दो चरण प्रतिबद्ध) पर लेने के लिए होने से बचने के लिए अनुमति देगा
ब्रायन

और उम्मीद है कि आप CustomField30 के माध्यम से CustomField1 जैसे स्तंभो होने और / या बजट, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName, आदि जैसे तालिकाओं के जाल से खुद से बचने
jfrankcarr

एक मौजूदा डेटा एक्सेस लेयर है जो बहुत सी संग्रहित प्रक्रियाओं का उपयोग करती है - 190 टेबल, 5 कोड-जनरेट की गई प्रक्रियाएँ, कुछ कस्टम वाले - जबकि मध्यम अवधि का लक्ष्य एंटिटी फ्रेमवर्क को शुरू करना है, क्या संग्रहीत को दोहराने की आवश्यकता होगी? प्रत्येक स्कीमा के लिए प्रक्रियाएं?
रिचर्ड डब्ल्यू 1001

@ रिचर्ड डब्ल्यू 1001: निर्भर करता है। जेनेरिक बनाने के लिए आप सपा में डायनामिक एसक्यूएल कर सकते हैं, लेकिन यह निश्चित रूप से उन पर निर्भर करता है, जिसमें कम से कम कुछ समान संरचना हो। गतिशील एसक्यूएल के लिए एक संभावित विकल्प, समानार्थक होगा , दुर्भाग्य से, जैसा कि मैं उन्हें समझता हूं, वे सिस्टम चौड़ा हैं और लेनदेन के भीतर निहित नहीं हैं, इसलिए विभिन्न मूल्यों के साथ समवर्ती उपयोग के लिए उपयुक्त नहीं है।
जमरनो

यदि हम EF कोड का उपयोग करते हुए कई स्कीमाओं का उपयोग करते हैं, तो सिस्टम के लाइव होने के बाद सभी स्कीमाओं को नवीनतम संस्करण में स्थानांतरित करना संभव होगा?
यशवित

4

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

एकल डेटाबेस सिस्टम सर्वश्रेष्ठ हैं जब विभिन्न ग्राहकों के बीच परिवर्तन केवल कॉन्फ़िगरेशन हैं, लेकिन प्रत्येक ग्राहक के लिए अतिरिक्त सुविधाएँ नहीं हैं।


आपका सुझाव क्या होगा कि कम से कम दर्द के साथ सामान्य कार्यक्षमता का प्रबंधन कैसे करें?
रिचर्ड डब्ल्यू 1001

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

3

आप कुछ चिंताओं को याद कर रहे हैं। समस्याएं विकास के साथ आएंगी। यदि आप मान सकते हैं कि किसी दिन आप एक डीबी सर्वर से बड़ा हो जाएगा - एक जटिल डेटाबेस निश्चित रूप से आपको सिरदर्द पैदा करेगा। जब तक आप पहले से आर्किटेक्चर में निवेश नहीं करेंगे। लेकिन यह भी महंगा कदम है)

तो, बस यह मत भूलो, कि यह दोनों कई बार सस्ता है और कई बार कुछ अलग-अलग डेटाबेस को स्केल करना आसान है, विशाल लोगों की तुलना में)


क्या आपके पास कोई डेटा है जो स्केलिंग की आसानी की पुष्टि करता है? यदि हां, तो यह बहुत ही सम्मोहक मामला होगा। क्या आप अन्य लापता चिंताओं के बारे में विस्तार से बता सकते हैं? मैं दोनों पक्षों पर यथासंभव तर्क वितर्क करने की कोशिश कर रहा हूं।
रिचर्ड डब्ल्यू 1001

1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.