अत्यधिक भरी हुई प्रणालियों में डेटाबेस स्केलिंग

पीयर्स की अंतिम आंतरिक रैली में, हमने आधुनिक वितरित भंडारण के बारे में बात की और मैक्सिम नल्स्की, सीईओ और पीयर्स के संस्थापक, ने फाउंडेशनडीबी की अपनी पहली छाप साझा की। इस लेख में, हम तकनीकी बारीकियों के बारे में बात करते हैं जो संरचित डेटा के भंडारण को स्केल करने के लिए एक तकनीक का चयन करते समय आपका सामना करते हैं।

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

वर्तमान लोड। हम इन संकेतकों के विकास को ध्यान में रखते हुए प्रौद्योगिकी का चयन करते हैं।

ग्राहक सर्वर वास्तुकला

क्लासिक क्लाइंट-सर्वर मॉडल एक वितरित प्रणाली का सबसे सरल उदाहरण है। एक सर्वर एक तुल्यकालन बिंदु है; यह कई ग्राहकों को एक साथ समन्वित तरीके से कुछ करने की अनुमति देता है।

क्लाइंट-सर्वर इंटरैक्शन की एक बहुत ही सरल योजना।

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

अनुयायियों को डेटा प्रतिकृति के साथ क्लाइंट-सर्वर आर्किटेक्चर।

यह स्पष्ट है कि यह एक अधिक विश्वसनीय प्रणाली है: यदि मुख्य सर्वर क्रैश हो जाता है, तो सभी डेटा की एक प्रति अनुयायी पर होती है और इसे जल्दी से उठाया जा सकता है।

यह समझना महत्वपूर्ण है कि प्रतिकृति कैसे काम करती है। यदि यह समकालिक है, तो लेनदेन को नेता और अनुयायी पर एक साथ संग्रहीत किया जाना चाहिए, और यह धीमा हो सकता है। यदि प्रतिकृति अतुल्यकालिक है, तो आप एक असफलता के बाद कुछ डेटा खो सकते हैं।

और जब सब लोग सो रहे हों तो रात को क्या होगा? अनुयायी का डेटा है, लेकिन किसी ने उसे नहीं बताया कि वह अब एक नेता है, और ग्राहक उससे कनेक्ट नहीं होते हैं। ठीक है, चलो अनुयायी को इस तर्क के साथ समाप्त करें कि वह नेता के साथ संबंध खो जाने पर खुद को मुख्य चीज मानना ​​शुरू कर देता है। फिर हम आसानी से एक विभाजित मस्तिष्क प्राप्त कर सकते हैं - एक संघर्ष जब नेता और अनुयायी के बीच संबंध टूट जाता है, और दोनों सोचते हैं कि वे मुख्य हैं। यह वास्तव में कई प्रणालियों पर होता है, जैसे कि RabbitMQ , आज की सबसे लोकप्रिय कतार तकनीक है।

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

गवाह गारंटी देता है कि केवल एक नेता है। यदि नेता गिर जाता है, तो अनुयायी स्वचालित रूप से चालू हो जाता है।

ऐसी प्रणाली अब हमारे साथ काम करती है। एक मुख्य डेटाबेस है, एक अतिरिक्त डेटाबेस है, एक साक्षी है और हाँ - कभी-कभी हम सुबह में आते हैं और देखते हैं कि स्विच रात में हुआ।

लेकिन इस योजना में भी कमियां हैं। कल्पना करें कि आप सर्विस पैक स्थापित कर रहे हैं या एक लीडर सर्वर पर OS अपडेट कर रहे हैं। इससे पहले, आपने मैन्युअल रूप से अनुयायी पर लोड किया और फिर ... यह गिर गया! आपदा, आपकी सेवा अनुपलब्ध है। इससे खुद को बचाने के लिए क्या करें? एक अन्य बैकअप सर्वर - एक और अनुयायी जोड़ें। तीन एक तरह का मैजिक नंबर है। यदि आप चाहते हैं कि सिस्टम मज़बूती से काम करे, तो दो सर्वर पर्याप्त नहीं हैं, आपको तीन की आवश्यकता है। रखरखाव के लिए एक, दूसरा गिरता है, तीसरा रहता है।

तीसरा सर्वर विश्वसनीय संचालन प्रदान करता है यदि पहले दो अनुपलब्ध हैं।

संक्षेप में, अतिरेक दो के बराबर होना चाहिए। एक की अतिरेक पर्याप्त नहीं है। इस कारण से, डिस्क सरणियों में, लोगों ने RAID5 के बजाय RAID6 योजना का उपयोग करना शुरू कर दिया, एक बार में दो डिस्क के गिरने से बचे।

लेन-देन

