एक मंच डिजाइनिंग: एक डेटाबेस या कई डेटाबेस?

Question

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

हमारे द्वारा पहले से विचार किए गए प्रत्येक दृष्टिकोण के कुछ फायदे शामिल हैं:

एकल डेटाबेस

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

एकाधिक डेटाबेस

• रखरखाव कार्य, हार्डवेयर समस्याएं, सुरक्षा उल्लंघनों और इसके बाद के संस्करण पूरे मंच को प्रभावित नहीं करते हैं
• प्रत्येक डेटाबेस को अलग हार्डवेयर पर मान लिया जाए, तो कई मशीनों को स्केल करने से एक बड़े पैमाने पर स्केलिंग की तुलना में अधिक प्रदर्शन लाभ मिलते हैं

एक परिचालन दृष्टिकोण से, क्या यह अधिक फायदेमंद है कि इस प्लेटफ़ॉर्म में प्रत्येक सेवा को अपना डेटाबेस मिलता है, या कि वे सभी एक ही डेटाबेस में जाते हैं? इस प्रश्न के उत्तर के लिए कौन से प्रमुख कारक सूचित करते हैं?

Comments

आपने आखिर क्या चुना?

— फ्रैंक विग्गियो

@ याकूबसिनार - यह अब से कुछ समय पहले है, लेकिन हमने कई डेटाबेस के साथ जाना समाप्त कर दिया है।

— निक चामास

स्कीमा परिवर्तन अधिक कठिन हैं या नहीं? मान लीजिए कि आपको हर डेटाबेस के स्कीमा को अपडेट करना है।

— फ्रैंक विजागियो

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

— निक चामास

मुझे पता है कि यह एक समय हो गया है, लेकिन क्या आपको उन विभिन्न डेटाबेस को साझा करने का मन है जिन्हें आपने चुना है और इसका कारण है?

— azngunit81

Answer 1

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

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

मैं ऐसी HighScalability.com जैसी साइटों को पढ़ने की सलाह दूंगा, जो कभी न भूलने वाली प्रकार की वेबसाइटों द्वारा अपनाए गए आर्किटेक्चर में खुदाई करती हैं। मेरे पसंदीदा में से एक नेटफ्लिक्स कैओस बंदर की कहानी थी जिसका उल्लेख कोडिंग हॉरर पर किया गया था ।

अपने प्रश्न के कुछ बिंदुओं को संबोधित करते हुए:

एक आपदा की स्थिति में, प्लेटफॉर्म को एक सुसंगत स्थिति में बहाल करना आसान है।

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

कई सेवाओं द्वारा संदर्भित डेटा के लिए, एक सेवा द्वारा कैश किए गए डेटा का उपयोग दूसरी सेवा द्वारा जल्द ही किए जाने की संभावना है।

वितरित कैश समाधान (मेमेकटेड एट अल) यहां मदद कर सकता है लेकिन आप सेवा स्वतंत्रता सिद्धांतों का उल्लंघन करेंगे। यह दो सेवाओं को सीधे एक-दूसरे के साथ संवाद करने, या बदतर सेवा सेवा वाले अनमोल डेटा स्टोर के साथ तुलना करना होगा, सेवा इंटरफ़ेस को पूरी तरह से दरकिनार करना। अनिवार्य रूप से डेटा संबंधित होगा और कॉलिंग प्लेटफ़ॉर्म द्वारा सेवाओं के बीच सौंप दिया जाएगा, मुश्किल फैसले यह तय करते हैं कि कौन सी सेवा डेटा के किस टुकड़े के मालिक होगी। अधिक सामान्य SOA समस्याओं के साथ मदद करने के लिए StackOverflow या Programmers साइट्स को बेहतर तरीके से रखा जा सकता है।

प्रत्येक डेटाबेस को अलग हार्डवेयर पर माना जाता है, और अधिक प्रदर्शन लाभ देता है।

निश्चित रूप से यह एकल मशीन को स्केल करने की तुलना में कई निम्न विशेष मशीनों के पैमाने पर सस्ता हो सकता है। हालाँकि, कम हार्डवेयर लागत स्वामित्व की कुल लागत में बौनी हो सकती है, जब अतिरिक्त विकास के प्रयास और परिचालन जटिलता की नरम लागत में फैक्टर होता है।

यदि यह SOA नहीं है और आपके पास सिर्फ एक मामला है, जहां इस प्लेटफॉर्म की घटक सेवाएं विभिन्न टीमों / आपूर्तिकर्ताओं द्वारा लॉजिस्टिक कारणों से बनाई जा रही हैं, तो एक ही डेटाबेस से चिपके रहते हैं और पूरी तरह से सब कुछ अनदेखा कर देते हैं! :)

Comments

वितरित कैश समाधान के बारे में अच्छी बात है। SAN या डेटाबेस स्तर पर कैशिंग के साथ, हालाँकि, यह कोई समस्या नहीं है। वहाँ आप अपनी तैनाती टोपोलॉजी (यानी अलग-अलग सेवाएं सिर्फ एक ही हार्डवेयर साझा करने के लिए) के कारण कैशिंग लाभ प्राप्त कर रहे हैं, न कि सेवाओं के बीच सीधे संचार के कारण के रूप में।

— निक चामास