क्या एक SQL सर्वर पर आपके द्वारा डाले जा सकने वाले डेटाबेस की कोई सीमा है?

Question

मैं एक SaaS सिस्टम स्थापित कर रहा हूँ, जहाँ हम प्रत्येक ग्राहक को अपना डेटाबेस देने की योजना बना रहे हैं। सिस्टम पहले से ही सेट किया गया है ताकि अगर लोड बहुत अधिक हो जाए तो हम आसानी से अतिरिक्त सर्वरों को स्केल कर सकें; हम हजारों, या यहां तक ​​कि हजारों ग्राहकों के लिए उम्मीद कर रहे हैं।

प्रशन

• क्या आपके पास एक SQL सर्वर पर माइक्रो-डेटाबेस की संख्या पर कोई व्यावहारिक सीमा हो सकती है / होनी चाहिए?
• क्या यह सर्वर के प्रदर्शन को प्रभावित कर सकता है?
• क्या प्रत्येक 100 एमबी के 10,000 डेटाबेस, या 1 टीबी का एक डेटाबेस बेहतर है?

अतिरिक्त जानकारी

जब मैं "माइक्रो-डेटाबेस" कहता हूं, तो मेरा वास्तव में "माइक्रो" नहीं होता है; मेरा तात्पर्य यह है कि हम हजारों ग्राहकों के लिए लक्ष्य कर रहे हैं, इसलिए प्रत्येक व्यक्तिगत डेटाबेस कुल डेटा संग्रहण का केवल एक हज़ारवां या उससे कम होगा। वास्तव में, प्रत्येक डेटाबेस 100 एमबी के आसपास होगा, यह इस बात पर निर्भर करता है कि उसे कितना उपयोग मिलता है।

10,000 डेटाबेस का उपयोग करने का मुख्य कारण स्केलेबिलिटी के लिए है। तथ्य यह है कि, सिस्टम के वी 1 में एक डेटाबेस है, और जब डीबी लोड के तहत तनावपूर्ण था, तो हमारे पास कुछ असहज क्षण थे।

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

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

हमने एज़्योर SQL डेटाबेस इलास्टिक पूल की कोशिश की । प्रदर्शन बहुत निराशाजनक था, इसलिए हमने नियमित वीएम पर वापस स्विच किया।

Answer 1

मैंने SQL सर्वर पर एक ही उदाहरण पर 8 से 10 हजार डेटाबेस के साथ काम किया है। यह सुंदर नहीं है।

सर्वर को पुनरारंभ करने में एक घंटे या उससे अधिक समय लग सकता है। 10,000 डेटाबेस के लिए पुनर्प्राप्ति प्रक्रिया के बारे में सोचें।

आप SQL सर्वर प्रबंधन स्टूडियो का उपयोग ऑब्जेक्ट एक्सप्लोरर में किसी डेटाबेस को मज़बूती से खोजने के लिए नहीं कर सकते हैं।

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

आप डेटाबेस के साथ नंबर, जैसे M01022, और नामकरण जैसी चीजें करना शुरू करते हैं T9945। यह सुनिश्चित करने की कोशिश कर रहे हैं कि आप सही डेटाबेस में काम कर रहे हैं, उदाहरण M001022के लिए M01022, इसके बजाय , यह मैडनिंग हो सकता है।

कई डेटाबेस के लिए स्मृति आवंटित करना कष्टदायी हो सकता है; SQL सर्वर बहुत सारे I / O को समाप्त करता है, जो प्रदर्शन पर एक वास्तविक ड्रैग हो सकता है। ऐसी प्रणाली पर विचार करें जो 10,000 कंपनियों के लिए 4 तालिकाओं में कार्बन उपयोग विवरण रिकॉर्ड करती है। यदि आप एक डेटाबेस में ऐसा करते हैं, तो आपको केवल 4 टेबल चाहिए; यदि आप 10,000 डेटाबेस में करते हैं, तो अचानक आपको मेमोरी में 40,000 टेबल चाहिए। स्मृति में तालिकाओं की उस संख्या से निपटने का ओवरहेड पर्याप्त है। यदि आपके द्वारा डिज़ाइन की गई कोई क्वेरी उन तालिकाओं के विरुद्ध चलाई जाएगी , तो योजना डेटाबेस में कम से कम 10,000 योजनाओं की आवश्यकता होगी यदि उपयोग में 10,000 डेटाबेस हैं।

ऊपर दी गई सूची समस्याओं का एक छोटा सा नमूना है जिसे आपको उस तरह के पैमाने पर संचालित करने के लिए योजना बनाने की आवश्यकता होगी।

आप शायद SQL सर्वर सेवा जैसी चीजों में भाग लेंगे, जिन्हें शुरू करने में बहुत लंबा समय लगेगा, जो सेवा नियंत्रक त्रुटियों का कारण बन सकता है। आप स्वयं सेवा स्टार्टअप समय बढ़ा सकते हैं, निम्न रजिस्ट्री प्रविष्टि बना सकते हैं:

