MySQL शेयरिंग बनाम MySQL क्लस्टर


13

केवल प्रदर्शन को ध्यान में रखते हुए , क्या MySQL क्लस्टर एक कस्टम डेटा को MySQL समाधान को हरा सकता है? sharding = क्षैतिज विभाजन

जब मैं तेज करने का संदर्भ देता हूं, तो मैं अनुप्रयोग लेयर में किए गए शीर्षलेख पर विचार कर रहा हूं, उदाहरण के लिए, स्वतंत्र MySQL उदाहरणों में समान रूप से रिकॉर्ड वितरित करना। दो सर्वरों के लिए, यह (कुंजी मॉड 2) हो सकता है।

जवाबों:


21

प्रकटीकरण: मैं एक MySQL कर्मचारी हूँ, MySQL क्लस्टर पर काम कर रहा हूँ।

मैं यह कहूंगा कि MySQL क्लस्टर, शार्प्ड MySQL + InnoDB से उच्चतर थ्रूपुट / होस्ट प्राप्त कर सकता है, बशर्ते कि:

  • प्रश्न सरल हैं
  • सभी डेटा स्मृति में फिट बैठता है

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

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

MySQL क्लस्टर वर्तमान में 48 से अधिक मेजबानों को 'शार्किंग' तक सीमित है। सिद्धांत में साझा MySQL की कोई सीमा नहीं है। हालाँकि, दिए गए लक्ष्य थ्रूपुट के लिए, MySQL क्लस्टर होस्ट की तुलना में कम MySQL क्लस्टर होस्ट की आवश्यकता हो सकती है।

जब आप प्रदर्शन के अलावा अन्य क्षेत्रों को देखते हैं तो अधिक दिलचस्प अंतर होते हैं:

  • MySQL क्लस्टर सभी शार्क के मनमाने प्रश्नों का समर्थन करता है
  • MySQL क्लस्टर सभी शार्क के मनमाने लेनदेन का समर्थन करता है
  • MySQL क्लस्टर स्वचालित विफलता और पुनर्प्राप्ति के साथ शार्क के तुल्यकालिक प्रतिकृति का समर्थन करता है
  • MySQL क्लस्टर ऑनलाइन ऐड नोड (क्लस्टर विस्तार) का समर्थन करता है
  • साझा MySQL अधिक 'अपना खुद का रोल' है

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

पिछले उत्तर के बारे में, कुछ स्पष्टीकरण:

"हालांकि MySQL क्लस्टर ACID- शिकायत है, यह यौगिक कुंजियों के साथ डेटा के लिए एक उपयुक्त भंडारण इंजन प्रदान नहीं करता है।"

MySQL क्लस्टर कंपाउंड प्राइमरी और सेकेंडरी कीज़ को सपोर्ट करता है। निश्चित नहीं है कि इसके बारे में 'उपयुक्त' क्या नहीं है। शायद पिछले पोस्टर की व्याख्या कर सकते हैं?

"डेटा नोड्स के एक विशेष सेट में संग्रहीत एक ही प्रमुख विशेषताओं के साथ डेटा रखने के लिए, आप निम्नलिखित कार्य कर सकते हैं:

  1. सभी डेटा नोड्स को ऑफ़लाइन ले जाएं, केवल उन डेटा नोड्स को छोड़ दें जिन्हें आप समान कुंजी विशेषताओं के साथ डेटा को घर में रखना चाहते हैं।
  2. अपने डेटा को MySQL क्लस्टर में लोड करें, जो केवल आपके चुनिंदा डेटा नोड्स को पॉप्युलेट करता है
  3. ऑनलाइन सभी डेटा नोड्स वापस लाएं "

यह गलत है। डेटा वितरण स्वतंत्र है जिसमें से नोड्स कभी भी ऑनलाइन होते हैं। MySQL क्लस्टर आपके द्वारा वर्णित अनुकूलन का समर्थन करने के लिए विभिन्न डेटा वितरण योजनाओं का समर्थन करता है। मैं यहां एक ब्लॉग पोस्ट में MySQL क्लस्टर में डेटा वितरण का वर्णन करता हूं: MySQL क्लस्टर में डेटा वितरण


अरे, फ़राज़ियर। मैंने आपके द्वारा दिए गए लिंक को पढ़ा। केवल क्लैरिफिकेशन के लिए, मेरी 'मिश्रित कुंजी' टिप्पणी गैर-अनूठे अनुक्रमों पर आधारित थी। मेरे नियोक्ता की कंपनी ने 2007-2015 के आसपास MySQL क्लस्टर की कोशिश की और खराब प्रदर्शन के कारण इसे पसंद नहीं किया। IMHO यह कुंजी (छोटी कार्डिनैलिटी) और उसके प्रश्नों के लिए ग्राहक की खराब पसंद थी। MySQL क्लस्टर तब से आपके लिंक के आधार पर अधिक परिपक्व होना चाहिए। मेरे दूसरे कथन के अनुसार, यह है कि कितने MongoDB उपयोगकर्ता विशिष्ट शार्क को आबाद करते हैं। मेरे नियोक्ता के कुछ ग्राहकों ने अपने कस्टम MySQL सेटअप के साथ ऐसा किया है।
रोलैंडमाइसीडीडीबीए

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

मेरे शेख़ी और बहकने के बदले में, आपके जवाब के लिए +1 !!!
रोलैंडमाइसीडीडीबीए

हाय रोलैंडो, अपने बयानों को स्पष्ट करने के लिए धन्यवाद। यह सच है कि क्लस्टर में नॉन-प्रूस्ड ऑर्डर किए गए इंडेक्स स्कैन 'महंगे' हैं, क्योंकि सभी डेटा नोड्स शामिल हैं। ऐसा लगता है कि कम कार्डिनिटी सूचकांकों पर ये स्कैन किसी भी सिस्टम पर महंगे होंगे, लेकिन क्लस्टर पर वे नेत्रहीन महंगे हो गए। आपकी सावधानी और निराशावाद में कोई संदेह नहीं है कि आपने एक से अधिक बार बचाया है :) +1 के लिए धन्यवाद
फ्रेज़र क्लेमेंट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.