साब्स आर्किटेक्चर न्यूबी

Question

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

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

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

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

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

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

Answer 1

अच्छे प्रश्न।

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

हम एक सास मॉडल का उपयोग करके भी अपना आवेदन प्रदान कर रहे हैं।

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

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

दूसरी ओर, हालांकि, इस समाधान ने मोटी क्लाइंट दृष्टिकोण को बनाए रखने और प्रबंधित करने की सभी समस्याओं को लाया जो आखिरकार हमें क्लाइंट, ब्राउज़र-आधारित दृष्टिकोण की ओर ले जाता है।

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

मुझे आशा है कि यह आपके लिए विचार के लिए कुछ भोजन प्रदान करेगा।

मैं भी इस प्रश्न में रूचि रखता हूं।

पोस्ट के लिए धन्यवाद।

-S