सॉफ्टवेयर आर्किटेक्चर और डेटाबेस डिज़ाइन: प्रत्येक कंपनी के लिए एक डेटाबेस/वेब एप्लिकेशन या सभी कंपनियों के लिए एक डेटाबेस/वेब एप्लिकेशन?

Question

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

मेरा पहला सवाल यह है: पक्ष-विपक्ष निम्नलिखित विकल्पों को देखते हुए क्या कर रहे हैं:

• ए कई ग्राहकों को एक ही डेटाबेस में की जानकारी प्रबंधित;
• बी डेटाबेस प्रति एक ग्राहक जानकारी प्रबंधित करें; इसलिए प्रत्येक ग्राहक के पास का अपना डेटाबेस होगा;

मेरा दूसरा प्रश्न है: तैनाती के निम्नलिखित तरीकों को पेशेवरों और विपक्ष क्या हैं?

• ए प्रत्येक ग्राहक को अपना सर्वर (नोड) मिलता है;
• बी कई वेबसाइटों के साथ एक शक्तिशाली सर्वर के साथ बड़े RAID ड्राइव का उपयोग करें;

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

टेक्नोलॉजीज का प्रयोग किया:

• डेटाबेस: एमएस एसक्यूएल
• प्लेटफार्म: ASP.NET
• भाषा: सी #

कोई टिप्पणी या सुझाव बहुत स्वागत है,

धन्यवाद ,

कुलेन

Answer 1

मैं प्रत्येक ग्राहक को अपना डेटाबेस देने की अनुशंसा नहीं करता। मैंने अपने वर्तमान आवेदन के लिए ऐसा करने की योजना बनाई और एक डेटाबेस में बात की गई। अच्छी बात है, क्योंकि अब हमारे पास 300 ग्राहक हैं। क्या आप 300 डेटाबेस प्रबंधित करने की कल्पना कर सकते हैं? हर बार जब आप अपग्रेड करते हैं तो प्रत्येक को अपडेट कर रहे हैं? यह सुनिश्चित करना कि प्रत्येक अद्यतित है, आदि

अस्वीकरण: वास्तव में हमारे पास वास्तव में कई डेटाबेस हैं। कुछ बहुत बड़े ग्राहकों के पास अपना स्वयं का डेटाबेस होता है और अन्य शेष लोगों को साझा करते हैं। मुझे लगता है कि शायद 7 डेटाबेस।

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

Answer 2

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

व्यापार सॉफ्टवेयर उद्योग में समग्र प्रवृत्ति अभी आपके आवेदन को अपने सर्वर पर केंद्रीकृत कर रही है और सॉफ्टवेयर को आपके ग्राहकों के लिए सेवा प्रदान कर रही है।

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

यदि आप हार्डवेयर लागतों के बारे में चिंतित हैं तो आप क्लाउड होस्टिंग सेवाओं जैसे Amazon s2, Google App Engine, और Microsoft Azure पर देख सकते हैं।

Answer 3

आप वास्तव में समीक्षा करने के लिए निम्नलिखित हैं:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

यह एक कागज है कि मल्टी-टेनेंट वास्तुकला के लिए अलग अलग डिजाइन परिदृश्यों के ऊपर जाता है है। उचित डेटा विभाजन, सुरक्षा और कौशल सेट से विचार करने के लिए कई चीजें हैं।

* नए लिंक

Answer 4

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

अपने एप्लिकेशन को डिज़ाइन करें ताकि एक ही डेटाबेस में कई ग्राहक मौजूद हो सकें। (यानी क्लाइंट डेटा के बीच अलगाव की एक परत बनाएं)। फिर सभी को एक डेटाबेस में रहने की योजना बनाएं।

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

Answer 5

मुझे लगभग 40 ग्राहकों के साथ एकल-किरायेदार डिज़ाइन चलाने का अनुभव है। प्रत्येक क्लाइंट में अलग ASP.NET एप्लिकेशन फ़ाइलें और SQL सर्वर डेटाबेस होता है। प्रत्येक क्लाइंट के लिए एप्लिकेशन कोर बाइनरी समान होती है, लेकिन ग्राहकों के पास कस्टम मॉड्यूल भी होते हैं।

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

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

पेशेवरों

• व्यापार सॉफ्टवेयर के लिए अच्छा है। अनुकूलित करने के लिए आसान है, लेकिन आप अभी भी पुन: उपयोग
• से लाभ प्राप्त कर हम एक एसक्यूएल एक्सप्रेस उदाहरणों प्रति सर्वर जब तक प्रत्येक डेटाबेस है 4GB के तहत
• जुदाई बहुत से ग्राहकों के बीच का उपयोग कर सकते हैं।उदाहरण के लिए, प्रत्येक ग्राहक के लिए एक अलग आईआईएस अनुप्रयोग पूल अधिक सिस्टम स्तर, नहीं पूरी तरह से आवेदन स्तर पर
• सुरक्षा हो सकता है
• एकल ग्राहक के सॉफ्टवेयर संस्करण लंबी अवधि के
• बग्स आमतौर पर हर ग्राहक पर सतह नहीं है के लिए जमे हुए किया जा सकता है
• वास्तविक सुविधाओं की मांग के आधार पर नई सुविधाओं को अच्छी तरह से उगाया जा सकता है। एक सुविधा के लिए सबसे पहले ग्राहकों को मूल रूप से बीटा परीक्षकों
  • उपभोक्ता सॉफ्टवेयर के लिए बुरा हैं

  विपक्ष।

• रखरखाव श्रम-गहन है:
• गुणवत्ता नियंत्रण थोड़ा कठिन होने पर गुणवत्ता नियंत्रण कठिन होता है। अपडेट के बाद अप्रत्याशित परेशानी सतह

Answer 6

प्रदर्शन और आदि अलग-अलग, क्या यह अलग-अलग डेटाबेस प्रदान करने के लिए आपके ग्राहक की सर्वोत्तम सेवा प्रदान करता है? क्या यह सॉफ़्टवेयर मौजूद है या आपकी कंपनी और लाइसेंस के बिना उपयोग किया जा सकता है?

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

सुरक्षा भी एक और चिंता है। एक डेटाबेस के साथ विफलता का एक बिंदु है और यदि एक ग्राहक से समझौता हो जाता है और आपके कोड में एक बग है, तो आपके सभी ग्राहक संभावित रूप से सामने आते हैं।

अनुप्रयोगों कभी अनुकूलित मिलेगा, और यदि ऐसा है तो होगा एक एकल डाटाबेस के कारण समस्याएं आती?