मुझे लगता है कि एक अच्छा समाधान आभासी टुकड़े का प्रयोग है। आप एक सर्वर से शुरू कर सकते हैं और सभी वर्चुअल शार्ड को एक सर्वर पर इंगित कर सकते हैं। वर्चुअल shards में पंक्तियों को समान रूप से वितरित करने के लिए incremental आईडी पर मॉड्यूल का उपयोग करें। अमेज़ॅन आरडीएस के साथ आपके पास दास को एक मास्टर में बदलने का विकल्प है, इसलिए इससे पहले कि आप शेर्डिंग कॉन्फ़िगरेशन को बदलें (नए सर्वर पर अधिक वर्चुअल शर्ड्स इंगित करें), आपको दास को मास्टर बनाना चाहिए, फिर अपनी कॉन्फ़िगरेशन फ़ाइल अपडेट करें, और फिर हटाएं मॉड्यूल का उपयोग कर नए मास्टर पर सभी रिकॉर्ड जो कि नए उदाहरण के लिए उपयोग की जाने वाली शर्ड रेंज का पालन नहीं करते हैं।
आपको मूल सर्वर से पंक्तियों को हटाने की भी आवश्यकता है, लेकिन अब तक नए वर्चुअल शार्ड श्रेणियों के आधार पर मॉड्यूल के साथ सभी नए डेटा नए सर्वर को इंगित करेंगे। तो आपको वास्तव में डेटा को स्थानांतरित करने की आवश्यकता नहीं है, लेकिन अमेज़ॅन आरडीएस सर्वर प्रचार सुविधा का लाभ उठाएं।
फिर आप मूल सर्वर से प्रतिलिपि बना सकते हैं। आप एक अद्वितीय आईडी बनाते हैं: शार्ड आईडी + टेबल टाइप आईडी + वृद्धिशील संख्या। तो जब आप डेटाबेस से पूछताछ करते हैं, तो आप जानते हैं कि किस शार्ड को जाना है और डेटा प्राप्त करना है।
मुझे नहीं पता कि यह RavenDB के साथ कैसे करना संभव है, लेकिन यह अमेज़ॅन आरडीएस के साथ बहुत अच्छी तरह से काम कर सकता है, क्योंकि अमेज़ॅन पहले ही आपको प्रतिकृति और सर्वर प्रचार सुविधा प्रदान करता है।
मैं मानता हूं कि उनका समाधान एक समाधान होना चाहिए जो शुरुआत से ही निर्बाध समाजक्षमता प्रदान करता है और डेवलपर को उन समस्याओं को हल करने के लिए नहीं कहता है जब वे होते हैं। इसके अलावा, मुझे पता चला है कि कई नोएसक्यूएल समाधान जो शार्ड्स में समान रूप से डेटा वितरित करते हैं, कम विलंबता वाले क्लस्टर के भीतर काम करने की आवश्यकता होती है। तो आपको इसे ध्यान में रखना होगा। मैंने दो अलग-अलग ईसी 2 मशीनों (एक समर्पित अमेज़ॅन क्लस्टर में नहीं) के साथ कॉचबेस का उपयोग करने की कोशिश की है और डेटा संतुलन बहुत धीमा था। यह भी कुल लागत में जोड़ता है।
मैं यह भी जोड़ना चाहता हूं कि 4096 आभासी shards का उपयोग करके, उनके स्केलेबिलिटी मुद्दों को हल करने के लिए क्या किया गया है।
आपको कई नोएसक्यूएल डेटाबेस के साथ पेजिंग समस्याओं को देखने की भी आवश्यकता होनी चाहिए। उस दृष्टिकोण के साथ आप पृष्ठ डेटा को आसानी से कर सकते हैं, लेकिन शायद सबसे प्रभावी तरीके से नहीं, क्योंकि आपको कई डेटाबेस पूछने की आवश्यकता हो सकती है। एक और समस्या स्कीमा बदल रही है। Pinterest ने MySQL में JSON Blob में सभी डेटा डालने से इसे हल किया। जब आप एक नया कॉलम जोड़ना चाहते हैं, तो आप नए कॉलम डेटा + कुंजी के साथ एक नई टेबल बनाते हैं, और उस कॉलम पर इंडेक्स का उपयोग कर सकते हैं। यदि आपको डेटा से पूछताछ की आवश्यकता है, उदाहरण के लिए, ईमेल द्वारा, आप ईमेल + आईडी के साथ एक और टेबल बना सकते हैं और ईमेल कॉलम पर एक इंडेक्स डाल सकते हैं। काउंटर एक और समस्या है, मेरा मतलब परमाणु काउंटर हैं। तो बेहतर है कि उन काउंटरों को JSON से बाहर ले जाएं और उन्हें कॉलम में रखें ताकि आप काउंटर वैल्यू बढ़ा सकें।
वहां बहुत अच्छे समाधान हैं, लेकिन दिन के अंत में आप पाते हैं कि वे बहुत महंगा हो सकते हैं। मैंने अपना खुद का शेडिंग समाधान बनाने पर समय बिताना पसंद किया और बाद में सिरदर्द को रोक दिया। यदि आप अन्य मार्ग चुनते हैं, तो बहुत सी कंपनियां परेशानी में पड़ने के लिए प्रतीक्षा कर रही हैं और आपकी समस्याओं का समाधान करने के लिए बहुत सारे पैसे मांगती हैं। क्योंकि जिस क्षण आपको उनकी आवश्यकता है, वे जानते हैं कि आप अपनी परियोजना को फिर से काम करने के लिए सबकुछ भुगतान करेंगे। यह मेरे अपने अनुभव से है, यही कारण है कि मैं अपने दृष्टिकोण का उपयोग करके अपना खुद का शेरिंग समाधान बनाने के लिए अपना सिर तोड़ रहा हूं, जो कि बहुत सस्ता भी है।
एक अन्य विकल्प है MySQL के लिए स्केलबेस या डीबीशार्ड्स जैसे मिडलवेयर समाधान का उपयोग करना। तो आप MySQL के साथ काम करना जारी रख सकते हैं, लेकिन उस समय आपको स्केल करने की आवश्यकता है, उनके पास अच्छी तरह से सिद्ध समाधान है। और वैकल्पिक विकल्प के बाद लागत बहुत कम हो सकती है।
एक और युक्ति: जब आप shards के लिए अपनी कॉन्फ़िगरेशन बनाते हैं, तो एक write_lock विशेषता दें जो गलत या सत्य स्वीकार करती है। तो जब यह झूठा होता है, तो डेटा उस शार्ड को नहीं लिखा जाएगा, इसलिए जब आप विशिष्ट तालिका प्रकार (यानी उपयोगकर्ताओं) के लिए शर्ड्स की सूची प्राप्त करते हैं, तो यह केवल उसी प्रकार के अन्य शर्ड्स में ही लिखा जाएगा। यह बैकअप के लिए भी अच्छा है, इसलिए आप सभी शर्ड्स के पॉइंट-इन-टाइम स्नैपशॉट प्राप्त करने के लिए सभी डेटा का बैक अप लेने पर सभी शर्ड लॉक करना चाहते हैं, तो आप आगंतुकों के लिए एक दोस्ताना त्रुटि दिखा सकते हैं। हालांकि मुझे लगता है कि आप अमेज़ॅन आरडीएस के साथ सभी डेटाबेस स्नैपशॉट करने और पॉइंट-इन-टाइम बैकअप का उपयोग करने के लिए वैश्विक अनुरोध भेज सकते हैं।
बात यह है कि ज्यादातर कंपनियां DIY शेर्डिंग समाधान के साथ काम करने में समय नहीं बिताएंगी, वे स्केलबेस के लिए भुगतान करना पसंद करेंगे।वे समाधान एकल डेवलपर्स से आते हैं जो शुरुआत से स्केलेबल समाधान के लिए भुगतान कर सकते हैं, लेकिन आश्वस्त रहना चाहते हैं कि जब वे इस बिंदु तक पहुंच जाएंगे तो उन्हें एक समाधान होगा। बस कीमतों को देखें और आप यह पता लगा सकते हैं कि इससे आपको बहुत कम खर्च आएगा। एक बार पूरा होने के बाद मैं खुशी से आपके कोड को साझा करूंगा। आप मेरी राय में सबसे अच्छे रास्ते के साथ जा रहे हैं, यह सब आपके आवेदन तर्क पर निर्भर करता है। मैं अपने डेटाबेस को सरल बनाने के लिए मॉडल करता हूं, कोई जोड़ता नहीं, जटिल समेकन प्रश्न नहीं - यह मेरी कई समस्याओं को हल करता है। भविष्य में आप उन बड़े डेटा प्रश्नों को हल करने के लिए मानचित्र कम करने का उपयोग कर सकते हैं।
ऑटो-शेर्डिंग लिंक के लिए धन्यवाद मैंने इसे नहीं देखा था। मुझे लगता है कि "बाद में इसे सॉर्ट करना" के साथ मेरी परेशानी यह है कि मैं एक ऐसी रणनीति चाहता हूं जो सर्वर पर डेटा को संतुलित करे, न कि एक सर्वर भरने वाला कोई भी अगला आगे बढ़ता है। जो नए जोड़े जोड़े जाने पर शर्ड्स के बीच चलती दस्तावेजों के मुद्दे को सामने लाता है। तो मैं जहां से संभव हो, उस के लिए योजना बनाने की कोशिश कर रहा हूं। –
मैंने इस विषय पर अपनी नई सोच के साथ सवाल अपडेट किया। इस दृष्टिकोण पर आपके विचार क्या हैं? –
मुझे यकीन नहीं है कि आपको इस बिंदु पर क्यों चाहिए। आप हमेशा बाद में शेडिंग जोड़ सकते हैं, और रावेनडीबी आपके लिए काम करेगा। – synhershko