क्या बहु-किरायेदार डीबी में कई डेटाबेस या साझा टेबल हैं?

Question

एक बहु-किरायेदार डेटाबेस है:

• एक DB सर्वर जिसमें प्रत्येक ग्राहक / किरायेदार के लिए एक अलग (समान) डेटाबेस / स्कीमा है ;; या
• एक डीबी सर्वर जिसमें एक डेटाबेस / स्कीमा होता है जहां ग्राहक / किरायेदार एक ही टेबल के अंदर रिकॉर्ड साझा करते हैं?

उदाहरण के लिए, ऊपर विकल्प # 1 के तहत, मेरे पास एक MySQL सर्वर हो सकता है, कहते हैं mydb01.example.com, और इसके customer1अंदर एक डेटाबेस हो सकता है । यह customer1डेटाबेस कह सकता है, 10 तालिकाएँ जो उस विशेष ग्राहक के लिए मेरे आवेदन को शक्ति प्रदान करती हैं (ग्राहक # 1)। इसमें एक customer2समान 10 टेबल के साथ एक डेटाबेस भी हो सकता है, लेकिन केवल ग्राहक # 2 के डेटा के साथ। इसमें एक customer3डेटाबेस, एक customer4डेटाबेस और इतने पर हो सकता है।

ऊपर विकल्प # 2 में, केवल एक ही डेटाबेस / स्कीमा होगा, कहते हैं myapp_db, फिर से इसमें 10 तालिकाओं के साथ (ऊपर के समान वाले)। लेकिन यहां, सभी ग्राहकों के लिए डेटा उन 10 तालिकाओं के अंदर मौजूद है, और इसलिए वे तालिकाओं को "साझा" करते हैं। और एप्लिकेशन लेयर, लॉजिक और सिक्योरिटी कंट्रोल में जिन ग्राहकों के पास उन 10 टेबलों में कौन से रिकॉर्ड्स तक पहुंच है, और यह सुनिश्चित करने के लिए बहुत सावधानी बरती जाती है कि ग्राहक # 1 ऐप में कभी भी लॉग इन न करें और कस्टमर # 3 का डेटा आदि देखें।

इनमें से कौन सा प्रतिमान एक पारंपरिक "मल्टी-टेनेंट" डीबी का गठन करता है? और यदि नहीं, तो क्या कोई मुझे एक उदाहरण प्रदान कर सकता है (ऊपर वर्णित परिदृश्यों का उपयोग करके) एक बहु-किरायेदार डीबी क्या है?

Comments

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

— द्वैदबक

मल्टी-टेनेंसी

— जेएफओ

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

Answer 1

इनमें से कौन सा प्रतिमान एक पारंपरिक "मल्टी-टेनेंट" डीबी का गठन करता है

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

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

सटीक होने के लिए, गैर-बहु किरायेदार DB के साथ एक बहु-किरायेदार एप्लिकेशन का निर्माण करना संभव है, प्रति ग्राहक एक व्यक्तिगत DB उदाहरण प्रदान करता है। हालांकि, यह किसी भी DB संसाधनों को सीधे किरायेदारों के बीच साझा करने के लिए रोकता है, और आवेदन परत को सही किरायेदार को सही डेटाबेस से कनेक्ट करना सुनिश्चित करना है।

Comments

धन्यवाद @ डॉक ब्राउन (+1) लेकिन फिर, आपके पास संभवतः कोई भी डेटाबेस कैसे हो सकता है जो बहु-किरायेदार नहीं था ?

— स्माइब

@smeeb: मल्टी-टेनेंसी, विभिन्न किरायेदारों द्वारा उपयोग किए जाने वाले एप्लिकेशन की एक संपत्ति है, एप्लिकेशन के "डेटाबेस" के पीछे नहीं। बेशक, डीबी अवधारणा को यह संभव बनाने के लिए बहु किरायेदारी का समर्थन करने की आवश्यकता है।

— डॉक्टर ब्राउन

@smeeb: मान लीजिए कि आपके पास एक उपयोगकर्ता तालिका है जिसमें एक बाधा है कि उपयोगकर्ता नाम अद्वितीय है, अब एक किरायेदार का कोई कर्मचारी अब किसी उपयोगकर्ता नाम का उपयोग नहीं कर सकता है क्योंकि एक अन्य किरायेदार का काम करने वाला कोई व्यक्ति पहले से ही इसका उपयोग कर रहा है।

— रेमकोगर्लिच