चार बुनियादी लेन-देन की आवश्यकताओं को अच्छी तरह से जाना जाता है: परमाणु, संगति, अलगाव और स्थायित्व (एटोमिसिटी, संगति, अलगाव, स्थायित्व - एसीआईडी)।

जब हम वितरित डेटाबेस के बारे में बात करते हैं, तो हमारा मतलब है कि डेटा को स्केल किया जाना चाहिए। रीडिंग स्केल बहुत अच्छी तरह से - हजारों लेनदेन बिना किसी समस्या के समानांतर डेटा पढ़ सकते हैं। लेकिन जब अन्य लेनदेन पढ़ने के रूप में एक ही समय में डेटा लिखते हैं, तो विभिन्न अवांछनीय प्रभाव संभव हैं। ऐसी स्थिति प्राप्त करना बहुत आसान है जहां एक लेनदेन एक ही रिकॉर्ड के विभिन्न मूल्यों को पढ़ेगा। यहाँ कुछ उदाहरण हैं।

गंदा पढ़ता है। पहले लेन-देन में, हम दो बार एक ही अनुरोध भेजते हैं: उन सभी उपयोगकर्ताओं को जिनकी आईडी = 1. यदि दूसरा लेन-देन इस लाइन को बदल देता है और फिर रोलबैक होता है, डेटाबेस को एक तरफ कोई बदलाव नहीं दिखेगा, लेकिन दूसरी तरफ पहला लेन-देन जो के लिए विभिन्न आयु मानों को पढ़ेगा।



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



पहले मामले में, क्लाइंट ने डेटा पढ़ा जो आमतौर पर डेटाबेस में अनुपस्थित था। दूसरे मामले में, क्लाइंट दोनों बार डेटाबेस से डेटा पढ़ता है, लेकिन वे अलग-अलग होते हैं, हालांकि रीडिंग एक ही लेनदेन के भीतर होती है।

प्रेत पढ़ता है जब हम एक ही लेनदेन के भीतर एक सीमा को फिर से पढ़ते हैं और लाइनों का एक अलग सेट प्राप्त करते हैं। कहीं बीच में, एक और लेन-देन दर्ज किया गया और डाला या हटाए गए रिकॉर्ड।



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

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



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

चलिए सीरियल के भोले-भाले कार्यान्वयन के बारे में सोचते हैं - प्रत्येक लेनदेन के साथ, हम बस बाकी सभी को रोकते हैं। प्रत्येक लेखन लेनदेन को सैद्धांतिक रूप से 50 50 (आधुनिक एसएसडी डिस्क पर एक लिखने के संचालन का समय) में किया जा सकता है। और हम तीन मशीनों को डेटा बचाना चाहते हैं, याद है? यदि वे एक ही डेटा सेंटर में हैं, तो रिकॉर्डिंग में 1-3 एमएस लगेगा। और अगर वे, विश्वसनीयता के लिए, विभिन्न शहरों में हैं, तो रिकॉर्डिंग आसानी से 10-12ms (मॉस्को से सेंट पीटर्सबर्ग के लिए एक नेटवर्क पैकेट का यात्रा समय और इसके विपरीत) ले सकते हैं। यही है, अनुक्रमिक रिकॉर्डिंग द्वारा अनुक्रमिक स्तर के एक भोले कार्यान्वयन के साथ, हम प्रति सेकंड 100 से अधिक लेनदेन नहीं कर सकते हैं। जबकि एक अलग एसएसडी आपको प्रति सेकंड लगभग 20,000 लिखने का संचालन करने की अनुमति देता है!

निष्कर्ष: लेखन लेनदेन समानांतर में किया जाना चाहिए, और उन्हें स्केल करने के लिए, आपको एक अच्छे संघर्ष समाधान तंत्र की आवश्यकता है।

Shardirovanie

जब डेटा एक सर्वर पर मिलना बंद हो जाए तो क्या करें? दो मानक ज़ूम तंत्र हैं:

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

एक शार्किंग कुंजी एक पैरामीटर है जिसके द्वारा सर्वर के बीच डेटा वितरित किया जाता है, उदाहरण के लिए, एक क्लाइंट या संगठन पहचानकर्ता।

कल्पना कीजिए कि आपको एक क्लस्टर में पृथ्वी के सभी निवासियों के बारे में डेटा रिकॉर्ड करने की आवश्यकता है। एक शार्क कुंजी के रूप में, आप उदाहरण के लिए, व्यक्ति का जन्म वर्ष ले सकते हैं। फिर 116 सर्वर पर्याप्त होंगे (और हर साल एक नया सर्वर जोड़ना आवश्यक होगा)। या आप एक महत्वपूर्ण देश के रूप में ले सकते हैं जहां व्यक्ति रहता है, तो आपको लगभग 250 सर्वरों की आवश्यकता होगी। फिर भी, पहला विकल्प बेहतर है, क्योंकि व्यक्ति की जन्मतिथि नहीं बदलती है, और आपको सर्वर के बीच उसके बारे में डेटा ट्रांसफर करने की आवश्यकता नहीं होगी।



