एक बड़ा डेटाबेस बनाम कई छोटे लोग

Question

हमारे पास एक स्थिति यह है कि हम (ए) एक MySQL डाटाबेस में एक एप्लिकेशन के इंस्टेंस को टेबल प्रीफिक्सिंग का उपयोग करके तैनात कर सकते हैं या (बी) एप्लिकेशन के प्रत्येक उदाहरण के लिए विभिन्न MySQL डेटाबेस का उपयोग कर सकते हैं, उदाहरण के लिए,

तय करो":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

अंतिम परिणाम कई तालिकाओं के साथ एक बड़ा DB है।

सेटअप "बी":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

अंतिम परिणाम कुछ तालिकाओं के साथ कई डेटाबेस हैं।

सभी चीजें समान हैं (उदाहरण के लिए, डेटा की मात्रा, ऐप इंस्टेंस की संख्या, आदि) या तो दृष्टिकोण के साथ जाने के पेशेवरों और विपक्ष क्या हैं? डेटाबेस प्रदर्शन और रखरखाव के लिए हानिकारक क्या होगा? आवेदन PHP 5 आधारित है, Apache 2.x पर चलता है, और हम MySQL 5.x चला रहे हैं।

आपके समय और विचारों के लिए बहुत धन्यवाद!

Comments

संबंधित: dba.stackexchange.com/questions/4547/…

— डेरेक डाउनी

संबंधित: dba.stackexchange.com/questions/1043/…

— RolandoMySQLDBA

यह देखते हुए कि MySQL "डेटाबेस" वास्तव में स्कीमा (यानी नेमस्पेस) हैं, प्रदर्शन में कोई अंतर नहीं होगा, केवल रखरखाव में।

— मटियाको

Answer 1

मैंने कई सर्वरों में फैले एक हजार डेटाबेस के सर्वश्रेष्ठ भाग के साथ एक प्रणाली चलाई। वे सभी एक समान संरचना थे और एक टेम्पलेट डेटाबेस के साथ सिंक्रनाइज़ किए गए थे जो प्रत्येक मशीन पर थे।

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

इसके बारे में महान बात यह है कि, आप सर्वर को अपनी गति से कॉन्फ़िगरेशन में जोड़ सकते हैं, जैसा कि प्रत्येक सर्वर ओवर-लोड होने लगता है, मिक्स में एक और जोड़ें, नए सर्वर में कुछ डीबी माइग्रेट करें और अच्छी तरह से समाप्त करें सर्वर का संतुलित सेट लोड करें। एक बहुत अच्छा और सरल तरीका है सिस्टम में पैमाने को जोड़ना और जब यह आवश्यक है!

जिस कारण मैं एकल विशाल डेटाबेस दृष्टिकोण के बजाय इस दृष्टिकोण के साथ गया था, वह संभावित डेटाबेस का विशाल आकार था जो बनाया गया होगा ... 1000 डेटाबेस में से प्रत्येक में 200 टेबल थे, और प्रत्येक के भीतर कई व्यक्तिगत टेबल थे। डेटाबेस में लाखों लोग शामिल थे डेटा पंक्तियाँ शामिल थीं!

एक एकल डेटाबेस कॉन्फ़िगरेशन में डेटा की बहु-अरब पंक्तियों के लिए कुछ तालिकाओं (उनमें से 8) की आवश्यकता होगी, और कुल db आकार 10Tb से अधिक रहा होगा। हम 5Tb के साथ कई सर्वरों को सक्षम करने में सक्षम थे RAID 10 भंडारण, प्रत्येक पर कई डेटाबेस के साथ।

यही तो मैं करता! आशा है कि यह आपके निर्णय लेने में मदद करता है ... :)

Comments

अच्छा जवाब !!! +1 !!!

— RolandoMySQLDBA

@DaveRix - आप बिना डाउनटाइम के नए सर्वर पर कैसे माइग्रेट करेंगे?

— प्रतीक बोथरा

@ pratik-Bothra - सौभाग्य से यह कोई समस्या नहीं थी, क्योंकि हमारे क्लाइंट का कार्यभार बहुत अधिक व्यावसायिक घंटे था, और हम उन सभी माइग्रेशन को घंटों के लिए करने में सक्षम थे। इस तरह के रूप में कोई 'डाउनटाइम' नहीं है, लेकिन प्रवास के दौरान उस ग्राहक के लिए कोई पहुंच नहीं है

