शार्पिंग के साथ गेटा यह है कि एप्लिकेशन को यह जानना होगा कि किस शार्द को क्वेरी करनी है। आम तौर पर, यह क्लाइंट की तरह कुछ पर तेज करके किया जाता है। मैं अपने उत्तर के रूप में उपयोग करने के लिए अपने पुराने ब्लॉग पोस्ट में से एक को अनुकूलित करूँगा ।
जब आप बहुत सारे क्लाइंट के लिए एप्लिकेशन बना रहे हैं, तो डेटाबेस को डिज़ाइन करने के दो सामान्य तरीके हैं:
- विकल्प A: सभी क्लाइंट को एक ही डेटाबेस में रखें
- विकल्प 2: प्रति ग्राहक एक डेटाबेस बनाएँ
एक ही डेटाबेस में सभी ग्राहकों को लाना
यह सरल है: स्कीमा के शीर्ष पर केवल एक ग्राहक तालिका जोड़ें, यह सुनिश्चित करने के लिए एक ग्राहक तालिका जोड़ें कि लोग केवल अपना डेटा देखें, और हम चले जाएं।
इस दृष्टिकोण के लाभ:
आसान स्कीमा प्रबंधन। जब डेवलपर्स एप्लिकेशन का एक नया संस्करण तैनात करते हैं, तो उन्हें केवल एक डेटाबेस में स्कीमा परिवर्तन करना होगा। विभिन्न ग्राहकों को सिंक से बाहर होने या गलत संस्करण के बारे में कोई चिंता नहीं है।
आसान प्रदर्शन ट्यूनिंग। हम केवल एक ही स्थान पर सूचकांक के उपयोग और आंकड़ों की जांच कर सकते हैं, सुधारों को आसानी से लागू कर सकते हैं, और अपने सभी ग्राहकों पर तुरंत प्रभाव देख सकते हैं। सैकड़ों या हजारों डेटाबेस के साथ, यहां तक कि सबसे छोटा परिवर्तन भी समन्वय करना मुश्किल हो सकता है। हम अपनी प्रक्रिया कैश सामग्री की जांच कर सकते हैं और कुछ के लिए जान सकते हैं कि कौन सी क्वेरी या संग्रहीत कार्यविधियाँ हमारे संपूर्ण अनुप्रयोग में सबसे अधिक गहन हैं, जबकि यदि हम प्रति ग्राहक अलग डेटाबेस का उपयोग कर रहे हैं, तो हमारे पास अलग-अलग निष्पादन योजनाओं में क्वेरी उपयोग का कठिन समय हो सकता है।
बाहरी एपीआई बनाने में आसान। अगर हमें बाहरी लोगों के लिए उत्पादों के निर्माण के लिए अपने पूरे डेटाबेस तक पहुंच प्रदान करने की आवश्यकता है, तो हम यह आसान कर सकते हैं यदि सभी डेटा एक डेटाबेस में हैं। यदि एपीआई को कई सर्वरों पर कई डेटाबेस से डेटा समूहीकरण करना है, तो यह विकास और परीक्षण समय जोड़ता है। (दूसरी ओर, वह "एकाधिक सर्वर" चीज एक-डेटाबेस-से-नियम-उन-सभी परिदृश्य के लिए प्रतिबंध पर संकेत देना शुरू कर देती है: एक डेटाबेस का आमतौर पर मतलब होता है कि हमारे सभी लोड केवल एक डेटाबेस सर्वर पर प्रभाव डालते हैं।) आपके मामले में। , PowerBI के साथ, सभी को एक डेटाबेस में रखने से कनेक्शन को प्रबंधित करना बहुत आसान हो जाएगा।
आसान उच्च उपलब्धता और आपदा वसूली। यह वास्तव में, डेटाबेस मिररिंग, लॉग शिपिंग, प्रतिकृति, और क्लस्टरिंग का प्रबंधन करने के लिए वास्तव में सरल है अगर हम सब के बारे में चिंता करने की जरूरत है तो सिर्फ एक डेटाबेस है। हम जल्दी से एक बुनियादी ढाँचे का निर्माण कर सकते हैं।
प्रत्येक ग्राहक को अपने स्वयं के डेटाबेस या शार्ड में लाना
आपको अभी भी एक क्लाइंट लिस्टिंग की आवश्यकता है, लेकिन अब यह एक निर्देशिका बन जाती है - प्रत्येक क्लाइंट के लिए, आप उस शार्द को भी ट्रैक करते हैं, जिसमें स्टार्टअप पर, आपका ऐप इस तालिका पर सवाल करता है, और इसे रैम में कैश करता है। जब इसे क्लाइंट के लिए डेटा की आवश्यकता होती है, तो यह सीधे उस शार्क (डेटाबेस और सर्वर) से जुड़ जाता है।
इस दृष्टिकोण के लाभ:
आसान एकल ग्राहक पुनर्स्थापित करता है। ग्राहक अविश्वसनीय मीटबैग हैं। (मेरे अलावा - वे विश्वसनीय मीटबैग हैं।) उनके पास सभी प्रकार के "उफ़" क्षण हैं जहां वे अपने सभी डेटा को एक समय में वापस प्राप्त करना चाहते हैं, और अगर उनके डेटा के साथ छेड़छाड़ की जाती है, तो यह बहुत बड़ा दर्द है। एक ही टेबल में अन्य क्लाइंट डेटा। एकल-क्लाइंट-डेटाबेस परिदृश्य में पुनर्स्थापना मस्तिष्क-मृत आसान है: बस ग्राहक के डेटाबेस को पुनर्स्थापित करें। कोई और प्रभावित नहीं है।
आसान डेटा निर्यात। ग्राहकों को अपने डेटा पर अपना हाथ रखना पसंद है। वे यह जानना चाहते हैं कि वे अपने डेटा को किसी भी समय बाहर निकाल सकते हैं, वे चाहते हैं कि खतरनाक विक्रेता लॉक-इन परिदृश्य से बचें और वे अपनी रिपोर्टिंग स्वयं करना चाहते हैं। प्रत्येक क्लाइंट के डेटा को उनके स्वयं के डेटाबेस में अलग-थलग करने के साथ, हम उन्हें केवल अपने स्वयं के डेटाबेस बैकअप की एक प्रति दे सकते हैं। हमें डेटा निर्यात APIs बनाने की आवश्यकता नहीं है।
आसान मल्टी सर्वर स्केलेबिलिटी। जब किसी एक सर्वर से हमारे एप्लिकेशन को अधिक शक्ति की आवश्यकता होती है, तो हम डेटाबेस को कई सर्वरों के बीच विभाजित कर सकते हैं। हम भौगोलिक रूप से लोड को भी फैला सकते हैं, एशिया या यूरोप में ग्राहकों के करीब होने के लिए सर्वर लगाते हैं।
आसान प्रति ग्राहक प्रदर्शन ट्यूनिंग। यदि कुछ ग्राहक विभिन्न विशेषताओं या रिपोर्टों का उपयोग करते हैं, तो हम उन ग्राहकों के लिए केवल सभी के डेटा आकार को बढ़ाए बिना अनुक्रमणिका या अनुक्रमित दृश्यों का एक विशेष सेट बना सकते हैं। दी, यहां कुछ जोखिम है - ग्राहकों के बीच स्कीमा मतभेदों को अनुमति देकर, हमने अभी-अभी हमारे कोड की तैनाती को थोड़ा जोखिम भरा बना दिया है और हमारे प्रदर्शन प्रबंधन को बहुत मुश्किल बना दिया है।
आसान सुरक्षा प्रबंधन। जब तक हमने प्रति डेटाबेस एक उपयोगकर्ता के साथ सुरक्षा को ठीक से बंद नहीं किया है, तब तक हमें क्लाइंट X के क्लाइंट वाई के डेटा तक पहुंचने के बारे में चिंता करने की आवश्यकता नहीं है। हालाँकि, यदि हम सभी के लिए एक ही लॉगिन का उपयोग करते हैं, तो हमने वास्तव में इस चिंता का समाधान नहीं किया है।
आसान रखरखाव खिड़कियां। एक वैश्विक वातावरण में जहां ग्राहक दुनिया भर में बिखरे हुए हैं, ग्राहकों को रखरखाव के लिए ऑफ़लाइन लेना आसान है यदि हम इसे समूहों या क्षेत्रों में कर सकते हैं।
आपके लिए कौन अच्छा है?
कोई भी सही विकल्प नहीं है: आपको अपनी कंपनी की ताकत और कमजोरियों को जानना होगा। आइए मेरे दो ग्राहकों को उदाहरण के रूप में लेते हैं।
कंपनी हार्डवेयर प्रदर्शन ट्यूनिंग में एक एक्सेल है। वे वास्तव में बहुत अच्छे हैं, हार्डवेयर के अंतिम प्रदर्शन को बहुत कम करते हैं, और वे 12-18 महीने के चक्र पर अपने SQL सर्वर हार्डवेयर को बदलने में कोई आपत्ति नहीं करते हैं। (वे हर 4-6 महीने में वेब सर्वरों को रिफ्रेश करते हैं!) उनकी अकिलीज़ की एड़ी अत्यधिक अनुपालन और सुरक्षा आवश्यकताओं की होती है। उनके पास अविश्वसनीय ऑडिटिंग की आवश्यकता है, और उनके लिए एकल सर्वर पर बुलेटप्रूफ नियंत्रण को लागू करना आसान है, एकल डेटाबेस इसके बजाय दर्जनों सर्वरों पर हजारों डेटाबेस में उन आवश्यकताओं का प्रबंधन करना है। उन्होंने एक डेटाबेस, एक सर्वर, कई क्लाइंट चुने।
कंपनी 2 विकास प्रथाओं में उत्कृष्टता। हजारों डेटाबेस में स्कीमा परिवर्तन और कोड तैनाती को प्रबंधित करना उनके लिए सिर्फ एक समस्या नहीं है। उनके पास दुनिया भर के ग्राहक हैं, और वे घड़ी के आसपास उन ग्राहकों के लिए क्रेडिट कार्ड लेनदेन का प्रसंस्करण कर रहे हैं। उन्हें भौगोलिक रूप से लोड फैलाने की क्षमता की आवश्यकता होती है, और वे हर 12-18 महीनों में दुनिया भर के सर्वर को बदलना नहीं चाहते हैं। उन्होंने प्रत्येक क्लाइंट के लिए एक डेटाबेस चुना, और यह उनके ऑफशोर क्लाइंट्स के लिए एशिया और यूरोप में SQL सर्वर डालना शुरू कर रहा है।