MySQL के लिए स्केलिंग समाधान (प्रतिकृति, क्लस्टरिंग)


83

जिस स्टार्टअप पर मैं काम कर रहा हूं, अब हम अपने डेटाबेस के लिए समाधानों पर विचार कर रहे हैं। MySQL के साथ चीजें कुछ हद तक भ्रामक (मेरे लिए कम से कम) हो जाती हैं, जिसमें MySQL क्लस्टर , प्रतिकृति और MySQL क्लस्टर प्रतिकृति (ver। 5.1.6 से) है, जो MySQL क्लस्टर का एक अतुल्यकालिक संस्करण है। MySQL मैनुअल अपने क्लस्टर FAQ में कुछ अंतरों के बारे में बताता है , लेकिन एक या दूसरे का उपयोग करने के लिए यह पता लगाना कठिन है।

मैं उन लोगों से किसी भी सलाह की सराहना करूंगा जो उन समाधानों के बीच अंतर से परिचित हैं और पेशेवरों और विपक्षों के बीच क्या अंतर है, और आप प्रत्येक का उपयोग करने की सलाह कब देते हैं।


4
2015 में इसी प्रश्न का उत्तर क्या है?
मैट्रिक

हैलो, प्रोग्रामिंग के बारे में क्या है, मेरा मतलब है कि अगर मैं इसे अपने PHP आधारित अनुप्रयोग के लिए कर रहा हूं, तो क्या विशिष्ट चीजों की कोई सूची है जो मुझे कोड लिखते समय ध्यान रखने की आवश्यकता है? या इससे कोई फर्क नहीं पड़ता?
सलिल मोमिन

2017 में, MariaDB, Galera और MariaDB MaxScale पर एक नज़र डालें।
मैटबियनको

जवाबों:


102

मैं उपलब्ध विकल्पों पर पढ़ने का एक बहुत कुछ कर रहा हूँ। मुझे उच्च प्रदर्शन MySQL 2 के संस्करण में भी हाथ मिला, जिसकी मैं अत्यधिक अनुशंसा करता हूं।

यह वही है जो मैंने एक साथ करने में कामयाब रहा है:

क्लस्टरिंग

सामान्य अर्थों में क्लस्टरिंग कई सर्वरों पर लोड वितरित कर रहा है जो एक सर्वर के रूप में एक बाहरी अनुप्रयोग को दिखाई देते हैं।

MySQL NDB क्लस्टर

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

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

इसके अलावा, कई बड़े डेटाबेस के लिए इन-मेमोरी आवश्यकता व्यावहारिक नहीं है।

निरंतर सेक्विया

यह MySQL के लिए एक और क्लस्टरिंग समाधान है, जो MySQL सर्वर के शीर्ष पर एक मिडलवेयर के रूप में कार्य करता है। यह तुल्यकालिक प्रतिकृति, भार संतुलन और विफलता प्रदान करता है। यह यह भी सुनिश्चित करता है कि अनुरोधों को हमेशा नवीनतम प्रति से डेटा प्राप्त होता है, स्वचालित रूप से एक नोड का चयन होता है जिसमें ताजा डेटा होता है।

मैंने इस पर कुछ अच्छी बातें पढ़ी हैं , और कुल मिलाकर यह बहुत अच्छा लग रहा है।

फेडरेशन

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

प्रतिकृति और लोड संतुलन

MySQL में विभिन्न सर्वरों पर डेटाबेस की प्रतिकृति बनाने की क्षमता है। इसका उपयोग कई चीजों के लिए किया जा सकता है - सर्वर, हॉट बैकअप के बीच लोड को विभाजित करना, टेस्ट सर्वर और फेलओवर बनाना।

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

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

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

साझेदारी और विभाजन

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

Hibernate Shards , Hibernate ORM (जो दुर्भाग्य से जावा में है। मैं PHP का उपयोग कर रहा हूँ) के विस्तार के साथ डेटा की सहायता से निपटने के लिए अमूर्त रूपरेखाएँ उपलब्ध हैं । HiveDB एक और ऐसा समाधान है जो शार्क के असंतुलन का भी समर्थन करता है।

अन्य

गूढ़ व्यक्ति

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

सामान्य स्फिंक्स में अन्य स्केलिंग समाधानों के साथ उपयोग किया जाना चाहिए ताकि उपलब्ध हार्डवेयर और बुनियादी ढांचे को अधिक प्राप्त किया जा सके। नकारात्मक पक्ष यह है कि फिर से आपको बुद्धिमानी से उपयोग करने के लिए स्फिंक्स के बारे में जानने के लिए एप्लिकेशन कोड की आवश्यकता होती है।

