क्या मुझे बहु-क्लाइंट एप्लिकेशन के लिए एकल या एकाधिक डेटाबेस सेटअप का उपयोग करना चाहिए?

Question

मैं एक PHP अनुप्रयोग पर काम कर रहा हूं जो कंपनी वर्कफ़्लो और प्रोजेक्ट प्रबंधन को कम करने का इरादा रखता है, मान लें कि Basecamp और GoPlan जैसे कुछ कहें।

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

संभव विपक्ष मैं एक डेटाबेस का उपयोग कर के बारे में सोच सकते हैं:

• तानाना की कमी
• सुरक्षा समस्याओं

(हालांकि कीड़े वहाँ पहली जगह में नहीं होना चाहिए) क्या क्या इस पर आपके विचार हैं? क्या आपके पास कोई विचार है कि उपर्युक्त कंपनियों का चयन करने की सबसे अधिक संभावना क्या है?

Answer 1

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

इस तरह आप एक डेटाबेस में छोटे ग्राहकों का समूह और अलग-अलग सर्वरों पर बड़े समूह प्राप्त कर सकते हैं।

हालांकि रखरखाव के लिए एक महत्वपूर्ण कारक यह है कि आप स्कीमा को सभी डेटाबेस में समान रखते हैं। क्लाइंट विशिष्ट स्कीमा पेश किए बिना संस्करण को प्रबंधित करने के लिए पर्याप्त सिरदर्द होगा।

Answer 2

multitenancy के लिए, प्रदर्शन आम तौर पर अधिक संसाधनों आप किरायेदारों पर साझा करने के लिए प्रबंधन में वृद्धि होगी, तो अगर आप, एकल डाटाबेस के साथ जा सकते

http://en.wikipedia.org/wiki/Multitenancy

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

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

Answer 3

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

डेटाबेस बैकअप के बारे में सोचें। ग्राहक ए कहता है "कृपया मुझे मेरे डेटा की एक प्रति भेजें"। एक डेटाबेस को साझा करने के बजाय एक अलग डेटाबेस सेटअप में बहुत अधिक आसान है। एक ग्राहक को हटाने के बारे में सोचो; फिर, अलग डेटाबेस के साथ बहुत आसान है।

('बुनियादी ढांचे' भाग आटे का मुँह क्योंकि वहाँ क्या उदाहरण के लिए, एक 'सर्वर उदाहरण' बनाम 'एक डेटाबेस' का गठन किया के बारे में अलग डीबीएमएस के बीच प्रमुख अंतर हैं जोड़ें:। सवाल 'mysql' टैग है है, तो हो सकता है उन विचारों को पूरी तरह से प्रासंगिक नहीं हैं)

जोड़ें:। एक और मुद्दा - एक एकल डाटाबेस में एक से अधिक ग्राहकों के साथ, हर SQL क्वेरी सुनिश्चित करने के लिए है कि सही ग्राहक के लिए डेटा की जरूरत करने जा रहा है चुना। इसका मतलब है कि एसक्यूएल लिखना और पढ़ना कठिन होगा, और डीबीएमएस को डेटा प्रोसेसिंग पर कड़ी मेहनत करनी होगी, और इंडेक्स बड़ा होगा, और ... मैं वास्तव में प्रति अलग डेटाबेस के साथ जाऊंगा कई उद्देश्यों के लिए ग्राहक।

स्पष्ट रूप से, स्टैक ओवरफ्लो (उदाहरण के रूप में) में प्रति उपयोगकर्ता एक अलग डेटाबेस नहीं है; हम सभी एक ही डेटाबेस का उपयोग करते हैं। लेकिन अगर आप विभिन्न कंपनियों के लिए लेखांकन प्रणाली चला रहे थे, तो मुझे नहीं लगता कि यह डाटाबेस साझा करने के लिए स्वीकार्य होगा (कंपनियों, और संभवतः कानूनी लोगों के लिए नहीं)।

Answer 4

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

यह प्रकरण # 20 या # 21 में था (विवरण के लिए प्रतिलेखों की जांच करें)।

Answer 5

विचार करने का एक और मुद्दा यह है कि एक कंपनी के डेटा को किसी अन्य से अलग रखने के लिए आपके पास कानूनी दायित्व हो सकता है।