पाइरस में, आप एक संगठन को एक शार्पिंग कुंजी के रूप में ले सकते हैं। लेकिन वे आकार में बहुत भिन्न होते हैं: दोनों में एक विशाल सोवकॉमबैंक (15 हजार से अधिक उपयोगकर्ता) और हजारों छोटी कंपनियां हैं। जब आप किसी संगठन को एक विशिष्ट सर्वर प्रदान करते हैं, तो आप पहले से नहीं जानते कि यह कैसे बढ़ेगा। यदि संगठन बड़ा है और सक्रिय रूप से सेवा का उपयोग करता है, तो जल्द ही या बाद में इसका डेटा एक सर्वर पर रखा जाना बंद हो जाएगा, और आपको पुनर्व्यवस्थित करना होगा। और यह आसान नहीं है अगर डेटा टेराबाइट्स है। कल्पना करें: एक भरी हुई प्रणाली, लेनदेन हर दूसरे पर चलते हैं, और इन स्थितियों में आपको डेटा को एक स्थान से दूसरे स्थान पर ले जाने की आवश्यकता होती है। आप सिस्टम को रोक नहीं सकते हैं, इस तरह की मात्रा को कई घंटों तक पंप किया जा सकता है, और व्यावसायिक ग्राहक इतने लंबे समय तक नहीं बचेंगे।

एक शार्किंग कुंजी के रूप में, डेटा चुनना बेहतर होता है जो शायद ही कभी बदलता है। हालाँकि, हमेशा एक लागू कार्य से यह करना आसान होता है।

क्लस्टर में सहमति

जब क्लस्टर में बहुत सारी मशीनें होती हैं और उनमें से कुछ दूसरों के साथ संपर्क खो देती हैं, तो यह कैसे तय करें कि डेटा का नवीनतम संस्करण कौन संग्रहीत करता है? बस एक साक्षी सर्वर को असाइन करना पर्याप्त नहीं है, क्योंकि यह पूरे क्लस्टर के साथ संपर्क भी खो सकता है। इसके अलावा, एक विभाजित मस्तिष्क की स्थिति में, कई मशीनें एक ही डेटा के विभिन्न संस्करणों को रिकॉर्ड कर सकती हैं - और आपको किसी तरह यह निर्धारित करने की आवश्यकता है कि कौन सा सबसे अधिक प्रासंगिक है। इस समस्या को हल करने के लिए, लोग आम सहमति एल्गोरिदम के साथ आए। वे कई समान मशीनों को वोट देकर किसी भी मुद्दे पर एक ही परिणाम के लिए आने की अनुमति देते हैं। 1989 में, इस तरह के पहले एल्गोरिथ्म, पैक्सोस को प्रकाशित किया गया था, और 2014 में, स्टैनफोर्ड के लोग इसे लागू करने के लिए एक सरल रफ़ के साथ आए। आम तौर पर आम सहमति तक पहुंचने के लिए (2N + 1) सर्वर के क्लस्टर के लिए सख्ती से बोलना, यह पर्याप्त है कि इसमें एन विफलताओं से अधिक नहीं है। 2 विफलताओं से बचने के लिए, क्लस्टर में कम से कम 5 सर्वर होने चाहिए।

संबंधपरक DBMS स्केलिंग

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



मान लें कि एक क्लस्टर इंडेक्स के साथ एक प्राथमिक कुंजी है। तब ऑप्टिमाइज़र एक ऐसी योजना बनाएगा जो सबसे पहले तालिका ए से आवश्यक रिकॉर्ड का चयन करेगी और फिर उपयुक्त सूचकांक (ए, बी) से तालिका बी में रिकॉर्ड के लिए उपयुक्त लिंक ले जाएगी। इस क्वेरी का निष्पादन समय तालिकाओं में रिकॉर्ड की संख्या से तार्किक रूप से बढ़ता है।

अब कल्पना करें कि डेटा क्लस्टर में चार सर्वरों में वितरित किया गया है और आपको उसी क्वेरी को निष्पादित करने की आवश्यकता है:



