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