उपकुंजी: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control
नाम: ServicesPipeTimeout
प्रकार: REG_DWORD
डेटा: सर्विस स्टार्टअप के दौरान समय से पहले मिलीसेकंड की संख्या

उदाहरण के लिए, सेवा समय से पहले 600 सेकंड (10 मिनट) प्रतीक्षा करने के लिए, 600000 टाइप करें।

---

अपने जवाब लिखने के बाद से मुझे एहसास हुआ कि सवाल अज़ूर के बारे में बात कर रहा है। शायद SQL डेटाबेस पर ऐसा करना समस्याग्रस्त नहीं है; शायद यह अधिक समस्याग्रस्त है। व्यक्तिगत रूप से, मैं शायद एक ही डेटाबेस का उपयोग कर एक प्रणाली डिज़ाइन करूँगा, शायद कई सर्वरों पर लंबवत रूप से शार्प किया गया है, लेकिन निश्चित रूप से एक-डेटाबेस-प्रति-ग्राहक नहीं।

Comments

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

— टोनी हिंकल

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

— alroc

Answer 2

तो दोनों विधियों के पेशेवरों और विपक्ष हैं। आपके एप्लिकेशन या सेवाओं के बारे में अधिक जानकारी के बिना आप मुझे प्रदान करने के लिए देख रहे हैं, मैं एक निश्चित उत्तर नहीं दे पाऊंगा, लेकिन मैं इस मामले पर अपने कुछ विचार बाहर फेंकूंगा।

क्यों आप सभी ग्राहकों के लिए 1 डेटाबेस का उपयोग करना चाहिए के लिए मेरा मामला।

पेशेवरों

• आसान रखरखाव। एक डीबी होने का मतलब है कि आपको केवल कई के बजाय एक स्थान पर अपना रखरखाव कार्य करना होगा। 1000 विभिन्न डेटाबेस को संभालने के दुःस्वप्न की कल्पना करें। 1000 DB या पुनर्निर्माण अनुक्रमित पर आँकड़ों को अद्यतन करने के बारे में कैसे DBCC CHECKDB?

• तैनाती कोड। मान लें कि आपको अपने एप्लिकेशन कोड या रिपोर्टिंग में संग्रहीत कार्यविधि में कोई समस्या है। आपको एक त्वरित परिवर्तन करने की आवश्यकता है ... अब आपको उस परिवर्तन को 1000+ DB के लिए तैनात करना होगा। नहीं, धन्यवाद, मैं नहीं चाहता था।

• आसान दृश्यता। बस चित्र SSMS 1000 + DB (कंपकंपी) खोलने की कोशिश कर रहा है । यह व्यावहारिक रूप से समस्या को बेकार कर देगा और SSMS को खोलने और प्रस्तुत करने के लिए आश्चर्यजनक समय लगेगा। ध्यान रखें, यदि आप एक सभ्य नामकरण सम्मेलन के साथ आने में सक्षम हैं।

विपक्ष

• सुरक्षा। यदि आप उन्हें अलग DB के रूप में रखते हैं तो अन्य ग्राहकों के डेटा को देखने से लोगों को रोकना आसान होगा। हालांकि कुछ बहुत ही सरल चीजें हैं जो आप ऐसा करने से रोक सकते हैं।

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

अंततः मुझे लगता है कि आपके सबसे अच्छे दांव में आपके लिए एक डीबी है और केवल डीबी के अंदर ग्राहक डेटा को विभाजित करना है। यह आपको जो परेशानी देगा वह 1000+ डेटाबेस के प्रबंधन के बुरे सपने की तुलना में कुछ भी नहीं होगा।

Answer 3

SQL सर्वर के लिए अधिकतम क्षमता विनिर्देश बताता है कि 32,767 की सीमा है।

जैसे कि क्या यह प्रदर्शन को प्रभावित करेगा, उत्तर हाँ है, लेकिन यह प्रदर्शन को प्रभावित करेगा, और क्या यह पर्याप्त होगा, कारकों के असंख्य पर निर्भर करेगा।

जब तक 10,000 डेटाबेस को विभाजित करने का एक अच्छा कारण नहीं होगा, मैं एक डेटाबेस के साथ जाऊंगा। एक बैकअप या 10,000 बैकअप? एक अखंडता की जाँच, या 10,000? 10,000 छोटे DB का उपयोग करने का एक अच्छा कारण हो सकता है, लेकिन आपने इसे निर्धारित करने के लिए पर्याप्त विवरण नहीं दिया है। आपके द्वारा पूछा गया प्रश्न काफी व्यापक है, और किसी के लिए बस इतनी जानकारी नहीं है कि सबसे अच्छा उत्तर क्या है।

Answer 4

आप यहां जिस बारे में बात कर रहे हैं वह मल्टी-टेनेंट बनाम मल्टी-इंस्टेंस आर्किटेक्चर है। मैं इन शर्तों को आपके सामने ला रहा हूं क्योंकि आप अपने प्रश्न में उनका उपयोग नहीं करते हैं, लेकिन यह वही है जिसे आप चर्चा कर रहे हैं और यदि आप Google में "मल्टी-टेनेंट आर्किटेक्चर" को प्लग करते हैं, तो आपको संसाधनों और चर्चा का खजाना मिलेगा इसके बारे में, इस पर पूरी किताबें लिखी गई हैं।

