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

हेब के पाठकों के अनुरोध पर , अब एक विषय के रूप में पूर्ण संस्करण।

स्केलेबल वेब आर्किटेक्चर और डिस्ट्रीब्यूटेड सिस्टम

केट मतसुदिरा

अनुवाद: जेडी-टू-बी ।
सुधार: अनास्तासियाफ़ 15 , सनशाइन_लैस , अमालिया , आग का गोला , गौडरॉन ।

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

यह अध्याय वेब सिस्टम के विश्लेषण पर केंद्रित है, हालांकि कुछ सामग्री को अन्य वितरित प्रणालियों के लिए एक्सट्रपलेशन किया जा सकता है।

1.1 भवन के सिद्धांत वितरित वेब सिस्टम

एक स्केलेबल वेबसाइट या एप्लिकेशन को बनाने और प्रबंधित करने का वास्तव में क्या मतलब है? एक आदिम स्तर पर, यह उपयोगकर्ताओं को इंटरनेट पर दूरस्थ संसाधनों से जोड़ रहा है। और इन संसाधनों तक पहुंच या पहुंच, जो कई सर्वरों पर छितरी हुई हैं और वे लिंक हैं जो वेबसाइट की मापनीयता सुनिश्चित करते हैं।

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

• पहुँच क्षमता: किसी वेबसाइट की अपटाइम की अवधि कई कंपनियों की प्रतिष्ठा और कार्यक्षमता के लिए महत्वपूर्ण है। कुछ बड़े ऑनलाइन रिटेल स्टोरों के लिए, कुछ मिनटों के लिए दुर्गमता भी हजारों या लाखों डॉलर के राजस्व का नुकसान कर सकती है। इस प्रकार, उनकी लगातार सुलभ और असफल-सुरक्षित प्रणालियों का विकास एक बुनियादी व्यापार और तकनीकी आवश्यकता दोनों है। वितरित प्रणालियों में उच्च उपलब्धता के लिए प्रमुख घटकों के लिए अतिरेक पर ध्यान देने की आवश्यकता है, आंशिक प्रणाली विफलताओं से त्वरित वसूली और समस्याओं के उत्पन्न होने पर क्षमताओं में एक सहज कमी।
• प्रदर्शन: वेबसाइट प्रदर्शन अधिकांश साइटों के लिए एक महत्वपूर्ण संकेतक बन गया है। वेबसाइट की गति उपयोगकर्ता के प्रदर्शन और उपयोगकर्ता की संतुष्टि, साथ ही खोज इंजन रैंकिंग को प्रभावित करती है, एक कारक जो सीधे दर्शकों की अवधारण और राजस्व को प्रभावित करता है। नतीजतन, कुंजी एक ऐसी प्रणाली बनाने के लिए है जो तेज प्रतिक्रियाओं और कम विलंबता के लिए अनुकूलित है।
• विश्वसनीयता, सिस्टम विश्वसनीय होना चाहिए, ताकि डेटा के लिए एक विशिष्ट अनुरोध समान रूप से कुछ डेटा लौटाया जा सके। डेटा परिवर्तन या अपडेट के मामले में, एक ही अनुरोध को नया डेटा वापस करना चाहिए। उपयोगकर्ताओं को पता होना चाहिए कि यदि सिस्टम में कुछ लिखा गया है या उसमें संग्रहीत किया गया है, तो आप यह सुनिश्चित कर सकते हैं कि यह बाद में डेटा पुनर्प्राप्त करने में सक्षम होने के लिए अपनी जगह पर रहेगा।
• स्केलेबिलिटी: जब किसी बड़े डिस्ट्रिब्यूटेड सिस्टम की बात आती है, तो साइज़ एक लिस्ट से सिर्फ एक आइटम होता है, जिस पर विचार करने की ज़रूरत होती है। समान रूप से महत्वपूर्ण भार के बड़े संस्करणों के प्रसंस्करण के लिए थ्रूपुट को बढ़ाने के प्रयास हैं, जिन्हें आमतौर पर सिस्टम स्केलेबिलिटी के रूप में संदर्भित किया जाता है। स्केलेबिलिटी सिस्टम के विभिन्न मापदंडों से संबंधित हो सकती है: अतिरिक्त ट्रैफ़िक की मात्रा जो इसे संभाल सकती है, स्टोरेज डिवाइस की क्षमता को बढ़ाना कितना आसान है, या कितने अन्य लेनदेन को संसाधित किया जा सकता है।
• प्रबंधनीयता: एक प्रणाली को डिजाइन करना जो संचालित करना आसान है, एक और महत्वपूर्ण कारक है। सिस्टम की नियंत्रणीयता संचालन "रखरखाव" और "अपडेट" की मापनीयता के बराबर है। नियंत्रणीयता सुनिश्चित करने के लिए, निदान की सादगी के मुद्दों और उभरती समस्याओं की समझ, अद्यतन या संशोधन में आसानी, और ऑपरेशन में सिस्टम की सनक के मुद्दों पर विचार करना आवश्यक है। अपवाद?)
• लागत: लागत एक महत्वपूर्ण कारक है। इसमें स्पष्ट रूप से हार्डवेयर और सॉफ़्टवेयर लागत शामिल हो सकते हैं, लेकिन सिस्टम को तैनात करने और बनाए रखने के लिए आवश्यक अन्य पहलुओं पर विचार करना भी महत्वपूर्ण है। डेवलपर्स को एक सिस्टम बनाने के लिए जितना समय चाहिए, सिस्टम लॉन्च करने के लिए आवश्यक परिचालन प्रयास की मात्रा, और यहां तक ​​कि प्रशिक्षण का पर्याप्त स्तर - सब कुछ प्रदान करना होगा। लागत स्वामित्व की कुल लागत है।

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

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