— डेव रिक्स

क्या होगा यदि आपको उन हजार डेटाबेस में से प्रत्येक के लिए डेटा संरचना को बदलना पड़ा? क्या वो गांड में असली दर्द नहीं था?

— विंसेंट

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

— डेव रिक्स

Answer 2

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

मल्टी-टेनेंट डेटा आर्किटेक्चर पर Microsoft द्वारा इस महान श्वेत पत्र को भी देखें

यह आपके द्वारा बताए गए दृष्टिकोणों के फायदे / नुकसान को भी उजागर करता है।

Comments

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

— कोस्टा कोंन्टोस

Answer 3

सेटअप बी का प्रबंधन करना आसान है

प्रत्येक tablenअलग फ़ोल्डर में बैठता है। यदि आप ओएस सीमा का परीक्षण नहीं करना चाहते हैं तो यह बहुत फायदेमंद हो सकता है ।

उदाहरण के लिए, मेरा नियोक्ता कार डीलरशिप की सीआरएम प्रणाली के लिए MySQL की मेजबानी करता है। क्लाइंट के पास 800 डीलरशिप हैं। प्रत्येक डीलरशिप डेटाबेस में 160 टेबल हैं। यह 128,000 टेबल है।

• सेटअप ए के तहत, सभी 128,000 टेबल एक डेटाबेस के तहत बैठेंगे।
• सेटअप बी के तहत, 160 तालिकाओं का प्रत्येक सेट एक सबफ़ोल्डर में / var / lib / mysql के नीचे बैठता है।

ओएस के परिप्रेक्ष्य और आई-नोड्स (या विंडोज के लिए एफएटी टेबल) को संभालने की क्षमता से, जिसमें प्रति फ़ोल्डर में अधिकतम संख्या में फाइलें शामिल हैं:

• सेटअप ए के तहत, आप एक फ़ोल्डर के तहत 128,000 फ़ाइलों के बारे में चिंता करेंगे। क्या आपका OS एकल फ़ोल्डर के तहत कई फाइलों का समर्थन कर सकता है?
• सेटअप बी के तहत, ऐसी कोई चिंता नहीं।

यदि आपको ALTER TABLEडीडीएल या किसी अन्य डीडीएल का उपयोग करके टेबल संरचनाओं को बदलना पड़ा है :

• सेटअप ए के तहत, आपको इसे एक्सेस करने और परिवर्तन करने से पहले विशिष्ट तालिका के नाम और संबंधित प्रश्नों के खिलाफ PHP (या विशेष MySQL स्क्रिप्ट) का उपयोग करके आवश्यक DDL स्क्रिप्ट करना होगा।
• सेटअप बी के तहत, दाएं डेटाबेस से कनेक्ट करें, फिर हर बार उसी नामित तालिका तक पहुंचें। पहुंच प्रतिमान हमेशा साफ रहेगा:
  • विशिष्ट डेटाबेस
  • के तहत विशिष्ट फ़ोल्डर /var/lib/mysql
  • विशिष्ट तालिका नाम।

यदि आप अलग-अलग डेटाबेस को अलग-अलग डिस्क पर रखना चाहते हैं:

• सेटअप ए के तहत, एक अलग डिस्क पर ले जाया गया हर टेबल के लिए सीमलिंक केवल "फ़ोल्डर में इनोड की संख्या" को बढ़ा देगा। डिस्क I / O और समग्र तालिका पहुंच अधिक जटिल हो जाती है और समग्र सर्वर लोड बढ़ जाती है क्योंकि .frmफाइलें बार-बार पहुंचती हैं।
• सेटअप बी के तहत, बस एक पूरे डेटाबेस फ़ोल्डर को एक अलग डेटा माउंट में स्थानांतरित करें। डिस्क I / O मांग पर वितरित किया जा सकता है।
• गुफा: अत्यधिक InnoDB के लिए हतोत्साहित किया गया

रूपक से बोलते हुए, जो आप बल्कि होगा?

• एक बेडरूम, एक बाथरूम और एक रसोईघर (सेटअप) के साथ एक विशाल अपार्टमेंट
• कई अपार्टमेंट, प्रत्येक अपने स्वयं के बेडरूम, बाथरूम और रसोई (SetupB) के साथ

