एक उदाहरण में ओरेकल उदाहरणों के 100 के विलय की बुद्धि

Question

हमारा आवेदन वेब पर चलता है, ज्यादातर पूछताछ उपकरण है, कुछ लेनदेन करता है। हम ओरेकल डेटाबेस होस्ट करते हैं। प्रत्येक ग्राहक के लिए ऐप में हमेशा ओरेकल का एक अलग उदाहरण होता है। एक ग्राहक एक ऐसी कंपनी है जो हमें कंपनी के कर्मचारियों को आम तौर पर 10,000-25,000 कर्मचारियों को सेवा प्रदान करने का भुगतान करती है। हम कई सौ ग्राहकों का इरादा रखते हैं। हम हर कुछ वर्षों में एक बड़ी रिलीज करते हैं, और उस नई रिलीज में माइग्रेट करना चुनौतीपूर्ण है: हमारे पास कुछ हफ्तों के लिए ग्राहक साइट पर एक टीम हो सकती है, नई कार्यक्षमता समझाती है और उस ग्राहक के अनुरूप ड्राइविंग डेटा सेट अप कर सकती है।

हम बहु-ग्राहक जाने पर विचार कर रहे हैं, जिससे हमारे सभी ग्राहकों को लागत को कम करने के लिए एक बड़े honkin 'विंडोज सर्वर 2008 सर्वर पर एक साझा साझा ओरेकल 11 जी उदाहरण में डाल दिया गया है। मैं सोच रहा हूं कि क्या सलाह दी जाती है।

प्रत्येक ग्राहक के लिए अलग-अलग उदाहरण होने के कुछ फायदे हैं। मुझे बताएं कि क्या ये फर्जी हैं, कृपया। घटते महत्व के बारे में मेरी किसी न किसी अनुमान में:

• हमारे ग्राहकों MyCorp और YourCo अलग से चले गए जा सकता है जब तोड़ने परिवर्तन स्कीमा के बने होते हैं। (बहु-ग्राहक के साथ, हम 300+ ग्राहकों को रातोंरात माइग्रेट कर रहे होंगे!?!)

• MyCorp का डेटा आसानी से बैक अप लिया जा सकता है और (!!!) अन्य ग्राहकों को प्रभावित किए बिना बहाल किया जा सकता है।

• माइक्रॉर्प का डेटा सुरक्षित रूप से कोड प्राप्त करने के लिए डेवलपर्स के आधार पर और/या डीबीए को कॉन्फ़िगरेशन अधिकार प्राप्त करने के आधार पर अपने प्रतिस्पर्धी योरको के डेटा से सुरक्षित रूप से अलग किया जाता है।

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

• एक सर्वर पर एक उदाहरण होने से विफलता का एक बिंदु प्रस्तुत होता है, यदि हमारे तूफान इमारत से बाहर निकलते हैं तो हमारे पूरे ग्राहक आधार व्यापार से बाहर होते हैं। एकाधिक सर्वरों पर कई उदाहरण भौगोलिक फैलाव की अनुमति देते हैं: कोई आपदा हमारे ग्राहकों के अनुपात को बहुत अधिक प्रभावित नहीं करेगी, और अन्य क्षेत्रों में अप्रभावित सर्वर असफल सर्वरों के भार को ले सकते हैं।

• प्रदर्शन बेहतर है क्योंकि डेटाबेस छोटा है (~ 10,000 टेबल में 10,000 बनाम 2,000,000 पंक्तियां)।

• यदि MyCorp के कार्यालय केवल एक क्षेत्र में (अधिकतर) हैं, तो MyCorp का उदाहरण भौगोलिक दृष्टि से सह-स्थित हो सकता है, इसलिए नेटवर्क अंतराल प्रदर्शन को नुकसान नहीं पहुंचाता है। हम इसी कारण से वैश्विक ग्राहकों को बेहतर सेवा प्रदान कर सकते हैं।

• माइक्रॉर्प में अपना डेटाबेस इन-हाउस लेना चाहता है, तो हम माइक्रॉर्प को अपना डेटा प्राप्त करने के लिए आसानी से अपना उदाहरण निर्यात कर सकते हैं।