1.2 मूल बातें

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

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

उदाहरण: छवि होस्टिंग अनुप्रयोग

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

एक ऐसी प्रणाली की कल्पना करें जहां उपयोगकर्ता अपनी छवियों को एक केंद्रीय सर्वर पर अपलोड कर सकते हैं, और छवियों को फ़्लिकर या पिकासा के समान किसी साइट या एपीआई के लिंक के माध्यम से अनुरोध किया जा सकता है। विवरण को सरल बनाने के लिए, मान लें कि इस एप्लिकेशन के दो मुख्य कार्य हैं: सर्वर पर छवियों को अपलोड (लिखने) और छवियों का अनुरोध करने की क्षमता। बेशक, एक प्रभावी डाउनलोड एक महत्वपूर्ण मानदंड है, लेकिन प्राथमिकता उपयोगकर्ताओं के अनुरोध पर तेजी से वितरण होगी (उदाहरण के लिए, छवियों को एक वेब पेज या अन्य एप्लिकेशन पर प्रदर्शित करने के लिए अनुरोध किया जा सकता है)। यह कार्यक्षमता उसी के समान है जिसे वेब सर्वर या सामग्री वितरण नेटवर्क (सीडीएन) के एज सर्वर द्वारा प्रदान किया जा सकता है। एक सीडीएन सर्वर आमतौर पर कई स्थानों में डेटा ऑब्जेक्ट को संग्रहीत करता है, इसलिए उनका भौगोलिक / भौतिक स्थान उपयोगकर्ताओं के करीब है, जिसके परिणामस्वरूप प्रदर्शन में वृद्धि हुई है।

सिस्टम के अन्य महत्वपूर्ण पहलू:

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

चित्र 1.1 कार्यक्षमता का एक सरल आरेख है।

चित्र 1.1: छवि होस्टिंग अनुप्रयोग के लिए एक सरलीकृत वास्तुकला आरेख

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

सेवाएं

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

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

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

