मैं उपलब्ध विकल्पों पर बहुत कुछ पढ़ रहा हूं। मुझे हाई परफॉर्मेंस MySQL 2nd एडिशन पर भी हाथ मिला है, जिसकी मैं अत्यधिक अनुशंसा करता हूं।
यही वह है जिसे मैं एक साथ मिलाने में कामयाब रहा:
क्लस्टरिंग
सामान्य अर्थों में क्लस्टरिंग कई सर्वरों में लोड वितरित कर रहा है जो एक बाहरी एप्लिकेशन को एक सर्वर के रूप में दिखाई देते हैं।
MySQL NDB क्लस्टर
MySQL NDB क्लस्टर सिंक्रोनस प्रतिकृति और स्वचालित डेटा विभाजन के साथ एक वितरित, इन-मेमोरी, साझा-कुछ भी नहीं स्टोरेज इंजन है (क्षमा करें, मैं उच्च प्रदर्शन पुस्तक से सचमुच उधार लेता हूं, लेकिन उन्होंने इसे बहुत अच्छी तरह से रखा है)। यह कुछ अनुप्रयोगों के लिए एक उच्च प्रदर्शन समाधान हो सकता है, लेकिन वेब एप्लिकेशन आमतौर पर इस पर अच्छी तरह से काम नहीं करता है।
बड़ी समस्या यह है कि बहुत ही सरल प्रश्नों (जो केवल एक तालिका को स्पर्श करते हैं) से परे, क्लस्टर को आम तौर पर कई नोड्स पर डेटा की खोज करनी होगी, जिससे नेटवर्क विलंबता में कमी आएगी और प्रश्नों के लिए पूरा होने का समय काफी धीमा हो जाएगा। चूंकि एप्लिकेशन क्लस्टर को एक कंप्यूटर के रूप में मानता है, इसलिए यह यह नहीं बता सकता कि किस नोड से डेटा प्राप्त करना है।
इसके अलावा, कई बड़े डेटाबेस के लिए इन-मेमोरी आवश्यकता व्यावहारिक नहीं है।
निरंतर सिकोइया
यह MySQL के लिए एक और क्लस्टरिंग समाधान है, जो MySQL सर्वर के शीर्ष पर एक मिडलवेयर के रूप में कार्य करता है। यह तुल्यकालिक प्रतिकृति, लोड संतुलन और विफलता प्रदान करता है। यह यह भी सुनिश्चित करता है कि अनुरोध हमेशा नवीनतम प्रति से डेटा प्राप्त करें, स्वचालित रूप से एक नोड का चयन करें जिसमें ताजा डेटा हो।
मैंने कुछ अच्छी बातें पढ़ी हैं इस पर, और कुल मिलाकर यह काफी आशाजनक लगता है।
फेडरेशन
फेडरेशन क्लस्टरिंग के समान है, इसलिए मैंने इसे यहां भी टग किया। MySQL फ़ेडरेटेड स्टोरेज इंजन के माध्यम से फ़ेडरेशन प्रदान करता है। NDB क्लस्टर समाधान के समान, यह केवल साधारण प्रश्नों के साथ अच्छा काम करता है - लेकिन जटिल प्रश्नों के लिए क्लस्टर और भी बदतर (क्योंकि नेटवर्क विलंबता बहुत अधिक है)।
प्रतिकृति और लोड संतुलन
MySQL में विभिन्न सर्वरों पर डेटाबेस की प्रतिकृति बनाने की अंतर्निहित क्षमता है। इसका उपयोग कई चीजों के लिए किया जा सकता है - सर्वर के बीच लोड को विभाजित करना, हॉट बैकअप, टेस्ट सर्वर बनाना और फेलओवर।
प्रतिकृति के मूल सेटअप में एक मास्टर सर्वर शामिल होता है जो ज्यादातर लिखता है और एक या एक से अधिक दास हैंडलिंग केवल पढ़ता है। एक अधिक उन्नत विविधता है मास्टर-मास्टर कॉन्फ़िगरेशन, जो एक ही समय में कई सर्वर लिखने के साथ-साथ लिखने को स्केल करने की अनुमति देता है।
प्रत्येक कॉन्फ़िगरेशन में इसके पेशेवरों और विपक्ष हैं, लेकिन एक समस्या जो वे सभी साझा करते हैं वह है प्रतिकृति अंतराल - चूंकि MySQL प्रतिकृति अतुल्यकालिक है, सभी नोड्स में हर समय सबसे ताज़ा डेटा नहीं होता है। इसके लिए एप्लिकेशन को प्रतिकृति के बारे में पता होना चाहिए और अपेक्षित रूप से काम करने के लिए प्रतिकृति-जागरूक प्रश्नों को शामिल करना चाहिए। कुछ अनुप्रयोगों के लिए यह कोई समस्या नहीं हो सकती है, लेकिन यदि आपको हमेशा नवीनतम डेटा की आवश्यकता होती है तो चीजें कुछ जटिल हो जाती हैं।
प्रतिकृति को नोड्स के बीच लोड को विभाजित करने के लिए कुछ लोड संतुलन की आवश्यकता होती है। यह एप्लिकेशन कोड में कुछ संशोधनों, या समर्पित सॉफ़्टवेयर और हार्डवेयर समाधानों का उपयोग करने जितना आसान हो सकता है।
शेयरिंग और पार्टिशनिंग
डेटाबेस समाधानों को स्केल करने के लिए साझाकरण आमतौर पर उपयोग किया जाने वाला दृष्टिकोण है। आप डेटा को छोटे टुकड़ों में विभाजित करते हैं और उन्हें विभिन्न सर्वर नोड्स में फैलाते हैं। इसके लिए आवश्यक है कि एप्लिकेशन को डेटा संग्रहण में संशोधन के बारे में पता होना चाहिए ताकि वह कुशलता से काम कर सके, क्योंकि उसे यह जानने की आवश्यकता है कि उसे आवश्यक जानकारी कहां मिलनी है।
डेटा शार्डिंग से निपटने में सहायता के लिए एब्स्ट्रैक्शन फ्रेमवर्क उपलब्ध हैं, जैसे हाइबरनेट शार्ड्स , हाइबरनेट ओआरएम का विस्तार (जो दुर्भाग्य से जावा में है। मैं PHP का उपयोग कर रहा हूं)। HiveDB एक और ऐसा समाधान है जो शार्प रीबैलेंसिंग का भी समर्थन करता है।
अन्य
स्फिंक्स
Sphinx एक पूर्ण-पाठ खोज इंजन है, जिसका उपयोग परीक्षण खोजों से कहीं अधिक के लिए किया जा सकता है। कई प्रश्नों के लिए यह MySQL (विशेष रूप से समूहीकरण और छँटाई के लिए) की तुलना में बहुत तेज़ है, और दूरस्थ सिस्टम को समानांतर में क्वेरी कर सकता है और परिणामों को एकत्रित कर सकता है - जो इसे शार्किंग के उपयोग में बहुत उपयोगी बनाता है।
सामान्य तौर पर स्फिंक्स का उपयोग अन्य स्केलिंग समाधानों के साथ किया जाना चाहिए ताकि अधिक उपलब्ध हार्डवेयर और बुनियादी ढांचे को प्राप्त किया जा सके। नकारात्मक पक्ष यह है कि फिर से आपको स्फिंक्स का बुद्धिमानी से उपयोग करने के लिए जागरूक होने के लिए एप्लिकेशन कोड की आवश्यकता है।
सारांश
स्केलिंग समाधान उस एप्लिकेशन की ज़रूरतों के आधार पर भिन्न होते हैं जिन्हें इसकी आवश्यकता होती है। हमारे लिए और अधिकांश वेब-अनुप्रयोगों के लिए, मेरा मानना है कि प्रतिकृति (शायद मल्टी-मास्टर) लोड को वितरित करने वाले लोड बैलेंसर के साथ जाने का तरीका है। क्षैतिज रूप से स्केल करने में सक्षम होने के लिए विशिष्ट समस्या क्षेत्रों (विशाल तालिकाओं) को साझा करना भी आवश्यक है।
मैं कॉन्टिनेंट सिकोइया को भी एक शॉट देने जा रहा हूं और देखूंगा कि क्या यह वास्तव में वह कर सकता है जिसका वह वादा करता है क्योंकि इसमें एप्लिकेशन कोड में कम से कम बदलाव शामिल होंगे।