• लोड-बैलेंसिंग आसान है क्योंकि विभिन्न सर्वरों पर उदाहरणों को रखा जा सकता है (यह एक वेब फार्म के साथ है)।

• जब कोई DEV या QA इंस्टेंस की आवश्यकता होती है, तो वास्तविक उदाहरण को क्लोन करना और डेटा को अनामित करना आसान है, क्योंकि बहुत कम डेटा है।

• क्योंकि वे काफी छोटे हैं, डेवलपर्स का अपना उदाहरण स्थानीय रूप से चल रहा है, इसलिए वे हवाई अड्डे पर इंतजार करते समय और उड़ान भरते समय कोड पर काम कर सकते हैं, वीपीएन परेशानियों के बिना।

Q1: अलग उदाहरणों में से अन्य लाभ क्या हैं?

हम डेटाबेस स्कीमा बदल रहा है और एक Oracle उदाहरण में हमारे सभी ग्राहकों के विलय, एक मोटी सर्वर पर चल रहा विचार कर रहे हैं।

यहां बहु-क्लाइंट इंस्टेंस दृष्टिकोण के फायदे हैं, सबसे महत्वपूर्ण पहले (मेरे डब्ल्यूएजी)। क्योंकि वे केवल सैकड़ों के बजाय एक उदाहरण बनाए रखने की जरूरत,

• DBAs के लिए कम काम: कृपया ठीक गोली चलाना है, तो इन फर्जी हैं। कम डीबीए काम सस्ता करने के लिए अनुवाद करता है, इस परिवर्तन के लिए हमारा मुख्य उद्देश्य।

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

• डेवलपर्स के लिए & एप्लिकेशन को बढ़ाने के लिए आसान होगा, क्योंकि केवल एक स्कीमा और एक ऐप है (यदि सैकड़ों उदाहरण हैं, तो ऐप के एक अलग संस्करण के साथ कई प्रकार के स्कीमा संस्करण हो सकते हैं स्कीमा के प्रत्येक संस्करण)। इससे लागत भी कम हो जाती है। विकल्प के साथ प्रत्येक डीबग सत्र शुरू करना है (1) यह ग्राहक किस संस्करण को चला रहा है और (2) चलो इसी विकास पर्यावरण, कोड और डेटाबेस को फिर से बनाने के लिए संघर्ष करते हैं। (हमें एक वर्चुअल मशीन की आवश्यकता है जिसमें प्रत्येक पैच और रिलीज के लिए कोड और डेटाबेस इंस्टेंस शामिल है!)

• लाइसेंसिंग ओरेकल सस्ता है क्योंकि यह प्रति सर्वर की कीमत के बावजूद है (या कुछ - मुझे इसके बारे में कुछ नहीं पता अधीन)।

• डेटाबेस वेब सत्र डेटा के लिए एक व्यवहार्य निरंतर स्टोर बन जाता है, क्योंकि केवल एक उदाहरण है।

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

Q2: एक उदाहरण में कई ग्राहकों होने के अन्य लाभ क्या हैं?

प्रश्न 3: आपको कौन सा दृष्टिकोण बेहतर लगता है (क्यों)? प्रति ग्राहक उदाहरण, या सभी ग्राहकों को एक उदाहरण में?

मैं चिंतित हूं कि एक बहु-ग्राहक उदाहरण होने लगभग असंभव प्रवास बनाता हूँ, और कि एक सौदा हत्यारा है ...

... जब तक कि वहाँ दो होने की तरह एक समझौता समाधान है बहु-ग्राहक उदाहरण, पुराने और नए।उस मामले में, हम प्रतिभागियों, रिपोर्टिंग इत्यादि को खोजने के लिए क्रॉस-इंस्टेंस समाधान तैयार करेंगे ताकि ग्राहक बिना किसी ब्रेकिंग के अगले में एक बहु-क्लाइंट इंस्टेंस से जा सकें।

Answer 1