सारांश

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

मैं कंटीन्यू सीक्विया को एक शॉट भी देने जा रहा हूं और देख सकता हूं कि क्या यह वास्तव में वही कर सकता है क्योंकि इसमें एप्लीकेशन कोड में कम से कम बदलाव शामिल हैं।


4
मास्टर-मास्टर आपको लिखने की अनुमति नहीं देता है - दोनों स्वामी को सिंक में रहने के लिए सभी लेखन करना होगा। इसके अलावा, प्रतिकृति टकराव पैदा करने के लिए एक बार में दो सर्वरों पर लिखना संभवतया (अधिक या कम गारंटी वाला) है, जिसे mysql स्वचालित रूप से हल नहीं करता है।
MarkR

1
08 में लिखी गई इस प्रतिक्रिया को देखते हुए, अब 1 1 1/2 साल बाद, कॉन्टिनेंट सेक्विया का आपका परिणाम क्या है?
केरी जोन्स

1
परिणाम / अनुभव को निरंतर Sequoia के साथ साझा करने का मन है?
conandor

मैंने अंत में
कंटीन्यू सीक्विया का

कॉन्टिनेंट Sequoia को बंद कर दिया गया है और कॉन्टिनेंट टंगस्टन के साथ बदल दिया गया है, जो मुफ्त उत्पादों का एक संग्रह है। continuent.com/community/tungsten-overview
lo_fye

12

अस्वीकरण: मैंने MySQL क्लस्टर का उपयोग नहीं किया है, इसलिए मैं केवल वही सुन रहा हूं जो मैंने सुना है।

MySQL क्लस्टर एक हा (उच्च उपलब्धता) समाधान है। यह तेज़ है, क्योंकि यह सभी मेमोरी में है, लेकिन यह वास्तविक विक्रय बिंदु उपलब्धता है। असफलता का एक भी बिंदु नहीं है। दूसरी ओर, प्रतिकृति के साथ, यदि स्वामी नीचे चला जाता है, तो आपको वास्तव में प्रतिकृति पर स्विच करना होगा, और नीचे समय की एक छोटी राशि हो सकती है। (हालांकि DRBD समाधान एक और विकल्प है जिसमें उच्च उपलब्धता है)

क्लस्टर के लिए आवश्यक है कि आपका पूरा डेटाबेस मेमोरी में फिट हो। इसका मतलब है कि क्लस्टर में प्रत्येक मशीन को पूरे डेटाबेस को संग्रहीत करने के लिए पर्याप्त मेमोरी की आवश्यकता होती है। तो यह बहुत बड़े डेटाबेस के लिए संभव समाधान नहीं है (या कम से कम यह बहुत महंगा समाधान है)।

मुझे लगता है कि जब तक हा सुपर महत्वपूर्ण नहीं है (पढ़ें: शायद नहीं), यह अधिक परेशानी (और पैसा) है, जितना कि इसके लायक है। प्रतिकृति अधिक बार जाना बेहतर तरीका है।

संपादित करें: मैं यह भी उल्लेख करना भूल गया कि क्लस्टर विदेशी कुंजी की अनुमति नहीं देता है, और रेंज स्कैन अन्य इंजनों की तुलना में धीमी है। यहाँ एक लिंक है जो MySQL क्लस्टर की ज्ञात सीमाओं के बारे में बात करता है


ठीक है, मैं जिस बिंदु को बनाने की कोशिश कर रहा था वह यह है कि यदि आप प्रदर्शन के बारे में चिंतित हैं, तो प्रतिकृति के साथ जाएं। यदि एचए एक प्राथमिक चिंता है तो केवल क्लस्टर चुनें। मैं नहीं जानता कि वे कैसे तुलना करते हैं, और हार्डवेयर आवश्यकताएं इतनी भिन्न हैं कि यह शायद वैसे भी सेब और संतरे की तुलना कर रहा है।
नाथन

यह 4-5 साल बाद है, लेकिन मैं सिर्फ यह जोड़ना चाहूंगा कि MySQL क्लस्टर को पूरी मेमोरी को RAM / RAM में रखने की आवश्यकता नहीं है: "MySQL 5.1 से, डेटा को पूरी तरह से मेमोरी में होने की आवश्यकता नहीं है । " dba.stackexchange.com/questions/9357/…
टेड

