database - घटक - संबंधपरक डेटाबेस प्रबंधन प्रणाली




प्रत्येक ग्राहक के लिए एक डेटाबेस का उपयोग करने के क्या फायदे हैं? (7)

"डेटाबेस" के कुछ अर्थ हैं

  • हार्डवेयर बॉक्स
  • चल रहे सॉफ़्टवेयर (उदाहरण के लिए "ऑरैकल")
  • डेटा फ़ाइलों का विशेष सेट
  • विशेष लॉगिन या स्कीमा

ऐसा लगता है कि जोएल का मतलब निम्न परतों में से एक है। इस मामले में, यह केवल सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन का मामला है ... उदाहरण के लिए, आपको सुरक्षा बग को ठीक करने के लिए 1000 सॉफ़्टवेयर सर्वर पैच करने की आवश्यकता नहीं है।

मुझे लगता है कि यह एक अच्छा विचार है, ताकि एक सॉफ्टवेयर बग ग्राहकों में जानकारी रिसाव न करे। इस मामले की कल्पना एक गलती के साथ करें जहां खंड ने मुझे अपना ग्राहक डेटा और साथ ही अपना खुद का दिखाया।

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

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

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

मैंने लोगों को उद्धृत किया है कि डेटाबेस बड़ी संख्या में रिकॉर्ड्स के साथ धीमा हो जाते हैं, लेकिन कुछ योग्यता वाले किसी भी रिलेशनल डेटाबेस में यह समस्या नहीं होगी - खासकर अगर उचित इंडेक्स और चाबियाँ उपयोग की जाती हैं।

किसी इनपुट की काफी सराहना की जाती है!


अनुमापकता। सुरक्षा। हमारी कंपनी प्रति ग्राहक दृष्टिकोण 1 डीबी का भी उपयोग करती है। यह कोड को बनाए रखने के लिए थोड़ा आसान बनाता है।


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


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

यहां इस सटीक विषय पर एक लेख दिया गया है (हां, यह एमएसडीएन है, लेकिन यह एक तकनीकी स्वतंत्र लेख है): http://msdn.microsoft.com/en-us/library/aa479086.aspx

बहु-किरायेदारी की एक और चर्चा के रूप में यह आपके डेटा मॉडल से संबंधित है: http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx भौतिक- डेटा- मॉडल.एएसपीएक्स


मान लें कि सभी क्लाइंट को एक डेटाबेस में स्टोर करने के लिए कोई स्केलिंग जुर्माना नहीं है; अधिकांश लोगों के लिए, और अच्छी तरह से कॉन्फ़िगर किए गए डेटाबेस / प्रश्नों के लिए, यह इन दिनों काफी सही होगा। यदि आप इन लोगों में से एक नहीं हैं, तो, एक डेटाबेस का लाभ स्पष्ट है।

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

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

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

आपको आसान संस्करण मिल रहा है - यदि कोई क्लाइंट सॉफ़्टवेयर संस्करण 1.0 पर रहना चाहता है, और दूसरा 2.0 चाहता है, जहां 1.0 और 2.0 विभिन्न डेटाबेस स्कीमा का उपयोग करते हैं, तो कोई समस्या नहीं है - आप उन्हें एक डेटाबेस से बाहर खींचने के बिना माइग्रेट कर सकते हैं।

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


मैं यहां इस शब्द को बहु-किरायेदार शब्द शामिल करने के लिए जोड़ रहा हूं। मैं क्वेरी के रूप में "multitenant" का उपयोग करके, यह खोज रहा था, और यह प्रकट नहीं हुआ था।


स्वास्थ्य देखभाल जैसे विनियमित उद्योगों में यह प्रति ग्राहक एक डेटाबेस की आवश्यकता हो सकती है, संभवतः एक अलग डेटाबेस सर्वर भी।

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

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

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







multi-tenant