मल्टी-टेनेंट डेटा आर्किटेक्चर

हाय हमर!









एक समय में, कंप्यूटर में कई मंजिलों का आकार होता था, और कई ऑपरेटर एक शक्तिशाली कंप्यूटर के साथ काम करते थे। तब तकनीक का यह चमत्कार डेस्कटॉप के आकार को कम करने और हर घर में रखने में सक्षम था। अब फिर से, "क्लाउड कंप्यूटिंग" एक नवाचार माना जाता है, हम्म ... यह सब कई टर्मिनलों और एक शक्तिशाली कंप्यूटर डेटा सेंटर के लिए नीचे आता है। ठीक है, चलो तब तक प्रतीक्षा करें जब तक कि Google डेटा केंद्र लैपटॉप के आकार तक कम नहीं हो जाता ...

परिचय

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

क्लाइंट सेवाओं के उपयोग के लिए भुगतान करता है और सर्वर खरीदने और उन्हें बनाए रखने के बारे में नहीं सोचता है। यह दृष्टिकोण क्लाइंट के लिए सस्ता है और ठेकेदार के लिए भुगतान करता है (क्योंकि यह लाइसेंसिंग और पायरेसी के साथ समस्याओं को हल करता है, और सबसे महत्वपूर्ण बात, एक सेवा कई ग्राहकों को प्रदान की जा सकती है)। हालाँकि, क्लाइंट को ठेकेदार पर भरोसा करना चाहिए, जैसा कि उसके सभी डेटा दूर, बहुत दूर हैं।

स्वाभाविक रूप से, इस तरह के निर्णय ने हमें डेटा प्लेसमेंट और पृथक्करण के क्षेत्र में समझौता करने की कोशिश की।

चूंकि एक उदाहरण के बिना कुछ बताना काफी समस्याग्रस्त है, एक सार समस्या पर विचार करें।

कार्य

1. प्रतिस्पर्धा करने में सक्षम होने के लिए कई बड़ी कंपनियों को खबर का पालन करने की आवश्यकता है;
2. समाचार - सूचना पूरे इंटरनेट में बिखरी हुई;
3. एक सेवा के रूप में, एक प्रणाली जो एक निश्चित तरीके से इंटरनेट पर आवश्यक जानकारी एकत्र करती है और इसे एक डेटाबेस में संग्रहीत करती है, ताकि इसे फिर क्लाइंट को दिखाया जा सके;
4. समय की अवधि (छह महीने से एक वर्ष) के बाद, डेटा को संग्रह (मुख्य डेटाबेस से हटा दिया गया) में स्थानांतरित किया जाएगा।

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



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

हल: MULTI-TENANT

विभिन्न ग्राहकों के डेटा को साझा करने के लिए दिमाग में आने वाला पहला समाधान अलग-अलग डेटाबेस (एक अलग दृष्टिकोण) में संग्रहीत किया जाएगा। एक विकल्प के रूप में, आप एक अतिरिक्त फ़ील्ड TenantID दर्ज करके सभी डेटाबेस को एक डेटाबेस में संग्रहीत कर सकते हैं, जिसके द्वारा उन्हें (सामान्य दृष्टिकोण) भेद करने के लिए। तर्क के द्वंद्व के बावजूद, दो समाधान नहीं थे, लेकिन अधिक। यह तथ्य msdn से उधार ली गई तस्वीर में बहुत ही स्पष्ट रूप से प्रस्तुत किया गया है:

विभिन्न डेटाबेस

यह समाधान - जो सबसे पहले ध्यान में आता है, वह है डेटा शेयरिंग का सरलतम कार्यान्वयन।







इस दृष्टिकोण के साथ, कोड ग्राहकों (आम यूआई फ़ाइलों और व्यावसायिक तर्क का उपयोग किया जाता है) के बीच साझा किया जाता है, और डेटा तार्किक रूप से (और संभवतः शारीरिक रूप से) साझा किया जाता है।

फायदे:

• सरल एक्स्टेंसिबिलिटी (एक क्लाइंट जोड़ने के लिए, बस एक नया डेटाबेस बनाएं और कॉन्फ़िगरेशन फ़ाइल को कॉन्फ़िगर करें);
• सरल स्केलिंग - आप अलग-अलग क्लाइंट्स के डेटाबेस को अलग-अलग सर्वरों में वितरित कर सकते हैं;
• व्यक्तित्व - आप कुछ ग्राहकों के लिए अलग-अलग सेटिंग्स कर सकते हैं (यहां तक ​​कि डेटाबेस को दूसरे DBMS पर रखें);
• एक साधारण डेटा बैकअप - यदि डेटाबेस के रोलबैक के दौरान एक क्लाइंट में कुछ टूट गया, तो अन्य, यह स्पर्श नहीं करेगा;

नुकसान:

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

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

सामान्य डेटाबेस, विभिन्न योजनाएँ

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

फायदे:

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

नुकसान:

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

निचला रेखा, यदि ग्राहक अगले दरवाजे पर रहने के लिए तैयार हैं, तो विकल्प काफी प्रभावी है, क्योंकि पिछले संस्करण की तुलना में अधिक ग्राहकों को एक मशीन पर बसने की अनुमति देगा।

सामान्य डेटाबेस, सामान्य योजना

तीसरा विकल्प एक डेटाबेस और आम तालिकाओं में सब कुछ संग्रहीत करना है। इस विकल्प को लागू करने के लिए, एक पूर्वापेक्षा ग्राहकों के बारे में जानकारी साझा करने के लिए एक अतिरिक्त क्षेत्र टेनांटिड (या कस्टमरआईडी जैसा आप) का परिचय होगा।

फायदे:

• सस्ते, सब कुछ तालिकाओं के एक सेट में संग्रहीत किया जाएगा;
• एक ग्राहक जोड़ना बस ग्राहक तालिका में एक नया रिकॉर्ड बनाना है;

नुकसान:

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

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

हर्ष वास्तविकता

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



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

संकेत आप कहते हैं? - मैं महंगा कहूंगा। इसके अलावा, यहां तक ​​कि अगर इंडेक्स हैं, तो डेटा डिस्क के विभिन्न हिस्सों में अभी भी झूठ होगा।

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







विभाजन के साथ, एक ग्राहक का डेटा क्रमिक रूप से शेष से अलग स्थान पर स्थित होता है। सादगी के लिए, हम मान सकते हैं कि प्रत्येक क्लाइंट का डेटा एक अलग लॉजिकल ड्राइव पर है। यह सुविधा DBMS स्तर पर समर्थित है, इसलिए ड्राइवरों को लिखने और पहिया को सुदृढ़ करने की कोई आवश्यकता नहीं है।

उपसंहार

यह लेख एक अनुवाद नहीं है, लेकिन स्वाभाविक रूप से बहु-किरायेदार के सार को रेखांकित करने वाले अंग्रेजी-भाषा के स्रोत हैं।

कुछ संबंधित लिंक:

www.developer.com/design/article.php/3801931

msdn.microsoft.com/en-us/library/aa479069.aspx

msdn.microsoft.com/en-us/library/aa479086.aspx

डी। सुर्कोव को विशेष धन्यवाद और DMinsky (ये अलग-अलग दिमित्री हैं)

पोस्टस्क्रिप्ट के बाद

इस अवसर को लेते हुए, मैं इस वर्ष आगामी, नवीनतम, सबसे शुक्रवार, शुक्रवार को सभी को बधाई देना चाहता हूं!