4

इस बारे में कुछ अच्छी चर्चाएँ हैं कि कैसे drupal.org को बनाए रखने वाले लोगों ने अपने डेटाबेस सर्वर को संरचित किया है:

दोनों 2007 से हैं, इसलिए क्लस्टरिंग समर्थन अब और मजबूत हो सकता है, लेकिन उस समय उन्होंने प्रतिकृति को चुना।


2

प्रतिकृति करने के बारे में अच्छी बात यह है कि यह आसान है। बस 2 mysql बॉक्स सेट करें, दूसरे बॉक्स पर सर्वरआईडी को बदलें, और फिर कमांड मास्टर को कमांड का उपयोग करके पहले बॉक्स में दूसरा बॉक्स इंगित करें।

यहाँ प्रासंगिक नमूना गुलाम my.cnf विन्यास है

#
#       Log names
#

log-bin=binlog
relay-log=relaylog
log-error=errors.log

#
#       Log tuning
#

sync_binlog = 1
binlog_cache_size = 1M

#
#       Replication rules (what are we interested in listening for...)
#
#       In our replicants, we are interested in ANYTHING that isn't a permission table thing
#

replicate-ignore-db =      mysql
replicate-wild-ignore-table=mysql.%

#
#       Replication server ID
#

server-id      =        2

इसलिए सुनिश्चित करें कि प्रत्येक गुलाम को 1 के द्वारा बढ़ा हुआ सर्वरआईडी मिलता है (इसलिए अगला दास सर्वर 3 है)

एक उपयोगकर्ता नाम और पासवर्ड सेट करें, जो दास को कनेक्ट कर सकता है, फिर परिवर्तन मास्टर को MASTER_HOST = 'xxxx' पर चलाएं; MASTER_PASSWORD = "XXXXX" में मास्टर बदलें;

और इसी तरह।

अंत में, "गुलाम शुरू करो;"

ऊपर आपका दास आता है और नकल करना शुरू कर देता है। मीठा हुह!

यह मानता है कि आप 2 खाली सर्वरों से शुरू करते हैं। फिर आप अपने डीबी को मास्टर सर्वर में डंप कर सकते हैं, और जैसे ही यह वहां लोड होता है, यह दास पर भी लोड करेगा।

आप चलाकर दास की स्थिति की जाँच कर सकते हैं:

दास की स्थिति दिखाओ \ G

इसके साथ मज़े करो .. soooo आसान ...


1

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

मैसकल प्रतिकृति आपको एक बैकअप मशीन प्रदान कर सकती है जिसका उपयोग या तो पढ़ने वाले दास के रूप में किया जा सकता है या आपदा वसूली के मामले में उपयोग किया जा सकता है।

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

मैंने http://www.techiegyan.com/?p=132 पर DRBD क्लस्टर की स्थापना के दौरान किए गए कुछ सीखने को सूचीबद्ध करने की कोशिश की

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

मुझे DRBD पर मास्टर-मास्टर कॉन्फ़िगरेशन की खोज करना बाकी है। जब भी मुझे इसमें सफलता मिलेगी, अपडेट करूंगा।

धन्यवाद।


1

मेरे विचार में, यहाँ भ्रम मुझे वापस Mnesia भेजता है। अनुक्रमण को संभालने के विखंडन, घोषणात्मक और व्यावहारिक तरीके से, डेटाबेस रेप्लिका के आदि की पारदर्शिता

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

संक्षेप में, हम MySQL क्लस्टर के शीर्ष पर mnesia चलाते हैं। MySQL क्लस्टर बड़े डेटा सेट को संभाल सकता है, एक डेटाबेस 50GB से अधिक तक बढ़ सकता है। हमारे पास Erlang / OTP अनुप्रयोगों को शक्ति प्रदान करने वाले mnesia हैं । जावा और पीएचपी अनुरूप अधिक mnesia से डेटा ऐक्सेस बाकी (हाल ही में बचत विनिमय स्वरूपों के रूप में JSON और XML का उपयोग) एपीआई।

डेटा एक्सेस लेयर ने Mnesia में डेटा तक पहुंच को रोक दिया है और यदि आवश्यक हो तो MySQL क्लस्टर में पुराने शिप किए गए डेटा। Mnesia अनिवार्य रूप से Erlang / OTP अनुप्रयोगों को पावर करने के लिए है। हालांकि यह डेटा के साथ घुलमिल जाता है, हम इसे MYSQL क्लस्टर में फेंक देते हैं। सभी एप्लिकेशन की ओर से डेटा एक्सेस लेयर एक अमूर्त एपीआई में mnesia और MySQL दोनों डेटा का उपयोग कर सकती है।

