मल्टी टेनेंसी या मल्टी इंस्टेंस?


11

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

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

उसके लिए मैंने एक साझा डेटाबेस (लॉगिन प्रयोजनों के लिए सभी उपयोगकर्ताओं को क्रेडेंशियल्स को सहेजने) और कई डेटाबेस साझा स्कीमा (प्रति खाता / कंपनी डेटाबेस) को बनाने का फैसला किया। असल में, मल्टी टेनेंसी

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

हालांकि, प्रत्येक दृष्टिकोण पेशेवरों और विपक्षों के साथ आता है, इसलिए मैं निर्णय नहीं ले सका कि किस दृष्टिकोण के साथ जाना है। यहाँ एक सूची है, लेकिन मेरे साथ नंगे हैं क्योंकि मुझे उन दोनों में ज्ञान की कमी है, इसलिए कुछ ऐसा हो सकता है जिसके बारे में मुझे जानकारी नहीं है, या एक समस्या का हल जो मुझे वेब पर नहीं मिला: [प्रत्येक दृष्टिकोण है एक क्रमबद्ध सूची जिसकी मैंने एक के बाद एक तुलना की]

मल्टी टेनेंसी :

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

बहु उदाहरण :

  1. साझा किए गए या बिना होस्ट किए गए होस्ट / हार्डवेयर, प्रति उदाहरण कोड, और डेटाबेस प्रति उदाहरण।
  2. यह कठिन कार्यक्षमता या ठीक कीड़े विस्तार करने के लिए (मुझे यकीन है कि डोकर में यह करने के लिए जहां एक उदाहरण या डोकर कंटेनर के लिए कार्यक्षमता / सुविधा जोड़ सकते हैं और इसे दूसरों को तैनात एक तरह से वहाँ है अगर नहीं कर रहा हूँ)।
  3. यह आसान किसी भिन्न होस्ट / हार्डवेयर के लिए पूरे उदाहरण ले जाने के लिए।
  4. उदाहरण के रूप में, मुझे उस परत का ध्यान रखने की आवश्यकता नहीं है क्योंकि प्रत्येक उदाहरण का अपना डेटाबेस होगा।

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

मामले में जो मदद करेगा (शायद?), हम लारवेल को बैक-एंड के लिए मुख्य ढांचे के रूप में उपयोग कर रहे हैं (सभी बाकी)।


आप इसे सभी एक डेटाबेस में भी रख सकते हैं। यदि आप किसी एकल डेटाबेस में क्रेडेंशियल संग्रहीत कर रहे हैं, तो मुझे शेष डेटा को विभाजित करने का बिंदु दिखाई नहीं देता है।
ग्रैंडमास्टरबी

मुझे लगता है कि आप प्रत्येक किरायेदार के डेटा को अलग करने के बिंदु से चूक गए। साझा डेटाबेस केवल लॉगिन उद्देश्यों के लिए है।
अशर

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

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

@ क्या आपने दो विकल्पों में से कुछ के लिए फैसला किया है? और क्यों? Answare उन लोगों के लिए उपयोगी होगा जिनके पास समान खोज हैं (जैसे कि मेरे)
alecardv

जवाबों:


8

मैं फिलहाल खुद से वही सवाल पूछ रहा हूं।

मैं बहु-उदाहरण एकल किरायेदारी समाधान की ओर झुक रहा हूं, लेकिन अभी तक एक निश्चित निर्णय नहीं लिया है। मुझे अपने कुछ विचार साझा करने दें:

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

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

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

  • कंटेनर आधारित पा.स.
  • कंटेनर (लोचदार कंटेनर) के प्रावधान और ऑटो-स्केलिंग

इसलिए हार्डवेयर और प्लेटफ़ॉर्म प्रबंधन सॉफ़्टवेयर प्रदाता की चिंता नहीं है। अवसंरचना और फलक स्तरों पर संसाधन पहले की तुलना में बहुत अधिक कुशलता से परस्पर जुड़े हुए हैं

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

इसके अलावा:

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

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

