MySQL टेबल को शार्प करने का सबसे अच्छा तरीका यह नहीं करना है जब तक कि इसे करना पूरी तरह से अपरिहार्य न हो।
जब आप कोई एप्लिकेशन लिख रहे होते हैं, तो आप आमतौर पर ऐसा करना चाहते हैं जिससे वेग, डेवलपर गति को अधिकतम किया जा सके। आप केवल आवश्यक होने पर विलंबता (उत्तर तैयार होने तक का समय) या थ्रूपुट (प्रति समय इकाई के उत्तरों की संख्या) के लिए अनुकूलित करते हैं।
आप विभाजन करते हैं और फिर अलग-अलग होस्ट (=shard) को विभाजन असाइन करते हैं, जब इन सभी विभाजनों का योग अब एक डेटाबेस सर्वर इंस्टेंस पर फिट नहीं होता है - इसका कारण या तो लिखता है या पढ़ता है।
लिखने का मामला या तो है a) लिखने की आवृत्ति इस सर्वर डिस्क को स्थायी रूप से ओवरलोड कर रही है या b) बहुत सारे लेखन चल रहे हैं ताकि प्रतिकृति इस प्रतिकृति पदानुक्रम में स्थायी रूप से पिछड़ जाए।
शार्डिंग के लिए रीड केस तब होता है जब डेटा का आकार इतना बड़ा होता है कि इसका वर्किंग सेट अब मेमोरी में फिट नहीं होता है और डेटा रीड ज्यादातर समय मेमोरी से परोसे जाने के बजाय डिस्क से टकराना शुरू कर देता है।
केवल तभी जब आपके पास है शार्प करने के लिए आप इसे करते हैं।
जिस क्षण आप शार्प करते हैं, आप उसके लिए कई तरह से भुगतान कर रहे हैं:
आपका अधिकांश SQL अब घोषणात्मक नहीं है।
आम तौर पर, एसक्यूएल में आप डेटाबेस को बता रहे हैं कि आप कौन सा डेटा चाहते हैं और उस विनिर्देश को डेटा एक्सेस प्रोग्राम में बदलने के लिए इसे ऑप्टिमाइज़र पर छोड़ दें। यह एक अच्छी बात है, क्योंकि यह लचीला है, और क्योंकि इन डेटा एक्सेस प्रोग्रामों को लिखना उबाऊ काम है जो वेग को नुकसान पहुंचाता है।
एक तेज वातावरण के साथ आप शायद नोड बी पर डेटा के खिलाफ नोड ए पर एक तालिका में शामिल हो रहे हैं, या आपके पास नोड ए और बी पर नोड से बड़ी तालिका है और नोड बी और सी पर डेटा के खिलाफ डेटा में शामिल हो रहे हैं। आप इसे हल करने के लिए मैन्युअल रूप से एप्लिकेशन साइड हैश-आधारित जॉइन रिज़ॉल्यूशन लिखना शुरू कर रहे हैं (या आप MySQL क्लस्टर को फिर से शुरू कर रहे हैं), जिसका अर्थ है कि आप बहुत सारे SQL के साथ समाप्त होते हैं जो अब घोषणात्मक नहीं है, लेकिन एक प्रक्रियात्मक तरीके से SQL कार्यक्षमता व्यक्त कर रहा है। (उदाहरण के लिए आप लूप में सेलेक्ट स्टेटमेंट का उपयोग कर रहे हैं)।
आप बहुत अधिक नेटवर्क विलंबता का सामना कर रहे हैं।
आम तौर पर, SQL क्वेरी को स्थानीय रूप से हल किया जा सकता है और ऑप्टिमाइज़र स्थानीय डिस्क एक्सेस से जुड़ी लागतों के बारे में जानता है और क्वेरी को इस तरह से हल करता है जिससे उसके लिए लागत कम हो।
एक शार्प्ड वातावरण में, या तो नेटवर्क पर की-वैल्यू एक्सेस को कई नोड्स (उम्मीद है कि बैच की गई कुंजी एक्सेस के साथ और हर राउंड ट्रिप के लिए अलग-अलग कुंजी लुकअप के साथ) या WHERE के कुछ हिस्सों को पुश करके हल किया जाता है। नोड्स के आगे क्लॉज जहां उन्हें लागू किया जा सकता है (जिसे 'कंडीशन पुशडाउन' कहा जाता है), या दोनों।
लेकिन सबसे अच्छे मामलों में भी इसमें कई और नेटवर्क राउंड ट्रिप शामिल हैं जो एक स्थानीय स्थिति है, और यह अधिक जटिल है। विशेष रूप से चूंकि MySQL अनुकूलक नेटवर्क विलंबता के बारे में बिल्कुल भी नहीं जानता है (ठीक है, MySQL क्लस्टर धीरे-धीरे उस पर बेहतर हो रहा है, लेकिन क्लस्टर के बाहर वेनिला MySQL के लिए यह अभी भी सच है)।
आप SQL की बहुत अधिक अभिव्यंजक शक्ति खो रहे हैं।
ठीक है, यह शायद कम महत्वपूर्ण है, लेकिन डेटा अखंडता के लिए विदेशी कुंजी बाधाएं और अन्य SQL तंत्र एकाधिक शार्क फैलाने में असमर्थ हैं।
MySQL में कोई एपीआई नहीं है जो एसिंक्रोनस प्रश्नों की अनुमति देता है जो कार्य क्रम में हैं।
जब एक ही प्रकार का डेटा कई नोड्स (जैसे नोड्स ए, बी और सी पर उपयोगकर्ता डेटा) पर रहता है, तो इन सभी नोड्स के खिलाफ क्षैतिज प्रश्नों को हल करने की आवश्यकता होती है ("सभी उपयोगकर्ता खाते खोजें जो 90 दिनों से लॉग इन नहीं हुए हैं या अधिक")। डेटा एक्सेस का समय नोड्स की संख्या के साथ रैखिक रूप से बढ़ता है, जब तक कि कई नोड्स को समानांतर में नहीं पूछा जा सकता है और परिणाम ("मैप-रिड्यूस") में आते ही एकत्रित हो जाते हैं।
इसके लिए पूर्व शर्त एक एसिंक्रोनस संचार एपीआई है, जो एक अच्छे कामकाजी आकार में MySQL के लिए मौजूद नहीं है। विकल्प बच्चे की प्रक्रियाओं में बहुत सारे फोर्किंग और कनेक्शन हैं, जो सीज़न पास पर चूसने की दुनिया का दौरा कर रहे हैं।
एक बार जब आप शार्प करना शुरू करते हैं, तो डेटा संरचना और नेटवर्क टोपोलॉजी आपके एप्लिकेशन के प्रदर्शन बिंदुओं के रूप में दिखाई देने लगती है। यथोचित रूप से अच्छा प्रदर्शन करने के लिए, आपके आवेदन को इन बातों के बारे में पता होना चाहिए, और इसका मतलब है कि वास्तव में केवल एप्लिकेशन स्तर की शार्डिंग ही समझ में आती है।
प्रश्न अधिक है यदि आप ऑटो-शार्ड करना चाहते हैं (यह निर्धारित करना कि कौन सी पंक्ति किस नोड में जाती है उदाहरण के लिए हैशिंग प्राथमिक कुंजी) या यदि आप मैन्युअल तरीके से कार्यात्मक रूप से विभाजित करना चाहते हैं ("xyz उपयोगकर्ता कहानी से संबंधित तालिकाएं जाती हैं यह मास्टर, जबकि एबीसी और डीईएफ़ संबंधित टेबल उस मास्टर के पास जाते हैं")।
फंक्शनल शार्डिंग का यह फायदा है कि, अगर सही तरीके से किया जाए, तो यह ज्यादातर डेवलपर्स के लिए अदृश्य है, क्योंकि उनकी उपयोगकर्ता कहानी से संबंधित सभी टेबल स्थानीय रूप से उपलब्ध होंगे। यह उन्हें यथासंभव लंबे समय तक घोषणात्मक SQL से लाभ उठाने की अनुमति देता है, और कम नेटवर्क विलंबता भी लेगा क्योंकि क्रॉस-नेटवर्क स्थानान्तरण की संख्या न्यूनतम रखी जाती है।
कार्यात्मक शार्डिंग का नुकसान यह है कि यह किसी एकल तालिका को एक उदाहरण से बड़ा नहीं होने देता है, और इसके लिए एक डिज़ाइनर के मैन्युअल ध्यान की आवश्यकता होती है।
कार्यात्मक शार्डिंग का यह फायदा है कि यह मौजूदा कोडबेस में अपेक्षाकृत आसानी से किया जाता है जिसमें कई बदलाव होते हैं जो बहुत बड़े नहीं होते हैं। http://Booking.com पिछले वर्षों में इसे कई बार किया है और इसने उनके लिए अच्छा काम किया है।
यह सब कहने के बाद, आपके प्रश्न को देखकर, मुझे विश्वास है कि आप गलत प्रश्न पूछ रहे हैं, या मैं आपके समस्या कथन को पूरी तरह गलत समझ रहा हूँ।