यदि DBMS पूरे क्लस्टर के सभी रिकॉर्ड नहीं देखना चाहता है, तो वह संभवतः A.id के साथ 128, 129, या 130 के बराबर रिकॉर्ड खोजने की कोशिश करेगा और टेबल बी से उनके लिए उपयुक्त रिकॉर्ड ढूंढेगा। लेकिन यदि A.id एक शार्प कुंजी नहीं है, तो अग्रिम में DBMS पता नहीं चल सकता है कि टेबल ए का डेटा किस सर्वर पर है। मुझे यह पता लगाने के लिए कि क्या हमारी स्थिति के लिए उपयुक्त एआईडी रिकॉर्ड हैं, वैसे भी सभी सर्वरों से संपर्क करना होगा। तब प्रत्येक सर्वर अपने अंदर एक JOIN कर सकता है, लेकिन यह पर्याप्त नहीं है। आप देखते हैं, हमें नमूने में नोड 2 पर रिकॉर्ड की आवश्यकता है, लेकिन एआईडी = 128 के साथ कोई रिकॉर्ड नहीं है? यदि नोड 1 और 2 स्वतंत्र रूप से शामिल होंगे, तो क्वेरी परिणाम अधूरा होगा - हम डेटा का हिस्सा प्राप्त नहीं करेंगे।

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

इस प्रकार, JOIN संचालन मूलभूत रूप से खराब होता है और यह संबंधपरक दृष्टिकोण की एक मूलभूत समस्या है।

NoSQL दृष्टिकोण

क्लासिक DBMS को स्केल करने में कठिनाई के कारण लोगों को NoSQL डेटाबेस के साथ आने के लिए प्रेरित किया है जिनके पास JOIN ऑपरेशंस नहीं हैं। कोई जोड़ नहीं - कोई समस्या नहीं। लेकिन एसीआईडी ​​गुण नहीं हैं, लेकिन उन्होंने विपणन सामग्रियों में इसका उल्लेख नहीं किया है। त्वरित रूप से पाए गए शिल्पकार जो विभिन्न वितरित प्रणालियों की ताकत का परीक्षण करते हैं और परिणामों को सार्वजनिक रूप से पोस्ट करते हैं । यह पता चला कि ऐसे परिदृश्य हैं जब रेडिस क्लस्टर संग्रहीत डेटा का 45%, रैबिटएमक्यू क्लस्टर - 35% संदेश , मोंगोडीबी - 9% रिकॉर्ड , कैसेंड्रा - 5% तक खो देता है । और हम क्लाइंट को सफल बचत के बारे में सूचित करने के बाद नुकसान के बारे में बात कर रहे हैं । आमतौर पर आप चुनी गई तकनीक से उच्च स्तर की विश्वसनीयता की उम्मीद करते हैं।

Google ने Spanner डेटाबेस विकसित किया है, जो दुनिया भर में संचालित होता है। स्पैनर एसीआईडी ​​गुण, सीरियलिबिलिटी और अधिक की गारंटी देता है। उनके पास डेटा केंद्रों में परमाणु घड़ियां हैं जो सटीक समय प्रदान करती हैं, और यह आपको महाद्वीपों के बीच नेटवर्क पैकेटों को अग्रेषित करने की आवश्यकता के बिना लेनदेन का वैश्विक क्रम बनाने की अनुमति देता है। स्पैनर का विचार यह है कि प्रोग्रामर के लिए प्रदर्शन समस्याओं से निपटने के लिए बेहतर है जो लेनदेन की कमी के आसपास बैसाखी की तुलना में बड़ी संख्या में लेनदेन के साथ उत्पन्न होते हैं। हालांकि, स्पैनर एक बंद तकनीक है, यह आपको सूट नहीं करता है यदि किसी कारण से आप एक विक्रेता पर निर्भर नहीं होना चाहते हैं।

Google के मूल निवासियों ने स्पैनर का एक खुला स्रोत एनालॉग विकसित किया और इसे कॉकरोचडीबी ("कॉकरोच" को अंग्रेजी में "कॉकरोच" नाम दिया, जिसे डेटाबेस की उत्तरजीविता का प्रतीक होना चाहिए)। Habré पर पहले से ही उत्पादन के लिए उत्पाद की अनुपलब्धता के बारे में लिखा था , क्योंकि क्लस्टर डेटा खो रहा था। हमने नए संस्करण 2.0 की जांच करने का फैसला किया, और एक समान निष्कर्ष पर पहुंचे। हमने डेटा नहीं खोया है, लेकिन कुछ सरल प्रश्नों को अनुचित रूप से लंबे समय तक निष्पादित किया गया था।

---

नतीजतन, आज रिलेशनल डेटाबेस हैं जो केवल लंबवत रूप से अच्छी तरह से पैमाने पर हैं, जो महंगा है। और बिना लेनदेन के और बिना ACID गारंटी के NoSQL समाधान हैं (यदि आप ACID चाहते हैं, तो बैसाखी लिखें)।

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