जब तक आप ओरेकल एक्सई (सीमित, मुक्त संस्करण) का उपयोग नहीं कर रहे हैं, तो प्रति सर्वर एक डेटाबेस बहुत महंगा हो जाएगा, भले ही आप सिंगल कोर, सिंगल सीपीयू बॉक्स खरीद रहे हों। प्रति सर्वर कई डेटाबेस अक्षम हैं, क्योंकि प्रत्येक डेटाबेस में CPU और RAM उपयोग का ओवरहेड होता है। ट्यूनिंग अधिक कठिन है, क्योंकि विवाद का निदान करना कठिन होता है।

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

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

एक चीज जो आप समेकन से खो सकते हैं वह आपके आवेदन के विभिन्न संस्करणों पर विभिन्न ग्राहकों का समर्थन करने की क्षमता है। हालांकि, यह एक बुरी बात नहीं है। जैसा कि आप देखते हैं, यदि आप आवेदन के व्यक्तिगत संस्करणों को छोड़ देते हैं तो कई सौ ग्राहकों को बनाए रखना बहुत आसान होगा। यदि आपको कुछ bespoke सुविधाओं की पेशकश करने की आवश्यकता है - भले ही आप किसी व्यक्तिगत क्लाइंट के साथ कुछ कार्यक्षमता का परीक्षण करना चाहते हैं - फिर Edition-Based Redefinition in 11gR2 पर एक नज़र डालें: यह वास्तव में निफ्टी सुविधा है। यह सभी ओरेकल लाइसेंसों के लिए भी उपलब्ध है, न केवल एंटरप्राइज़।

Answer 2

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

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

ओरेकल की दुकान के अनुसार,

• ओरेकल मानक संस्करण एक 5,800.00 $/प्रोसेसर है (जहां 86 पर, एक प्रोसेसर सॉकेट है, और आप के लिए 2 सॉकेट पर जा सकते हैं)
• ओरेकल मानक संस्करण $ 17,500.00/प्रोसेसर (जहां x86 पर, प्रोसेसर एक सॉकेट है, और आप 4 सॉकेट तक जा सकते हैं)
• ओरेकल एंटरप्राइज़ संस्करण $ 47,500.00/प्रोसेसर (जहां x86 पर, एक प्रोसेसर 2 कोर है - इसलिए आपको प्रभावी ढंग से प्रभावी होना है क्वाड कोर सीपीयू के लिए उस कीमत को दोगुना करें)

तो यदि, उदाहरण के लिए, आपको 100 ग्राहकों को संभालने के लिए 8 क्वाड कोर सीपीयू की आवश्यकता है, तो लाइसेंसिंग करना कि एक ही डेटाबेस पर 4 अलग-अलग डेटाबेस होने की तुलना में अधिक महंगा है, प्रत्येक में 2 क्वाड कोर CPU हैं, प्रत्येक 25 ग्राहक चल रहे हैं।

8 क्वाड कोर CPUs को एंटरप्राइज़ संस्करण की आवश्यकता होती है, और इसकी सूची 16 x $ 47,500 = $ 760,000 होगी। 4 मशीनें, प्रत्येक चल रहे मानक संस्करण एक, और प्रत्येक 2 क्वाड-कोर सीपीयूएस के साथ, 8 x $ 5,800.00 = $ 46,400 की सूची मूल्य होगी - 16 अंतर का एक कारक। अब, ध्यान रखें कि कोई भी उद्यम संस्करण के लिए सूची मूल्य का भुगतान नहीं करता है, लेकिन अभी भी विचार करने के लिए एक बड़ा अंतर है।

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

Answer 3

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

मैं होस्ट किए गए एप्लिकेशन के लिए डीबीए था और डेवलपर्स ने इसके लिए ओरेकल वर्चुअल प्राइवेट डेटाबेस सुविधा का उपयोग करने का निर्णय लिया।

एप्लिकेशन लोड बैलेंसिंग और बैक एंड पर एक डेटाबेस स्कीमा के लिए ऐप सर्वर के पूल साझा करने वाले ग्राहकों के इरादे से बनाया गया था।