मान लें कि सेवा भविष्य में भारी उपयोग में है; यह परिदृश्य बेहतर ट्रैक करने में मदद करता है कि एक छवि को पढ़ने में लगने वाले समय को रिकॉर्डिंग कितना समय तक प्रभावित करती है (क्योंकि दोनों कार्य साझा संसाधनों के लिए प्रतिस्पर्धा करेंगे)। वास्तुकला के आधार पर, यह प्रभाव महत्वपूर्ण हो सकता है। भले ही भेजें और प्राप्त गति समान हो (जो कि अधिकांश आईपी नेटवर्क के लिए विशिष्ट नहीं है, क्योंकि उन्हें कम से कम 3: 1 का प्राप्त / आउटपुट गति अनुपात प्राप्त करने के लिए डिज़ाइन किया गया है), आमतौर पर पढ़ी गई फाइलें कैश से निकाली जाएंगी, और रिकॉर्ड अंततः डिस्क पर जाएं (और संभवतः समान स्थितियों में कई पुनर्लेखन से गुजरें)। भले ही सारा डेटा मेमोरी में हो या डिस्क (जैसे एसएसडी सॉलिड स्टेट ड्राइव) से पढ़ा गया हो, डेटाबेस से लिखना लगभग हमेशा इससे पढ़ने की तुलना में धीमा होगा। (पोल स्थिति, बेंचमार्किंग डेटाबेस के लिए एक खुला स्रोत उपकरण, http://polepos.org/ और http://polepos.sourceforge.net/results/PolePositionClientServer.pdf के परिणाम।)।

इस डिज़ाइन के साथ एक और संभावित समस्या यह है कि Apache या lighttpd जैसे वेब सर्वर में आमतौर पर एक साथ कनेक्शन की संख्या पर ऊपरी सीमा होती है जो इसे सेवा कर सकता है (डिफ़ॉल्ट मान लगभग 500 है, लेकिन यह बहुत अधिक हो सकता है) और उच्च यातायात के साथ, रिकॉर्ड जल्दी से इस सीमा का उपयोग कर सकते हैं चूंकि रीड्स अतुल्यकालिक हो सकते हैं या अन्य प्रदर्शन अनुकूलन का लाभ उठा सकते हैं जैसे कि gzip संपीड़न या बैच ट्रांसफर, वेब सर्वर फीड रीडिंग को तेजी से और क्लाइंट के बीच स्विच कर सकता है, कनेक्शन की अधिकतम संख्या की तुलना में बहुत अधिक अनुरोधों की सेवा (Apache के साथ) और अधिकतम 500 सेट के कनेक्शन के साथ, प्रति सेकंड कई हजार रीड रिक्वेस्ट सर्व करना संभव है)। दूसरी ओर, रिकॉर्ड्स पूरे डाउनलोड समय में एक खुला कनेक्शन बनाए रखने के लिए होते हैं। इसलिए सर्वर पर 1 एमबी फ़ाइल स्थानांतरित करने से अधिकांश होम नेटवर्क पर 1 सेकंड से अधिक समय लग सकता है, परिणामस्वरूप, वेब सर्वर केवल 500 ऐसे एक साथ रिकॉर्ड की प्रक्रिया कर सकता है।

चित्र 1.2: पढ़ने और लिखने का पृथक्करण

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

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

बेशक, उपरोक्त मॉडल का काम इष्टतम होगा यदि दो अलग-अलग समापन बिंदु हैं (वास्तव में, यह क्लाउड स्टोरेज प्रदाताओं और सामग्री वितरण नेटवर्क के कई कार्यान्वयन के समान है)। ऐसी समस्याओं को हल करने के कई तरीके हैं, और प्रत्येक मामले में आप एक समझौता पा सकते हैं।

उदाहरण के लिए, फ़्लिकर विभिन्न मॉड्यूल के बीच उपयोगकर्ताओं को वितरित करके इस रीड-राइट समस्या को हल करता है, ताकि प्रत्येक मॉड्यूल केवल विशिष्ट उपयोगकर्ताओं की एक सीमित संख्या में सेवा कर सके, और जब उपयोगकर्ताओं की संख्या बढ़ जाती है, तो क्लस्टर में अधिक मॉड्यूल जोड़े जाते हैं (फ़्लिकर स्केलिंग पर प्रस्तुति देखें)
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-pretation-file.html )। पहले उदाहरण में, वास्तविक लोड (संपूर्ण सिस्टम में पढ़ने और लिखने की संख्या) के आधार पर हार्डवेयर को स्केल करना आसान है, जबकि फ़्लिकर स्केलिंग उपयोगकर्ता आधार पर आधारित है (हालांकि, विभिन्न उपयोगकर्ताओं के बीच समान उपयोग की धारणा यहाँ उपयोग की जाती है, इसलिए आपको क्षमता के साथ योजना बनाने की आवश्यकता है। मार्जिन)। अतीत में, एक अक्षमता या सेवाओं में से एक के साथ एक समस्या ने पूरे सिस्टम की कार्यक्षमता को अक्षम कर दिया (उदाहरण के लिए, कोई भी फाइल नहीं लिख सकता है), फिर फ़्लिकर मॉड्यूल में से एक की अक्षमता केवल इससे संबंधित उपयोगकर्ताओं को प्रभावित करेगी। पहले उदाहरण में, डेटा के एक पूरे सेट पर ऑपरेशन करना आसान है - उदाहरण के लिए, नए मेटाडेटा को शामिल करने के लिए रिकॉर्डिंग सेवा को अपडेट करना, या छवियों के सभी मेटाडेटा को खोजना - जबकि फ़्लिकर आर्किटेक्चर के साथ, प्रत्येक मॉड्यूल को अपडेट किया जाना चाहिए या खोज (या खोज सेवा) होनी चाहिए मेटाडेटा को छाँटने के लिए बनाया गया है जो वास्तव में इसके लिए अभिप्रेत है)।

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