Answer 6

प्रति क्लाइंट डेटाबेस होने पर आम तौर पर स्केल नहीं होता है। MySQL (और शायद अन्य डेटाबेस) प्रति टेबल खोलने वाले संसाधन रखता है, यह एक उदाहरण पर 10k + टेबल पर खुद को उधार नहीं देता है, जो बड़े पैमाने पर बहुसंख्यक स्थिति में होता है।

बेशक, यदि आपके पास कोई अन्य समस्या है जो इस स्तर तक पहुंचने से पहले अन्य समस्याओं का कारण बनती है, तो यह प्रासंगिक नहीं हो सकता है।

इसके अतिरिक्त, एक बहु-किरायेदार आवेदन "sharding" अंततः करने के लिए सही काम होने की संभावना है क्योंकि आपका आवेदन बड़ा और बड़ा हो जाता है।

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

€ मैं इसकी गारंटी नहीं दे सकता।

Answer 7

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

1) डेटाबेस को इस तरह से डिज़ाइन करें कि इसे आसानी से विभाजित किया जा सके। उदाहरण के लिए, यदि ग्राहक डेटा साझा करने जा रहे हैं, तो सुनिश्चित करें कि डेटा प्रत्येक डेटाबेस में आसानी से दोहराया जाता है।

2) जब आपके पास केवल एक डेटाबेस है, तो सुनिश्चित करें कि इसका उपयोग किसी अन्य भौतिक सर्वर पर किया जा रहा है। एक विफलता की स्थिति में आप यातायात को इस अन्य सर्वर पर वापस कर सकते हैं और अभी भी आपका डेटा बरकरार है।

Answer 8

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

• प्रदर्शन प्रदर्शन के लिए, सभी के लिए डेटाबेस का उपयोग करें। कनेक्शन पूलिंग, साझा स्मृति, कैशिंग, आदि के बारे में सोचो

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

Answer 9

निम्नलिखित screencast बताता है कि यह salesforce.com पर कैसे किया जाता है। वे एक विशेष कॉलम OrgId के साथ एक डेटाबेस का उपयोग करते हैं जो प्रत्येक किरायेदार के डेटा की पहचान करता है। इसके लिए बहुत कुछ है इसलिए आपको इसे देखना चाहिए। मैं उनके दृष्टिकोण के साथ जाना होगा।

एमएसडीएन पर इसके बारे में एक और शानदार article है। यह गहराई से बताता है जब आपको साझा या पृथक दृष्टिकोण का उपयोग करना चाहिए। याद रखें कि आपके सभी किरायेदारों के लिए साझा डीबी होने के कुछ महत्वपूर्ण सुरक्षा प्रभाव हैं और यदि वे सभी डीबी ऑब्जेक्ट्स साझा करते हैं तो आप [पंक्ति स्तर की सुरक्षा] का उपयोग करना चाहेंगे - आपके द्वारा उपयोग किए जाने वाले डीबीएमएस के आधार पर (मुझे यकीन है कि यह संभव है एमएस एसक्यूएल सर्वर और ओरेकल, शायद आईबीएम डीबी 2 में भी)। आप समान परिणाम (विचार + ट्रिगर) प्राप्त करने के लिए row level security in mySQL जैसे चाल का उपयोग कर सकते हैं।

Answer 10

जब आप मल्टी-टेनेंट डेटाबेस डिज़ाइन कर रहे हैं, तो आप आम तौर पर तीन विकल्प हैं:

1. किरायेदार प्रति एक डेटाबेस है
2. किरायेदार प्रति एक स्कीमा
3. सभी किरायेदारों एक ही मेज साझा किया है (ओं)

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

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

• आप पैमाने के लिए निर्माण कर रहे हैं: सभी किरायेदारों एक ही तालिका (रों)
• का हिस्सा आप अलगाव के लिए बना रहे हैं तो है: किरायेदार

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

निर्णय उस प्राथमिक आयाम पर आता है जिसके लिए आप अपना डेटाबेस डिज़ाइन अनुकूलित कर रहे हैं। This article on designing your SaaS database for scale व्यापार-बंद के बारे में बात करता है और PostgreSQL के संदर्भ में सारांश प्रदान करता है।