विशेष रूप से यहाँ SQL सर्वर के बारे में कुछ अच्छे संसाधन:

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

मैं अन्य उत्तरों के साथ रहूंगा, इसमें मैं एक डिफ़ॉल्ट के रूप में मल्टी-टेनेंट की ओर दृढ़ता से झुकूंगा, जब तक कि आपके पास मल्टी-इंस्टेंस के पक्ष में मजबूर करने वाले कारण नहीं होंगे।

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

आप ग्राहकों के "लाखों" के बारे में बात कर रहे हैं, किसी भी बड़े पैमाने पर क्लाउड-आधारित सॉफ़्टवेयर को एक सेवा के रूप में सोचें, जीमेल, जो भी हो, आपको शायद ही लगता है कि वे प्रत्येक नए साइनअप के लिए एक पूरी तरह से नया डेटाबेस बनाते हैं, अब आप करते हैं?

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

Answer 5

डाउनसाइड्स में से एक जो मैं एकल-डेटाबेस सुझाव को देख सकता हूं वह है रोलिंग डेटा के साथ करना - यदि आपके पास प्रति किरायेदार सेट-अप डेटाबेस है, तो आप प्रत्येक क्लाइंट के डेटा को स्वतंत्र रूप से (और किसी विशेष समय में) पुनर्स्थापित कर सकते हैं। यदि वे सभी एक डेटाबेस में हैं, तो यह बहुत कठिन हो जाता है (और त्रुटि के लिए बहुत अधिक प्रवण होता है क्योंकि इसे INSERT / UPDATE / DELETE कथनों के माध्यम से करने की आवश्यकता होगी)।

Comments

+1 - यह एक-डेटाबेस-प्रति-किरायेदार होने के बहुत कम वांछनीय लाभों में से एक है।

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

Answer 6

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

तेज करने के लिए प्रेरणा

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

चिंताओं का जवाब

• सर्वर को पुनरारंभ करने में एक लंबा समय लगता है: ठीक है, लेकिन सामान्य ऑपरेशन में हम किसी भी सर्वर को पुनरारंभ करने का इरादा नहीं कर रहे हैं। सिस्टम को अंततः 24/7 ऑनलाइन होना है, इसलिए यदि हम डाउनटाइम के लिए जा रहे हैं तो इसे वैसे भी शेड्यूल करना होगा।
• बैकअप / आपदा वसूली: हम क्लाउडबरी का उपयोग कर रहे हैं, जो सब कुछ स्वचालित करता है। एक समस्या नहीं है।
• डेटाबेस का नामकरण / उन्हें SSMS में पता लगाना: नामकरण सम्मेलन आसान है, बस ग्राहक के नाम पर आधारित है। यदि नाम साझा किए जाते हैं तो सीरियल अंक जोड़ें।
• अनुरक्षण: यदि प्रत्येक डेटाबेस मैं संशोधन के रूप में छोटा है, तो मैन्युअल रूप से अनुक्रमित पुनर्निर्माण की कोई आवश्यकता नहीं होनी चाहिए।
• तैनाती कोड: हम एंटिटी फ्रेमवर्क का उपयोग करते हैं, इसलिए प्रत्येक स्कीमा परिवर्तन को स्वचालित रूप से प्रत्येक डेटाबेस में नई रिलीज़ के साथ रोल आउट किया जाएगा। यह सच है, हालांकि, अगर हम उत्पादन में एक प्रदर्शन के मुद्दे की खोज करते हैं जो कि एक साधारण इंडेक्स ट्वीक के साथ तय किया जा सकता है, तो बस इसे बाहर धकेलना इतना आसान नहीं है। दूसरी ओर, प्रत्येक डेटाबेस इतना छोटा होने के साथ, यह संभावना नहीं है कि उत्पादन शार्क पर शोस्टॉपर के प्रदर्शन के मुद्दे होंगे। और सामान्य डेटाबेस एक ही DB रहता है, जिस पर ये चिंताएं लागू नहीं होती हैं।

अगर आपको लगता है कि मुझे कुछ याद आ रहा है, तो मुझे टिप्पणियों में आपसे वापस सुनने में खुशी होगी!

Comments

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

— जे ज़ेलोस

मेरा मानना ​​है कि आज की डीबी तकनीक का उपयोग करने से 'शार्किंग ’के लगभग सभी कारण वैध नहीं रह जाते हैं। मेरा मानना ​​है कि आप इसे या तो सड़क पर पछतावा करेंगे या शायद यह भी महसूस नहीं करेंगे कि आप तुलनात्मक रूप से कितने बुरे हैं और इसलिए इसे पछतावे से नहीं पछताएं। मैं मैक्स के जवाब से सहमत हूं और इसे किसी भी बेहतर तरीके से नहीं समझा सका।

— जो