फालतूपन

असफलता से निपटने के लिए, एक वेब आर्किटेक्चर को अपनी सेवाओं और डेटा में अतिरेक होना चाहिए। उदाहरण के लिए, यदि किसी एकल सर्वर पर संग्रहीत फ़ाइल की केवल एक प्रतिलिपि है, तो इस सर्वर के नुकसान का मतलब फ़ाइल का नुकसान होगा। यह संभावना नहीं है कि इस स्थिति को सकारात्मक रूप से चित्रित किया जा सकता है, और आमतौर पर कई या बैकअप प्रतियां बनाकर इससे बचा जा सकता है।

यही सिद्धांत सेवाओं पर लागू होता है। यदि आप उस एप्लिकेशन के लिए कार्यक्षमता का एक अभिन्न अंग प्रदान करते हैं जो इसकी कई प्रतियों या संस्करणों के एक साथ संचालन की गारंटी देता है, तो आप एकल नोड की विफलता से अपनी रक्षा कर सकते हैं।

सिस्टम में अतिरेक पैदा करने से आप कमजोरियों से छुटकारा पा सकते हैं और आपातकाल की स्थिति में बैकअप या निरर्थक कार्यक्षमता प्रदान कर सकते हैं। , , «», , .
.

।

— , . , , «», . , . , , .

।

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

चित्र 1.3: निरर्थक छवि होस्टिंग अनुप्रयोग

विभाजन

, . , , . : .

. , ( ) , . . , , .

, , . , . , . , .

. , . , , . , .

, , , , , . (. 1.4।) इस तरह की वास्तुकला प्रणाली को प्रत्येक फ़ाइल सर्वर को छवियों के साथ भरने की अनुमति देगी, अतिरिक्त सर्वर को जोड़ने के रूप में डिस्क स्थान भरा हुआ है। डिज़ाइन को एक नामकरण योजना की आवश्यकता होगी जो छवि फ़ाइल नाम को सर्वर से युक्त करती है। छवि नाम सर्वर से जुड़ी एक सुसंगत हैश योजना से बन सकता है। या वैकल्पिक रूप से, प्रत्येक छवि में एक वृद्धिशील पहचानकर्ता हो सकता है, जो एक छवि का अनुरोध करते समय वितरण सेवा को प्रत्येक सर्वर (एक सूचकांक के रूप में) से जुड़े पहचानकर्ताओं की सीमा को संसाधित करने की अनुमति देता है।

चित्र 1.4: अतिरेक और विभाजन के साथ छवि होस्टिंग अनुप्रयोग

, . — ; , , . , , , , , , .

() . , , «» — , — . , , , «» «», , . , , «» «», .

।

, , , , : , , , .. . , . ; , . , - .

1.3।

, — .

LAMP स्टैक एप्लिकेशन जैसे सरल वेब एप्लिकेशन चित्र 1.5 में छवि के समान हैं ।

चित्र 1.5: सरल वेब अनुप्रयोग