वीपीडी से पहले हमारे पास जावा क्लास था जिसने "ग्राहक_आईडी =?" या "और ग्राहक_आईडी =?" डाटाबेस में जाने से ठीक पहले प्रत्येक क्वेरी पर, ग्राहक केवल अपना डेटा देखेंगे। डीबी में लॉगिन पर वीपीडी में इसे लागू करने के लिए हम ऐप को ऐप संदर्भ में एक चर सेट करेंगे जिसका उपयोग वीपीडी नीतियों द्वारा किया जाएगा ताकि सत्र को केवल उनके रिकॉर्ड देख सकें। तो हाँ, आपको इसे सही तरीके से कोड करना होगा और टेबल पर वीपीडी नीतियों को असाइन करना होगा, और यह भी भरोसा है कि ओरेकल सौदेबाजी का अपना अंत रखता है।

तो क्या यह हमारे लिए अच्छा था? सिद्धांत रूप में हमारे आवेदन के बाहर कुछ करने के लिए SQL predicate हैंडलिंग को ऑफ़लोड करना अच्छा था, लेकिन व्यवहार में फायदे नुकसान को कम नहीं करते थे।

• जब हमारे पास एक डेटाबेस में दर्जनों ग्राहक थे और जब हमने अपग्रेड किया तो उन्हें सभी को एक ही समय में अपग्रेड करना पड़ा। हमारे पास उन ग्राहकों के साथ बहुत सारे युद्ध थे जो किसी भी कारण से अपग्रेड नहीं करना चाहते थे या नए संस्करणों पर अपना स्वयं का क्यूए नहीं करना चाहते थे।

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

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

तो इसके बाद मेरा क्या लेना है? मैंने यह सुनिश्चित करने में समय बिताया होगा कि हमारे ऐप ने बाइंड वैरिएबल का अच्छा इस्तेमाल किया है और पुराने तंत्र के साथ जारी रखा है जो SQL_id को SQL कथन में जोड़ा गया है।

Answer 4

मुझे कुछ बार एक ही निर्णय पर विचार करना पड़ा। हमारे मामले में हम MySQL का उपयोग करते हैं, इसलिए अलग-अलग डेटाबेस में सभी ग्राहकों को चलाने के साथ कोई लागत नहीं है।

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

डेटाबेस परिवर्तन बड़े mysql डेटाबेस पर बहुत लंबा समय ले सकता है। चूंकि हमारे सभी ग्राहकों का अपना डेटाबेस है, इसलिए हम अपने सभी डेटासेट को छोटा रखने में सक्षम हैं। बैकअप भी बहुत तेज़ हैं।

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

फेसबुक ने अपनी कंपनी शुरू करने पर एक ही दृष्टिकोण लिया। प्रत्येक स्कूल जिसे उन्होंने लॉन्च किया था, में एक अलग डेटाबेस था और वे नए उदाहरणों को बहुत जल्दी स्थापित करने में सक्षम थे। आखिरकार उन्होंने अपने डेटाबेस को समेकित करने का प्राथमिक कारण यह था कि वे उपयोगकर्ताओं को स्कूलों के बीच संवाद करने में सक्षम बनाना चाहते थे।

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

Answer 5

ओरेकल उस तरह के भार को संभालने के लिए बनाया जाता है।

मेरा प्रश्न - जब आप हजारों ग्राहक हैं और दस हजार कहें तो आप क्या करते हैं?
क्या आप अभी भी अलग-अलग उदाहरण/स्कीमा रखते हैं?

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

विश्वसनीयता के लिए आप अभी भी क्लस्टरिंग - Oracle RAC का उपयोग कर सकते हैं।

Answer 6

यह Salesforce शोध लायक हो सकता है, और चर्चा शब्द आप देख रहे हैं कि "बहु किरायेदार वास्तुकला"

यह एक अच्छा पढ़ने बनाता है:

http://blog.dayspring-tech.com/2009/02/forcecom-multitenant-architecture-under-the-covers/

यह क्योंकि एक अच्छा उदाहरण है सेल्सफोर्स कवर के तहत ओरेकल डीबी का उपयोग करते हैं।