मैं यहाँ क्या कह सकता हूँ कि मानेसिया हमारे लिए सबसे अच्छा विकल्प है। तालिकाओं को अत्यधिक खंडित और अनुक्रमित किया गया है, प्रश्न बहुत अच्छा प्रदर्शन करते हैं और डेटाबेस को 2 स्थानों पर दोहराया जाता है, जो एक सुरंग से जुड़ा होता है।

इससे पहले, हमें डर था कि टेबल आकार की सीमा के कारण मानेसिया कई रिकॉर्ड को संभाल नहीं सकते हैं। लेकिन हमने इस बयान को गलत पाया। अच्छी ट्यूनिंग (विखंडन) के साथ, हमारे मेनेसिया डेटाबेस प्रति वर्ष औसतन लगभग 250 मिलियन रिकॉर्ड बनाते हैं।

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

Mnesia ने हमारे लिए बहुत अच्छा काम किया है। Mnesia ने अपने रोमांचक प्रदर्शन के कारण डेटाबेस को देखने के तरीके को पूरी तरह से बदल दिया है। हमारे सोलारिस सर्वर सीपीयू कोर को औसतन पीक आवर्स में लगभग 48% उपयोग में व्यस्त रखा गया है।

मैं आपको मेन्सिया की जांच करने की सलाह देता हूं और जो जानता है, वह आपके वितरण या प्रतिकृति आवश्यकताओं के कई जवाब दे सकता है।


0

मैंने उनका उपयोग नहीं किया है, लेकिन डॉक्स से मैं कहूंगा कि प्रतिकृति पसंदीदा समाधान है अगर डेटाबेस से सबसे बड़ा लोड पढ़ रहा है।


1
आप वास्तव में इस निष्कर्ष पर कैसे आए ... यदि आप निर्दिष्ट करते हैं तो यह अच्छा होगा। डॉक्स भी संकेत देता है कि क्लस्टरिंग अधिक विश्वसनीय है
एरन गैपरिन

0

"मेमोरी में" सीमा हमारे लगभग 50Gb डेटा के लिए MySQL क्लस्टर का उपयोग करने से रोकती है, इसलिए हम DRBD प्लस लिनक्स हार्टबीट का उपयोग कर रहे हैं ।

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


1
क्या यह प्रदर्शन में मदद करता है या यह केवल अतिरेक के लिए है?
एरान गैपरिन

DRBD सब कुछ ठीक है और तब तक अच्छा है जब तक कि फाइलसिस्टम पर कुछ नहीं चढ़ता है और आपके टेबल को खराब कर देता है - तब आपके पास सिर्फ एक के बजाय टूटने के दो नोड होते हैं। मुझे इस पर भरोसा नहीं है।
जॉन टॉपर

+1 @ गैलेक्सिन फेलओवर / अतिरेक, इस प्रश्न पृष्ठ पर मेरी यात्रा का मुख्य कारण है, विचारों के लिए हमारी कंपनी प्रति साइट एक mysql सर्वर के लिए आंतरिक व्यवस्था लागू करना।
उपचार

0

MySQL क्लस्टर एक अजीब जानवर है और हर बार हमने मूल्यांकन किया है कि यह या तो बहुत खराब है या अविश्वसनीय है।

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

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

लेकिन मुझे वास्तव में लगता है कि यह बहुत ही विशेष प्रयोजन के मामलों के लिए बेहतर है जो इसके लिए डिज़ाइन किया गया था। यह ज्यादातर मामलों में प्रदर्शन या सुविधाओं में किसी अन्य डेटाबेस इंजन (जैसे InnoDB) को प्रतिस्थापित नहीं कर सकता है।


कई नाइनों का एक समाधान है जो इसे स्थापित करना आसान बनाता है: support.severalnines.com/entries/… ... लेकिन सहमत हूं, मैं अपनी कंपनी में MySQL क्लस्टर का मूल्यांकन कर रहा हूं, और इसके प्रसार के लिए महान लिखता है, लेकिन बहुत धीमा पढ़ता है, और कोई विदेशी कुंजी समर्थन नहीं है, आदि
सुमन

v7.3 के बाद से विदेशी कुंजी समर्थन उपलब्ध है । यहाँ InnoDB बनाम NDB
lennartvdd
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.