एप्लिकेशन की वृद्धि के साथ, दो मुख्य कठिनाइयां उत्पन्न होती हैं: एप्लिकेशन सर्वर और डेटाबेस तक पहुंच को स्केल करना। एक अच्छी तरह से स्केलेबल एप्लिकेशन डिज़ाइन में, एक वेब सर्वर या एप्लिकेशन सर्वर आमतौर पर छोटा होता है और अक्सर एक आर्किटेक्चर का प्रतीक होता है जो संसाधनों को साझा नहीं करता है। यह सिस्टम के एप्लिकेशन सर्वर को क्षैतिज रूप से स्केलेबल बनाता है। इस डिज़ाइन का उपयोग करने के परिणामस्वरूप, कड़ी मेहनत डेटाबेस सर्वर और सहायक सेवाओं के लिए स्टैक को नीचे ले जाएगी; यह इस स्तर पर है कि स्केलिंग और प्रदर्शन की वास्तविक समस्याएं खेलने में आती हैं।

इस अध्याय के बाकी कुछ सबसे आम रणनीतियों और डेटा को त्वरित पहुंच प्रदान करके इन प्रकार की सेवाओं के प्रदर्शन और मापनीयता में सुधार के तरीकों पर केंद्रित है।

चित्र 1.6: सरलीकृत वेब अनुप्रयोग

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

इस अनुभाग की समीक्षा करने के लिए, मान लें कि आपके पास डेटा के कई टेराबाइट्स (टीबी) हैं, और आप उपयोगकर्ताओं को यादृच्छिक क्रम में इस डेटा के छोटे हिस्से तक पहुंचने की अनुमति देते हैं। ( चित्र 1.7 देखें ।)
एक समान कार्य उदाहरण छवि होस्टिंग अनुप्रयोग में फ़ाइल सर्वर पर कहीं छवि फ़ाइल का पता लगाना है।

चित्र 1.7: विशिष्ट डेटा तक पहुंच

, -. — , , , . ; 6 , , 100,000 — (. « », http://queue.acm.org/detail.cfm?id=1563874). )। , , , .

, , — , , . , , .

: . : , , -, - . : , , , , . , , , .

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

चित्र 1.8: अनुरोध-स्तर के होस्ट पर कैश होस्ट करना

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

चित्र 1.9: कैश सिस्टम

जब आप कई नोड्स को कैशिंग वितरित करते हैं तो क्या होता है? जैसा कि आप चित्र 1.9 में देख सकते हैं , यदि अनुरोध स्तर में कई नोड शामिल होंगे, तो यह संभावना है कि प्रत्येक नोड का अपना कैश होगा। हालांकि, अगर आपका लोड बैलेंसर नोड्स के बीच बेतरतीब ढंग से अनुरोधों को वितरित करता है, तो एक ही अनुरोध अलग-अलग नोड्स में जाएगा, इस प्रकार कैश विफलताओं में वृद्धि होती है। इस बाधा को दूर करने के दो तरीके वैश्विक और वितरित कैश हैं।

वैश्विक कैश

: . , , , . , . , , . ( , , , ).

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

चित्र 1.10: वैश्विक कैश, जहां कैश पुनर्प्राप्त करने के लिए जिम्मेदार है



चित्र 1.11: वैश्विक कैश जहां अनुरोध नोड्स को पुनर्प्राप्त करने के लिए जिम्मेदार हैं

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

वितरित कैश

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

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

चित्र 1.12: वितरित कैश।

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

ओपन सोर्स कैश का एक लोकप्रिय उदाहरण मेमेकैच्ड () है, जो स्थानीय या वितरित कैश के रूप में काम कर सकता है); इसके अलावा, कई अन्य विकल्प हैं (एक विशेष भाषा या प्लेटफ़ॉर्म के लिए विशिष्ट सहित)।

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