जब एक अपार्टमेंट में रेडिएटर को ठीक करने की बात आती है:

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

IHMO यद्यपि बजट डिजाइन / अवसंरचना निर्णयों के लिए एक प्रेरक शक्ति हो सकता है, मैं आसानी से प्रति ग्राहक अलग डेटाबेस के पक्ष में होगा।

Answer 4

मेरे पास एक सास उत्पाद भी है और डेव रिक्स के रूप में उसी सेटअप का उपयोग करें।

प्रत्येक ग्राहक का अपना डेटाबेस होता है

मैं कुछ और सुझाव देता हूँ:

• आपके पास एक डेटाबेस "नियंत्रक" लोड-संतुलित (मास्टर-मास्टर) होना चाहिए, जो डेटाबेस स्थान (आईपी), डेटाबेस नाम और ग्राहक नाम को संग्रहीत करता है। यह नियंत्रक वह है जहां आपका एप्लिकेशन जानता है कि प्रत्येक ग्राहक डेटाबेस कहां है।

• आपका आवेदन कहीं भी हो सकता है - आप दुनिया भर के कई डेटासेन्टर्स के लिए डेटाबेस रख सकते हैं।

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

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

• आप दो वेब फ़ार्म + डेटाबेस फ़ार्म सेट कर सकते हैं: एक "EDGE" के लिए और दूसरा "STABLE" रिलीज़ के लिए। फिर, आपको ग्राहकों का एक छोटा समूह होना चाहिए जो चीजों का परीक्षण करने और यह पुष्टि करने के लिए तैयार हों कि सब कुछ अपेक्षित है (दूसरे शब्दों में, गुणवत्ता आश्वासन [QA]), इससे पहले कि आप अपने सभी ग्राहकों पर लागू होते हैं।

• आपको प्रति दिन कम से कम एक बार प्रति डेटाबेस में एक स्वचालित बैकअप कार्य होना चाहिए।

• आपके पास प्रतिकृति करने के लिए एक और सर्वर होना चाहिए। यदि आप "मास्टर" और "दास" होस्ट सर्वरों की समान राशि का वहन नहीं कर सकते हैं तो एक ही होस्ट कई डेटाबेस (प्रत्येक होस्ट के लिए अलग-अलग पोर्ट का उपयोग कर सकता है) को दोहरा सकता है।

  उदाहरण के लिए, 5 मास्टर सर्वर + 1 दास सर्वर 5 डेटाबेस के साथ अलग-अलग बंदरगाहों पर चल रहे हैं - बस इसके लिए रैम पर्याप्त है।

• आपको एक डेटाबेस को किसी भी अन्य सर्वर पर ले जाने के लिए "माइग्रेशन" टूल करना चाहिए।

• अपने राजस्व को सुरक्षित रखने के लिए आपको VIP ग्राहकों को अधिक सुरक्षित / उपलब्ध डेटाबेस सर्वर पर माइग्रेट करना चाहिए। याद रखें, कई बार 20% ग्राहक आपके राजस्व का 80% प्रतिनिधित्व करते हैं। विशेष ग्राहकों का ध्यान रखें।

• जब कोई ग्राहक आपकी कंपनी छोड़ता है, तो आपके पास "अंतिम बैकअप" करने और डेटाबेस को हटाने के लिए एक बैकअप-डिलीट "कचरा" कलेक्टर होना चाहिए।

• आपके पास एक डेटाबेस छवि होनी चाहिए जहां आप नए खातों के लिए निर्यात और उपयोग करते हैं।

• आपके पास मौजूदा खातों में नए पैच लगाने के लिए एक डेटाबेस पैचिंग टूल होना चाहिए।

• अपने सभी एसक्यूएल पैच के संस्करणों को रखें, तोड़फोड़ या गिट जैसे संस्करण टूल का उपयोग करके और अपनी खुद की नंबरिंग भी बनाएं। xxx-4.3.0.sql - कभी-कभी पैचिंग गलत हो जाती है और आपको पता होना चाहिए कि कैसे कार्य को पूरा करना है।

ठीक है, यह सब मैं अपनी कंपनी में एक उत्पाद के साथ करता हूं जिसमें लगभग 5k डेटाबेस है जिसमें लगभग 600 टेबल हैं।