@smeeb: यदि दो किरायेदारों की सेवा करने का एकमात्र तरीका दो अलग-अलग डेटाबेस पर दो अलग-अलग सर्वरों पर एक एप्लिकेशन को दो बार इंस्टॉल और रन करना है, तो मुझे लगता है कि कोई भी इस मल्टी-टेनेंसी को नहीं कहेगा।

— डॉक ब्राउन

मैं थोड़ी देर पहले Azure पर एक प्रस्तुति के लिए गया था जो कह रहा था कि MYOB ने Azure पर अपने क्लाउड समाधान को चलाया है, और प्रत्येक किरायेदार को अपना DB (और संभवतः वेब सर्वर भी) मिलता है; उनके पास बस कुछ महान स्वचालन उपकरण हैं, जिन्हें सैकड़ों DB उदाहरणों की आवश्यकता होती है। दूसरी ओर, संगठन है कि मैं वर्तमान में एक ही डेटाबेस से बाहर सैकड़ों ग्राहकों के लिए काम करता है, ग्राहकों के डेटा के अलगाव को लागू करने के लिए सॉफ्टवेयर में अभी काफी काम किया है। हमने एक हाइब्रिड पर भी विचार किया, जहां हमारे सबसे बड़े ग्राहकों को अपना डीबी मिलेगा, जबकि अन्य ने मूल साझा किया।

— डेविड केवेनी

Answer 2

Microsoft के अनुसार, इस शब्द के 3 संभावित अर्थ हैं (सभी किरायेदारों के लिए एक डेटाबेस, या प्रति किरायेदार एक डेटाबेसर)।

अपने उदाहरण का उपयोग करने के लिए, प्रत्येक ग्राहक स्वयं किरायेदार होगा।

1. एक डेटाबेस प्रति किरायेदार (ग्राहक)

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

2. एक साझा डेटाबेस, अलग स्कीमा।

   • प्रत्येक किरायेदार की अपनी स्कीमा होती है, और उनका डेटा उनकी अपनी तालिका में होता है।
   • पुनर्स्थापित करने में अधिक समय लग सकता है, क्योंकि हर कोई एक ही डेटाबेस में होता है, आप डेटाबेस को पहले के बैकअप में पुनर्स्थापित नहीं कर सकते (यह हर किरायेदारों के डेटा को वापस करेगा)। एक विकल्प एक नए डेटाबेस को पुनर्स्थापित करना और फिर केवल 1 किरायेदारों के डेटा को मर्ज / कॉपी करना है।

3. एक साझा डेटाबेस, साझा स्कीमा।

   • हर किरायेदारों का डेटा एक ही तालिका में है। यदि आप उदाहरण के लिए आदेशों को ट्रैक करते हैं, तो प्रत्येक किरायेदारों के आदेश "dbo.Orders" में स्थित होंगे।
   • प्रत्येक तालिका में एक स्तंभ द्वारा किरायेदारों के डेटा को अलग किया जाता है (यह टेनेंटआईड हो सकता है), जो पंक्ति के मालिक को दिखाता है।

प्रत्येक लेख के लिए पेशेवरों और विपक्ष हैं, इस लेख में अच्छी तरह से समझाया गया है: https://msdn.microsoft.com/en-us/library/aa479086.aspx

बोनस: आप इसे जीवित क्वार्टर (सकल सरलीकृत) के रूप में सोच सकते हैं।

1. हर किराएदार के पास अपना घर है। वे जो चाहें कर सकते हैं, और अगर यह जलता है, तो यह वास्तव में किसी और को प्रभावित नहीं करता है।

2. हर किरायेदार एक ही इमारत में है, लेकिन उसके पास खुद का अपार्टमेंट है।

3. हर कोई एक ही अपार्टमेंट में रहता है, और सभी सामान को एक चिपचिपा नोट के साथ चिह्नित किया जाता है जो यह बताता है कि इसका मालिक कौन है।

Comments

आपके उत्तर के लिए धन्यवाद। क्या आप कृपया अपना उत्तर थोड़ा विस्तृत कर सकते हैं। यह एक बेहतर जवाब पैदा करेगा।

— थॉमस जंक

आपका बोनस उदाहरण भयानक है @ imms90

— अरविन

Microsoft ने MSDN से आपके द्वारा लिंक किया गया पृष्ठ हटा दिया है। वेबैक मशीन अभी भी एक प्रति है।

— माइक शेरिल 'कैट रिकॉल'

एमएस से समान लेख (शायद वही जो स्थानांतरित हो गया है): docs.microsoft.com/en-us/azure/sql-database/…

— पियरे हेनरी