फेसबुक अपनी साइट पर उच्च प्रदर्शन प्राप्त करने के लिए कई अलग-अलग प्रकार के कैशिंग का उपयोग करता है (देखें "फेसबुक: कैशिंग और प्रदर्शन" )। वे $GLOBALS और APC का उपयोग करते हैं, भाषा-स्तरीय कैशिंग (एक फ़ंक्शन को कॉल करके PHP में दर्शाया गया है), जो मध्यवर्ती फ़ंक्शन कॉल को गति देने और परिणाम प्राप्त करने में मदद करता है। (वेब पेज के प्रदर्शन को बेहतर बनाने के लिए अधिकांश भाषाएं इन प्रकार के पुस्तकालयों से सुसज्जित हैं, और उन्हें लगभग हमेशा उपयोग किया जाना चाहिए।) इसके अलावा, फेसबुक एक वैश्विक कैश का उपयोग करता है जिसे कई सर्वरों में वितरित किया जाता है (देखें " स्केलिंग को फेसबुक पर याद किया जाता है" ), इसलिए वह एक है। कैश को एक्सेस करने वाला एक फ़ंक्शन कॉल एक साथ अलग-अलग मेमेकैड सर्वर पर संग्रहीत डेटा के कई अनुरोधों को निष्पादित कर सकता है। यह दृष्टिकोण आपको उपयोगकर्ता प्रोफ़ाइल डेटा के लिए उच्च प्रदर्शन और थ्रूपुट प्राप्त करने और डेटा अपडेट करने के लिए एक केंद्रीकृत वास्तुकला बनाने की अनुमति देता है। यह महत्वपूर्ण है क्योंकि, हजारों सर्वरों के साथ, कैश स्थिरता को अक्षम करना और बनाए रखना मुश्किल हो सकता है।

आगे हम कैश में डेटा की कमी के मामले में कार्यों के एल्गोरिदम के बारे में बात करेंगे।

प्रॉक्सी

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

चित्र 1.13 प्रॉक्सी सर्वर

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

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

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

चित्र 1.14: अनुरोधों को संयोजित करने के लिए प्रॉक्सी सर्वर का उपयोग करना

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

चित्र 1.15: डेटा के लिए अनुरोधों को एक-दूसरे के करीब रखने के लिए एक प्रॉक्सी का उपयोग करना

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

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

सूचकांक

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

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

चित्र 1.16: सूचकांक

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

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

अक्सर ऐसे कई स्तर होते हैं, जो एक नक्शे के रूप में काम करते हैं, जो आपको एक स्थान से दूसरे स्थान तक ले जाते हैं, आदि, जब तक आपको उस डेटा का हिस्सा नहीं मिल जाता है जिसकी आपको आवश्यकता होती है। ( चित्र 1.17 देखें)

चित्र 1.17: बहुस्तरीय सूचकांक

इंडेक्स का उपयोग एक ही डेटा के कई अन्य प्रतिनिधित्व बनाने के लिए भी किया जा सकता है। बड़े डेटा सेट के लिए, यह डेटा की कई अतिरिक्त प्रतियां बनाने के लिए बिना विभिन्न फिल्टर और विचारों को परिभाषित करने का एक शानदार तरीका है।

उदाहरण के लिए, मान लीजिए कि ऊपर उल्लिखित छवि होस्टिंग प्रणाली वास्तव में पुस्तक पृष्ठों पर चित्र डालती है, और सेवा इन छवियों में क्लाइंट-साइड टेक्स्ट क्वेरी को सक्षम करती है, किसी दिए गए विषय पर सभी पाठ सामग्री को उसी तरह से देखती है जैसे कि खोज इंजन आपको HTML द्वारा खोजने की अनुमति देता है। सामग्री। इस मामले में, ये सभी पुस्तक चित्र फ़ाइलों को संग्रहीत करने के लिए बहुत सारे सर्वर का उपयोग करते हैं, और उपयोगकर्ता के लिए प्रस्तुति के लिए एक पृष्ठ ढूंढना काफी मुश्किल हो सकता है। प्रारंभ में, मनमाने शब्दों और शब्द सेटों को क्वेरी करने के लिए उलटा सूचकांक आसानी से सुलभ होना चाहिए; फिर इस पुस्तक में सटीक पृष्ठ और स्थान पर जाने और खोज परिणामों के लिए सही छवि निकालने का कार्य है। इस प्रकार, इस मामले में, उल्टे सूचकांक को स्थान पर प्रदर्शित किया जाएगा (जैसे बुक बी), और फिर बी में सभी शब्दों, स्थानों और प्रत्येक भाग में होने वाली संख्याओं के साथ सूचकांक शामिल हो सकता है।

इनवर्टेड इंडेक्स जो इंडेक्स 1 ऊपर दिए गए आरेख में प्रदर्शित कर सकता है, वह कुछ इस तरह दिखाई देगा: प्रत्येक शब्द या शब्दों का सेट उन पुस्तकों के लिए एक इंडेक्स के रूप में कार्य करता है जिनमें उन्हें शामिल किया गया है।

