हालांकि कुछ कंपनियां निश्चित रूप से डरती हैं कि उनके डेटा से समझौता किया जा सकता है, इसलिए हम अन्य समाधानों का मूल्यांकन कर रहे हैं।
यह दुर्भाग्यपूर्ण है, क्योंकि ग्राहकों को कभी-कभी यह गलतफहमी हो जाती है कि केवल शारीरिक अलगाव ही पर्याप्त सुरक्षा प्रदान कर सकता है।
एक दिलचस्प MSDN लेख है, जिसका शीर्षक है मल्टी-टेनेंट डेटा आर्किटेक्चर , जिसे आप जांचना चाह सकते हैं। इस तरह लेखकों ने साझा दृष्टिकोण के प्रति गलत धारणा को संबोधित किया:
<ब्लॉकक्वॉट>एक आम गलत धारणा यह मानती है कि केवल शारीरिक अलगाव ही उचित स्तर की सुरक्षा प्रदान कर सकता है। वास्तव में, साझा दृष्टिकोण का उपयोग करके संग्रहीत डेटा भी मजबूत डेटा सुरक्षा प्रदान कर सकता है, लेकिन इसके लिए अधिक परिष्कृत डिज़ाइन पैटर्न के उपयोग की आवश्यकता होती है।
तकनीकी और व्यावसायिक विचारों के लिए, लेख एक संक्षिप्त विश्लेषण करता है जहां एक निश्चित दृष्टिकोण दूसरे की तुलना में अधिक उपयुक्त हो सकता है:
<ब्लॉकक्वॉट>किरायेदारों की संख्या, प्रकृति और ज़रूरतें जो आप सभी की सेवा करने की उम्मीद करते हैं, आपके डेटा आर्किटेक्चर निर्णय को अलग-अलग तरीकों से प्रभावित करते हैं। निम्नलिखित में से कुछ प्रश्न आपको अधिक पृथक दृष्टिकोण की ओर ले जा सकते हैं, जबकि अन्य आपको अधिक साझा दृष्टिकोण की ओर ले जा सकते हैं।
-
आप कितने संभावित किरायेदारों को लक्षित करने की अपेक्षा करते हैं? आप अधिकार के साथ संभावित उपयोग का अनुमान लगाने में सक्षम नहीं हो सकते हैं, लेकिन परिमाण के आदेशों के संदर्भ में सोचें:क्या आप सैकड़ों किरायेदारों के लिए एक आवेदन बना रहे हैं? हजारों? दसियों हजारों की? अधिक? जितना बड़ा आप अपने किरायेदार आधार की अपेक्षा करते हैं, उतनी ही अधिक संभावना है कि आप अधिक साझा दृष्टिकोण पर विचार करना चाहेंगे।
-
आप औसत टैनेंट के डेटा पर कितने संग्रहण स्थान की अपेक्षा करते हैं? यदि आप कुछ या सभी टैनेंट से बहुत बड़ी मात्रा में डेटा संग्रहीत करने की अपेक्षा करते हैं, तो ये अलग-अलग-डेटाबेस दृष्टिकोण शायद सबसे अच्छा है। (वास्तव में, डेटा संग्रहण आवश्यकताएँ आपको अलग-अलग डेटाबेस मॉडल को अपनाने के लिए मजबूर कर सकती हैं। यदि ऐसा है, तो बाद में अलग-अलग डेटाबेस दृष्टिकोण पर जाने की तुलना में एप्लिकेशन को शुरुआत से इस तरह से डिज़ाइन करना बहुत आसान होगा।)
-
आप औसत टैनेंट से कितने समवर्ती अंतिम उपयोगकर्ताओं की अपेक्षा करते हैं? संख्या जितनी बड़ी होगी, अंतिम-उपयोगकर्ता आवश्यकताओं को पूरा करने के लिए उतना ही अधिक उपयुक्त होगा।
-
क्या आप किसी प्रति-किरायेदार मूल्य-वर्धित सेवाओं की पेशकश करने की अपेक्षा करते हैं, जैसे प्रति-किरायेदार बैकअप और पुनर्स्थापना क्षमता? ऐसी सेवाओं को एक अलग दृष्टिकोण के माध्यम से पेश करना आसान होता है।
अद्यतन करें: आगे किरायेदारों की अपेक्षित संख्या के बारे में अद्यतन करने के लिए।
किरायेदारों की अपेक्षित संख्या (10k) को बहु-डेटाबेस दृष्टिकोण को बाहर करना चाहिए, अधिकांश के लिए, यदि सभी परिदृश्य नहीं हैं। मुझे नहीं लगता कि आप 10,000 डेटाबेस इंस्टेंस को बनाए रखने, और हर दिन सैकड़ों नए इंस्टेंस बनाने के विचार को पसंद करेंगे।
अकेले उस पैरामीटर से, ऐसा लगता है कि साझा-डेटाबेस, एकल-स्कीमा दृष्टिकोण सबसे उपयुक्त है। तथ्य यह है कि आप प्रति किरायेदार लगभग 50 एमबी संग्रहित करेंगे, और कोई प्रति-किरायेदार ऐड-ऑन नहीं होगा, इस दृष्टिकोण को और भी उपयुक्त बनाता है।
ऊपर उद्धृत एमएसडीएन लेख में तीन सुरक्षा पैटर्न का उल्लेख किया गया है जो साझा-डेटाबेस दृष्टिकोण के लिए सुरक्षा विचारों से निपटते हैं:
जब आप अपने एप्लिकेशन के डेटा सुरक्षा उपायों के बारे में आश्वस्त होते हैं, तो आप अपने ग्राहकों को एक सेवा स्तर अनुबंध प्रदान करने में सक्षम होंगे। जो मजबूत डेटा सुरक्षा गारंटी प्रदान करता है। अपने SLA में, गारंटी के अलावा, आप उन उपायों का भी वर्णन कर सकते हैं जो आप यह सुनिश्चित करने के लिए करेंगे कि डेटा से समझौता न हो।
अद्यतन 2: जाहिरा तौर पर Microsoft लोगों ने इस विषय के संबंध में एक नया लेख बनाया / बनाया, मूल लिंक चला गया है और यह नया है:मल्टी-टेनेंट SaaS डेटाबेस टेनेंसी पैटर्न (शे केर को प्रणाम)
