किस बिंदु पर प्रति ग्राहक एक डेटाबेस अप्रभावी हो जाता है?

31

हमारे सिस्टम में से एक के लिए, हमारे पास संवेदनशील क्लाइंट डेटा है और प्रत्येक क्लाइंट के डेटा को एक अलग डेटाबेस में संग्रहीत करता है। हमारे पास उस प्रणाली के लिए लगभग 10-15 ग्राहक हैं।

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

इस पर कोई विचार?

database-design sql-server-2012

— NibblyPig
स्रोत

मैं प्रति सर्वर कई डेटाबेस होने के पेशेवरों-विपक्ष को नहीं जानता (मेरे पास कभी भी कोई समस्या नहीं थी) लेकिन कई स्कीमा अवधारणा technet.microsoft.com/en-us/library/dd207005.aspx एक ही डेटाबेस के भीतर, दोनों प्रदान करता है अलगाव और सुरक्षा। तो, आप इस वास्तुकला को भी आजमा सकते हैं।

— अलेक्जेंड्रोस

2

@Alexandros स्कीमा जुदाई थोड़ा प्रदान करता है, लेकिन यह आपको अलग-अलग पुनर्प्राप्ति मॉडल का उपयोग करने की अनुमति नहीं देता है, अलग-अलग शेड्यूल पर बैक अप करता है, एक क्लाइंट को समय में एक विशिष्ट बिंदु पर पुनर्स्थापित करता है, एक क्लाइंट को आसानी से हटाता है, एक क्लाइंट को आसानी से स्थानांतरित करता है, आदि

— हारून बर्ट्रेंड

4

मैंने एक सर्वर पर 3,000+ डेटाबेस (प्रति ग्राहक 1) के साथ सिस्टम देखा है। मैं बहुत ज्यादा चिंता नहीं करता - बस सुनिश्चित करें कि आप संसाधनों की सावधानीपूर्वक योजना बनाते हैं और उपयोग की निगरानी करते हैं क्योंकि ग्राहक की गिनती ऊपर जाती है।

— मैक्स वर्नोन

आप इसे पढ़ सकते हैं, विशेष रूप से तारीखों और ऑप्स टिप्पणियों पर ध्यान दें: stackoverflow.com/questions/5596755/…

— NotMe

48

100 या 500 डेटाबेस का प्रबंधन करना वास्तव में यह सब 5 या 10 के प्रबंधन से अलग नहीं है - आपको बस स्वचालन को गले लगाना होगा और एक स्केलेबिलिटी प्लान करना होगा (और सभी में मिररिंग जैसी उच्च-लागत-प्रति-डेटाबेस सुविधाओं का उपयोग करने की योजना नहीं है ग्राहकों)।

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

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

मैं इन पोस्टों में कई आपत्तियों, और / या कैसे समस्याओं को हल करने के लिए संबोधित करता हूं:

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

— आरोन बर्ट्रेंड
स्रोत

6

आपको लगातार लागू होने वाले अच्छे नामकरण सम्मेलन की भी आवश्यकता होगी।

— ग्रीनस्टोन वाकर

धन्यवाद उन कुछ महान लिंक हैं। यह वास्तव में एक प्रबंधन मुद्दा नहीं है (फिलहाल), मैं सिर्फ चिंतित था कि चीजें रुक सकती हैं। लेकिन ऐसा लगता है कि मुझे इसकी चिंता नहीं करनी चाहिए और यह सुनिश्चित करना चाहिए कि मैं यह सब प्रबंधित कर सकूं। तो धन्यवाद!

— निब्लीपिग

@ एरोन का OMS में समान परिदृश्य है जहां मेरे पास कई कार्यशालाएं हैं जो एक आदेश की प्रक्रिया करती हैं और वे स्वतंत्र हैं। कार्यशाला का चयन ऑर्डर (ग्राहक) पते के आधार पर किया जाता है। तो एक ग्राहक कई वर्कशो में ऑर्डर दे सकता है। इसलिए जब ग्राहक डेटाबेस को प्रत्येक डेटाबेस सर्वर पर जाने की आवश्यकता होती है, तो यह मुश्किल होता है।

— नवरतन यादव

15

मैं आपको मल्टी-टेनेंट डेटा आर्किटेक्चर , एक श्वेत-पत्र पढ़ने की सलाह देता हूं जो आपके पास विकल्प, और पेशेवरों और विपक्षों पर चर्चा करता है। संक्षेप में, यह तीन विकल्प देता है:

अलग डी.बी.
अलग स्कीमा
साझा स्कीमा

अब आप अलग-अलग DBs चरण में हैं, जो सबसे अच्छा जुदाई (किरायेदारों के बीच अलगाव) प्रदान करता है, लेकिन प्रबंधन करना सबसे कठिन है। जैसे ही आप सैकड़ों किरायेदारों में बढ़ते हैं, आपको पता चलेगा कि 100s के डीबी का प्रबंधन तुच्छ से दूर है। बैकअप-पुनर्स्थापना (बैकअप फ़ाइलों, कार्य, शेड्यूल आदि का स्थान) के बारे में सोचें। सोचें कि आप सैकड़ों डीबी पर फ़ाइल आवंटन, डिस्क स्थान का उपयोग और डेटाबेस वृद्धि की निगरानी और प्रबंधन कैसे करेंगे। सोचो कि 1000 किरायेदार के साथ निकट भविष्य में आपकी उच्च-उपलब्धता / आपदा-पुनर्प्राप्ति परिदृश्य क्या होगा? 1000 प्रतिबिंबित डीबी, 1000 लॉग शिपिंग सत्र? सोचें कि अगर 6 महीने में आपकी देव टीम आपके पास आती है और कहती है "मुझे पता है कि हमारे उत्पाद को यह भयानक सुविधा कैसे दी जाए, तो हम Transactional प्रतिकृति का उपयोग करेंगे!", आप क्या कहेंगे? "यकीन है, मुझे 500 प्रकाशकों की स्थापना,"! सैकड़ों DBs का प्रबंधन करना असंभव नहीं है, लेकिन अगर आप योजना बनाते हैं, तो आप अपने PowerShell कौशल को बेहतर ढंग से पॉलिश करेंगे और अभी UI प्रबंधन उपकरणों का उपयोग करना बंद कर देंगे ।

इसके अतिरिक्त आपको यह विचार करने की आवश्यकता है कि कई (सैकड़ों) डीबी का प्रदर्शन और लागत पर औसत दर्जे का प्रभाव पड़ता है:

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

अलग-अलग डीबी कुछ फायदे के साथ आते हैं हालांकि अलगाव के कारण मुख्य लाभ स्वतंत्र बैकअप / पुनर्स्थापना है।

यद्यपि आप की तरह परिदृश्य SQL Azure डेटाबेस के लिए एक आदर्श उम्मीदवार हैं । डिस्क स्थान का कोई प्रशासन, हा / डीआर प्रदान करने की आवश्यकता नहीं, सैकड़ों / हजारों डीबी के लिए बढ़ें आदि।

— रेमस रुसानु
स्रोत

धन्यवाद यह कुछ अच्छी सलाह है, विशेष रूप से संभवतः क्लाउड मॉडल पर स्विच करना। मुझे कुछ गंभीर विचार देने होंगे कि मैं कैसे चीजों का समर्थन करने जा रहा हूं।

— निब्लीपिग

और एक बार जब आपका स्वचालन प्रत्येक क्लाइंट के लिए अलग-अलग डेटाबेस का समर्थन करने के लिए पर्याप्त रूप से विकसित हो जाता है, तो यह प्रत्येक क्लाइंट के लिए अलग-अलग वीएम को प्रावधान करने के लिए वहां से एक विशाल छलांग नहीं है। यह, आखिरकार, "क्लाउड" होस्टिंग कंपनियां क्या करती हैं। सहमत हूँ कि यह संभवतः SQL Azure

— Gavin Campbell

2

मेरी पिछली नौकरी में, हमने प्रति ग्राहक केवल एक डेटाबेस की मेजबानी नहीं की - ज्यादातर उदाहरणों में, यह उससे अधिक था! जैसा कि मैंने छोड़ा था, एक मारियाडीबी क्लस्टर में 4,500 से अधिक डेटाबेस चल रहे थे, दूसरे में लगभग 7,000 (विडंबना से छोटे) क्लस्टर, और 4 "शार्क" (पूरी तरह से अलग, स्वतंत्र वेब और डेटाबेस सर्वर, यहां तक कि पूरी तरह से अलग डेटा सेंटर में) प्रत्येक होस्टिंग एक एकल MySQL सर्वर में 200-500 डेटाबेस। और वह कंपनी अभी भी एक अच्छी क्लिप में बढ़ रही है।

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

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

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

— Kromey
स्रोत