शब्द (शब्द)	पुस्तक (ओं)
जबरदस्त है	बुक बी, बुक सी, बुक डी
सदैव	पुस्तक सी, पुस्तक एफ
मानना	पुस्तक बी

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

और यह बड़े पैमाने पर सिस्टम में एक महत्वपूर्ण बिंदु है, क्योंकि संकुचित होने पर भी ये इंडेक्स स्टोर करने के लिए काफी बड़े और महंगे हो सकते हैं। मान लीजिए कि इस प्रणाली में हमारे पास दुनिया भर की कई किताबें हैं - 100,000,000 (ब्लॉग प्रविष्टि "अंदर Google पुस्तकें" देखें ) - और यह कि प्रत्येक पुस्तक में प्रति पृष्ठ 250 शब्दों के साथ केवल 10 पृष्ठ (गणना को सरल बनाने के लिए) शामिल हैं : यह हमें कुल 250 बिलियन शब्द देता है। यदि हम किसी वर्ण की औसत संख्या को 5 मानते हैं, और प्रत्येक वर्ण 8 बिट्स (या 1 बाइट के साथ एन्कोडेड है, भले ही कुछ वर्ण वास्तव में 2 बाइट्स पर कब्जा कर लेते हैं), इस प्रकार प्रति शब्द 5 बाइट खर्च करते हैं, तो सूचकांक प्रत्येक शब्द में केवल एक बार 1 से अधिक टेराबाइट की क्षमता के साथ भंडारण की आवश्यकता होगी। इस प्रकार, आप देखते हैं कि अनुक्रमणिका, जिसमें अन्य जानकारी भी होती है, जैसे कि शब्द सेट, डेटा स्थान और उपयोग की संख्या, बहुत तेज़ी से वॉल्यूम में बढ़ सकते हैं।

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

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

बैलेंसर्स लोड करें

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

चित्र 1.18: लोड बैलेंसर

सर्विसिंग क्वेरी के लिए कई अलग-अलग एल्गोरिदम हैं, जिनमें एक यादृच्छिक नोड चुनना, एक चक्रीय एल्गोरिथ्म या यहां तक ​​कि कुछ मानदंडों के आधार पर एक नोड चुनना, जैसे कि सीपीयू या रैम का उपयोग करना। लोड बैलेंसरों को हार्डवेयर उपकरणों या सॉफ्टवेयर के रूप में लागू किया जा सकता है। ओपन सोर्स सॉफ्टवेयर पर लोड बैलेन्सर के बीच, HAProxy सबसे व्यापक रूप से उपयोग किया जाता है।

एक वितरित प्रणाली में, लोड बैलेंसर अक्सर सिस्टम के "फ्रंट एंड" पर होते हैं, इसलिए आने वाले सभी अनुरोध सीधे उनके माध्यम से जाते हैं। यह बहुत संभावना है कि एक जटिल वितरित प्रणाली में अनुरोध को कई बैलेन्सर से गुजरना होगा, जैसा कि दिखाया गया है
आंकड़ा 1.19 ।

चित्रा 1.19: एकाधिक लोड बैलेंसर्स

प्रॉक्सी की तरह, कुछ लोड बैलेंसर भी अनुरोध के प्रकार के आधार पर विभिन्न तरीकों से अनुरोध भेज सकते हैं। उन्हें रिवर्स प्रॉक्सी के रूप में भी जाना जाता है।

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

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

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

कतारों

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

चित्र 1.20: सिंक्रोनस अनुरोध

, . , . , ( ) , , . , , , , . — , 1.20 .

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

चित्र 1.21: अनुरोधों को प्रबंधित करने के लिए कतारों का उपयोग करना

. : , , «» , . (. 1.21 .) - . , ; . , .

, . , , , . , , , , , , . , , , . — , .

. , , , - . , , , .

— , . RabbitMQ ,
ActiveMQ ,
BeanstalkD ,
Zookeeper , Redis .

1.4। निष्कर्ष

, , . , — .

---

Creative Commons Attribution 3.0 . . .

ऊपर तक
The Architecture of Open Source Applications .