कृपया ध्यान दें: मैं SQL सर्वर के दृष्टिकोण से उत्तर दे रहा हूं, इसलिए मैं SQL सर्वर के लिए विशिष्ट कुछ अवधारणाओं का उल्लेख करता हूं, लेकिन मेरा मानना है कि इन सभी अवधारणाओं में समान लाभ और सीमाओं के साथ अन्य प्रमुख RDBMS प्लेटफार्मों में समकक्ष हैं।
मैं संभवतः इस उत्तर को संपादित करना जारी रखूंगा क्योंकि मैं अन्य संभावित पेशेवरों / विपक्षों के बारे में सोचता हूं।
खैर, यह वास्तव में स्कीमा, वॉल्यूम, आदि पर निर्भर करता है कि वास्तव में दुकान का भंडारण क्या है? यह 50,000 बिल्लियों या 50,000 उत्पादों या 50,000 विंगनॉट के डेटा को संग्रहीत करने से कैसे अलग है?
कई कारण हैं (केवल अपने आप में आकार के पहलू के अलावा) आप एक ही डेटाबेस में 50,000 विभिन्न ग्राहकों के लिए डेटा स्टोर क्यों नहीं करना चाहते हैं, यदि वास्तव में डेटा को ग्राहक द्वारा पूरी तरह से अलग किया जा सकता है (न कि लुकअप टेबल जैसे ज़िपकोड या अनुप्रयोग-विशिष्ट तालिकाएँ, जो एकल, केंद्रीय डेटाबेस में जा सकती हैं):
यदि कोई ग्राहक एप्लिकेशन को आगे बढ़ाता है, तो उसके डेटा को निकालने और उसे स्केल करने के लिए किसी अन्य उदाहरण, सर्वर आदि पर ले जाने का कोई आसान तरीका नहीं है, जब तक कि आप आगे की योजना नहीं बनाते हैं CustomerIDऔर जैसे 50,000 फ़ाइलग्रुप हैं (आप सीमित हैं) यदि आप SQL सर्वर के पुराने संस्करण पर हैं, तो वैसे भी 15,000 विभाजन या 1,000 हो सकते हैं, और बहुत सारे फ़ाइलग्रुप होना विनाशकारी हो सकता है )। यह भी ध्यान दें कि विभाजन के लिए एंटरप्राइज़ संस्करण की आवश्यकता होती है।
यदि यह पता चलता है कि आपके सभी ग्राहक इस उदाहरण के लिए बहुत बड़े हैं, तो नए हार्डवेयर प्राप्त करने और पूरे डेटाबेस को वहां ले जाने का मतलब है (और संभवतः फिर से सड़क को नीचे करना)।
ग्राहक को हटाना समान रूप से दर्दनाक हो सकता है, क्योंकि आपको बहुत बड़ी तालिकाओं से कुछ% पंक्तियों को हटाना होगा, और यह सस्ता नहीं होगा।
आपके पास संभवतः ग्राहक डेटा (एक बिलियन पंक्तियों वाला एक ग्राहक, 5,000 के साथ एक अन्य ग्राहक) का व्यापक वितरण होगा। यह कार्डिनैलिटी और प्लान क्वालिटी से जुड़े पैरामीटर सूँघने और हानिकारक प्रदर्शन जैसी चीज़ों को जन्म दे सकता है (क्योंकि आप संभवतः अलग-अलग डेटा सेट के खिलाफ समान प्रश्नों के लिए समान योजनाओं का फिर से उपयोग कर रहे होंगे)।
आपके सभी ग्राहक ठीक उसी SLAs और HA / DR योजनाओं के अधीन हैं। आपके पास पूरे डेटाबेस में एन-मिनट लॉग बैकअप के साथ पूर्ण पुनर्प्राप्ति मोड है, या आप सरल हैं और पूर्ण + भिन्न बैकअप पर भरोसा करते हैं। यदि आपको ग्राहक की त्रुटि के कारण वापस जाना है, या डेटाबेस को एक समय में पुनर्प्राप्त करने की आवश्यकता है, तो यह हर एक ग्राहक को प्रभावित करता है।
डेटा पुनर्प्राप्ति में त्रुटियों की संभावना है - जहां क्लॉस में बग, उदाहरण के लिए, एक ग्राहक को किसी अन्य ग्राहक के डेटा या अन्य सभी ग्राहकों के डेटा को देखने के लिए नेतृत्व कर सकता है ।
कानूनी निहितार्थ हो सकते हैं (कुछ कंपनियों की जगह में सख्त आवश्यकता होगी कि आप अपना डेटा उसी डेटाबेस में किसी अन्य कंपनी और विशेष रूप से अपने प्रतिस्पर्धियों के स्थान पर न रखें)।
यदि किसी एक ग्राहक के डेटा की सुरक्षा महत्वपूर्ण है, तो डेटाबेस टेबल से अलग होने की तुलना में इसे प्राप्त करना बहुत आसान है।
प्रत्येक ग्राहक को एक अलग डेटाबेस में (या कम से कम कई डेटाबेस, प्रत्येक ग्राहकों के समूह के लिए) होने के कुछ फायदे:
- आकार के संदर्भ में, यह डिस्क पर समान आकार के बारे में ले जाएगा।
- स्केलिंग करना आसान है, क्योंकि आप एक डेटाबेस (या कई) को एक अलग सर्वर पर स्थानांतरित कर सकते हैं।
- एक ग्राहक को हटाना और उसका सारा डेटा लगभग बराबर हो जाता है
DROP DATABASE।
- आप योजनाओं के लिए अधिक मेमोरी का उपयोग कर रहे हैं (या आपके पास प्रति ग्राहक कैश में कम योजनाएँ हैं), लेकिन कम से कम वे योजनाएँ उनके संबंधित डेटाबेस में डेटा के लिए प्रासंगिक हैं और आंकड़ों / पैरामीटर के मुद्दों को सूँघने के लिए कम हैं।
- आप आसानी से अलग SLAs और DR प्लान कर सकते हैं, कुछ डेटाबेस को पूर्ण और अन्य को सरल में रखकर। इसके अलावा किसी समय में किसी ग्राहक को प्रभावित करने या बहाल करने से उस ग्राहक पर असर पड़ता है।
- आप आसानी से अलग-अलग डेटाबेस (कहते हैं, अपने उच्च प्राथमिकता वाले ग्राहक) को तेजी से I / O पर रख सकते हैं। आप इसे फाइलग्रुप्स के साथ एक ही डेटाबेस में कर सकते हैं, लेकिन इसे प्रबंधित करने के लिए बहुत पेचीदा है (कम से कम IMHO)।
कुछ कमियां:
- एक तरफ आकार, आप शायद SQL सर्वर के एक ही उदाहरण पर 50,000 डेटाबेस नहीं रखना चाहेंगे, तो इसका मतलब होगा कि कई सर्वरों को स्केल करना होगा।
- स्टार्टअप का समय बढ़ जाता है क्योंकि प्रत्येक डेटाबेस को शुरू करने में कुछ अंतर्निहित ओवरहेड होता है।
- एप्लिकेशन को थोड़ा होशियार होना चाहिए - जहां क्लाज पर केवल CustomerID होने के बजाय, इसे गतिशील रूप से CustomerID के डेटाबेस से कनेक्ट करना होगा। यह एक उचित मध्य स्तरीय के साथ कठिन नहीं है लेकिन यह एक बदलाव है।
- हां, आपके पास समान टेबलों और प्रक्रियाओं की कई प्रतियां हैं, लेकिन कोड और स्कीमा डेटाबेस में समान हैं, बस डेटा अलग है। इसलिए कोड / स्कीमा परिवर्तन को लागू करना अब केवल एक निष्पादन के बजाय एक लूप है।
- जब आप 50,000 डेटाबेस का प्रबंधन कर रहे होते हैं तो रखरखाव थोड़ा अलग होता है - फिर से समग्र आकार लगभग समान होता है लेकिन प्रक्रिया को बदलना पड़ता है - आप एक ही बार में सभी 50,000 डेटाबेस को डीफ़्रैग / रींडेक्स / बैक अप नहीं कर सकते। यह कहते हुए कि, मैंने अपनी पिछली नौकरी में 500-1,000 समान डेटाबेस के साथ इंस्टेंसेस प्रबंधित किए, और 3 समान डेटाबेस और 750 समान डेटाबेस के प्रबंधन के बीच का अंतर केवल समय लगता है।