जो मुझे एक बहुत ही प्रारंभिक चरण (प्री-इन्वेसमेंट) स्टार्टअप परियोजना के लिए एकल-किरायेदार के विकास के अंतिम लाभों के लिए लाता है:

  • एप्लिकेशन के समान (या लगभग समान) संस्करण को ऑन-प्रिमाइसेस में या तो एक वर्चुअल उपकरण या docker कंटेनर के रूप में या यहां तक ​​कि ग्राहक-प्रबंधित मशीन पर भी तैनात किया जा सकता है (कुछ कंपनियां अभी भी क्लाउड के प्रति अनिच्छुक हैं और यह शुरुआती चरण के स्टार्टअप को मदद नहीं कर सकती है महत्वपूर्ण प्रारंभिक दत्तक ग्रहण)
  • सीमित संसाधनों के साथ एक उत्पाद प्राप्त करने के लिए तेज़ (एप्लिकेशन परत और डेटाबेस स्कीमा काफी कम जटिल है), शुरुआती गोद लेने वालों के लिए पहले (एमवीपी) एक "डंबल" एकल उदाहरण एकल (एमवीपी) प्राप्त कर सकते हैं और ऐप के व्यावसायिक मूल्य को दिखा सकते हैं संभावित निवेशकों के लिए, और बाद में सभी क्लाउड ऑटोमेशन को जोड़ें
  • डेटा सुरक्षा के बारे में चिंतित ग्राहकों के लिए एक विक्रय तर्क के रूप में देखा जा सकता है: डेटा बेहतर रूप से समझाया जाता है क्योंकि हर ग्राहक का अपना स्कीमा या डेटाबेस होता है। "स्पिलज" का बहुत कम जोखिम

एनबी: मैं स्पष्ट रूप से यहां एक व्यावसायिक ऐप के बारे में सोच रहा हूं, जहां ग्राहक व्यवसाय होंगे (प्रत्येक एक से अधिक व्यक्तिगत उपयोगकर्ताओं के साथ) और व्यक्ति नहीं। यह प्रत्येक व्यक्ति के उपयोगकर्ता के लिए ऐप का एक अलग उदाहरण चलाने के लिए कोई मतलब नहीं होगा (या यह होगा?)


4

दोनों विकल्पों का समर्थन करना भी संभव है (कई उदाहरणों में किरायेदारों का एक पूल)।

मैं प्राकृतिक अलगाव के बहु-उदाहरण के पक्ष में हूं। प्रत्येक ग्राहक का उदाहरण उसकी स्वयं की प्रक्रियाओं में चलता है और यह डेटा स्वयं डेटाबेस में पृथक है। आप इच्छित होने पर प्रति ग्राहक / आवृत्ति के आधार पर नए संस्करणों में इंस्टेंस को अपग्रेड कर सकते हैं।

किरायेदार आधारित सिस्टम सूचना सुरक्षा जोखिम के साथ आते हैं। बस विचार करें कि "WHERE किराएदार = x" खंड को भूलना कितना आसान है। किरायेदार सक्षम प्रणाली का उपयोग करने का मुख्य कारण प्रदर्शन होगा, प्रक्रियाएं भारी वजन हैं, एक प्रक्रिया को साझा करके आप संभावित रूप से एक मशीन से अधिक प्राप्त कर सकते हैं। यह अधिक सच था मुझे लगता है कि 32-बिट की दुनिया में यह आजकल 64 बिट मशीनों पर है जिसमें बहुत अधिक रैम है।

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

मैं किरायेदार क्षमताओं को तब तक छोड़ देता हूं जब तक कि आप इसके लिए एक मामला नहीं बना सकते (इंजीनियरिंग लागत बनाम पैसे की बचत (हार्डवेयर साझाकरण प्रक्रिया प्रक्रिया के माध्यम से)।


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

मैं पूरी तरह से @Joppe से सहमत हूं, यहां कुछ और बिंदु हैं: 1. क्या ग्राहक उसी समय एप्लिकेशन को अन्य सभी के रूप में अपग्रेड करने के लिए तैयार हैं? कुछ ग्राहकों के पास ऐसे नियम हैं जो एप्लिकेशन को अपग्रेड करने से पहले लंबे परीक्षण चक्र की आवश्यकता होती है। अन्य हमेशा नवीनतम पर रहना चाहते हैं और विक्रेता के परीक्षण पर भरोसा करते हैं। मल्टी-टेनेंसी एक बुरा सपना बन सकता है। 2. जोखिम: डेटा-संवेदनशीलता का स्तर क्या है? जैसा कि जोप्पे ने उल्लेख किया है, फ़िल्टरिंग को भूलना और दूसरों के प्रति संवेदनशील डेटा को उजागर करना आसान है। बहु-किरायेदारी के साथ आप पर मुकदमा चलाया जा सकता है, बहु-उदाहरण में, आप दोष को सौंपने की कोशिश कर सकते हैं। ;)
डैनिलो टॉमासीना
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.