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

स्केलिंग बेसिक्स

स्केलेबिलिटी - एक डिवाइस की क्षमता को बढ़ाने के लिए

संभावनाएं

कार्यात्मक ब्लॉकों की संख्या बढ़ाकर,

एक प्रदर्शन और

समान कार्य।

Glossariy.ru



आमतौर पर जब वे स्केलिंग के बारे में सोचना शुरू करते हैं

सर्वर उसे सौंपे गए कार्य के साथ सामना नहीं करता है। वास्तव में वह क्या नहीं है

कर रहा है? द्वारा किसी भी वेब सर्वर का संचालन और बड़े फोड़े को मुख्य

कंप्यूटर व्यवसाय - डेटा प्रोसेसिंग। HTTP (या किसी अन्य) अनुरोध का उत्तर दें

कुछ डेटा पर कुछ ऑपरेशन शामिल हैं। तदनुसार,

हमारे पास दो मुख्य इकाइयाँ हैं - ये डेटा (उनकी मात्रा की विशेषता) और हैं

गणना (जटिलता द्वारा विशेषता)। सर्वर इसके साथ सामना नहीं कर सकता है

डेटा की बड़ी मात्रा के कारण काम (वे शारीरिक रूप से फिट नहीं हो सकते हैं

सर्वर), या बड़े कम्प्यूटेशनल लोड के कारण। यह यहाँ के बारे में है,

बेशक, कुल भार के बारे में - एक भी अनुरोध प्रसंस्करण की जटिलता हो सकती है

छोटे, लेकिन उनमें से बड़ी संख्या सर्वर को "भर" सकती है।



हम मुख्य रूप से एक उदाहरण के साथ स्केलिंग के बारे में बात करेंगे

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

अन्य अनुप्रयोगों। पहले हम परियोजना की वास्तुकला और सरल को देखते हैं

कई सर्वरों में इसके घटकों का वितरण, और फिर आइए बात करते हैं

स्केलिंग गणना और डेटा।

विशिष्ट साइट वास्तुकला

एक विशिष्ट साइट एक बहुत ही सरल वास्तुकला के साथ शुरू होती है।

- यह एक वेब सर्वर है (आमतौर पर Apache अपनी भूमिका में कार्य करता है),

HTTP अनुरोधों को पूरा करने का काम कौन करता है,

आने वालों से। वह ग्राहकों को तथाकथित "स्थिर" देता है, फिर

सर्वर की डिस्क पर पड़ी फाइलें हैं और प्रसंस्करण की आवश्यकता नहीं है: चित्र (gif)

jpg, png), स्टाइल शीट (css), क्लाइंट स्क्रिप्ट (js, swf)। एक ही सर्वर

उन अनुरोधों पर प्रतिक्रिया देता है जिनके लिए गणना की आवश्यकता होती है - आमतौर पर यह गठन

html-पेज, हालांकि कभी-कभी चित्र और अन्य दस्तावेज़ मक्खी पर बनाए जाते हैं।

अक्सर, ऐसे अनुरोधों के उत्तर php में लिखी गई स्क्रिप्ट द्वारा उत्पन्न होते हैं,

पर्ल या अन्य भाषाएं



काम की ऐसी सरल योजना का नुकसान यह है कि वे अलग हैं

चरित्र अनुरोध (डिस्क और स्क्रिप्ट कंप्यूटिंग से फ़ाइल अपलोड)

एक ही वेब सर्वर द्वारा संसाधित। कम्प्यूटिंग प्रश्नों की आवश्यकता है

सर्वर की मेमोरी में बहुत सारी जानकारी रखें (स्क्रिप्ट भाषा दुभाषिया,

स्क्रिप्ट स्वयं, वे जिस डेटा के साथ काम करते हैं) और बहुत कुछ ले सकते हैं

कंप्यूटिंग संसाधन। इसके विपरीत स्थैतिक उत्पादन, कुछ संसाधनों की आवश्यकता है

सीपीयू, लेकिन क्लाइंट के कम होने पर लंबा समय लग सकता है

संचार की गति। अपाचे सर्वर इंटर्न प्रत्येक मान लेते हैं

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

हालांकि, सरल प्रश्नों को संभालने के लिए इष्टतम नहीं है। यह पता चला कि भारी (से)

स्क्रिप्ट और अन्य डेटा) अपाचे प्रक्रियाएं प्रतीक्षा करने में बहुत समय बिताती हैं (पहली बार प्राप्त करते समय

अनुरोध, फिर प्रतिक्रिया भेजते समय), सर्वर मेमोरी को बर्बाद कर रहा है।



इस समस्या का समाधान प्रसंस्करण कार्य का वितरण है।

दो अलग-अलग कार्यक्रमों के बीच अनुरोध - अर्थात बंटवारे में सामने और

बैकएंड। लाइटवेट फ्रंटेंड-सर्वर स्टेटिक्स और बाकी की वापसी पर कार्य करता है

बैकएंड पर रीडायरेक्ट (परदे के पीछे) का अनुरोध करता है, जहां गठन किया जाता है

पृष्ठों की है। धीमे ग्राहकों की प्रतीक्षा भी सीमा पर होती है, और यदि यह उपयोग करता है

मल्टीप्लेक्सिंग (जब एक प्रक्रिया कई ग्राहकों को सेवा प्रदान करती है - तो

उदाहरण के लिए, nginx या lighttpd का काम), फिर लगभग कुछ भी नहीं होने का इंतज़ार करना

इसके लायक।







साइट के अन्य घटकों में से, डेटाबेस में, नोट किया जाना चाहिए

जो आमतौर पर सिस्टम के मुख्य डेटा को स्टोर करता है - यहां सबसे लोकप्रिय हैं

मुफ्त DBMS MySQL और PostgreSQL। अक्सर अलग-अलग आवंटित भंडारण

चित्रों वाली बाइनरी फाइलें (उदाहरण के लिए, लेखों के लिए चित्र

साइट, अवतार और उपयोगकर्ताओं की तस्वीरें) या अन्य फाइलें।



इस प्रकार, हमने एक आर्किटेक्चर आरेख प्राप्त किया, जिसमें से एक था

कई घटक।







आमतौर पर साइट के जीवन की शुरुआत में वास्तुकला के सभी घटक

एक सर्वर पर स्थित हैं। यदि वह लोड का सामना करना बंद कर देता है, तो

एक सरल उपाय है - सबसे आसानी से वियोज्य भागों को दूसरे में स्थानांतरित करें

सर्वर। डेटाबेस के साथ शुरू करने का सबसे आसान तरीका इसे एक अलग सर्वर पर स्थानांतरित करना है और

स्क्रिप्ट में पहुंच विवरण बदलें। वैसे, इस समय हमारा सामना है

उचित कोड वास्तुकला का महत्व। अगर डेटाबेस के साथ काम कर रहा है

पूरी साइट के लिए एक अलग मॉड्यूल आम में ले जाया गया - फिर मापदंडों को ठीक करें

कनेक्शन आसान होगा।



घटकों के आगे पृथक्करण के तरीके भी स्पष्ट हैं - उदाहरण के लिए, आप फ्रंटेंड को एक अलग सर्वर पर स्थानांतरित कर सकते हैं। लेकिन आम तौर पर सामने

कम प्रणाली संसाधनों की आवश्यकता होती है और इस स्तर पर इसका निष्कासन महत्वपूर्ण नहीं होगा

प्रदर्शन लाभ। ज्यादातर अक्सर साइट प्रदर्शन पर टिकी हुई है

स्क्रिप्ट - प्रतिक्रिया (html-पेज) बनाने में बहुत लंबा समय लगता है।

इसलिए, अगला चरण आमतौर पर बैकएंड सर्वर को स्केल करना है।

कंप्यूटिंग का वितरण

एक बढ़ती साइट के लिए एक विशिष्ट स्थिति - डेटाबेस पहले से ही है

एक अलग मशीन में ले जाया गया, फ्रंटएंड और बैकएंड का पृथक्करण किया गया,

हालाँकि, ट्रैफ़िक में वृद्धि जारी है और बैकएंड की प्रक्रिया के लिए समय नहीं है

अनुरोध। इसका मतलब है कि हमें गणनाओं को कई में वितरित करने की आवश्यकता है

सर्वर। यह करना आसान है - बस एक दूसरा सर्वर खरीदें और डाल दें

कार्यक्रमों और स्क्रिप्ट काम करने के लिए बैकएंड के लिए आवश्यक है।

उसके बाद, आपको यह सुनिश्चित करने की आवश्यकता है कि उपयोगकर्ता अनुरोध वितरित किए गए हैं

(संतुलित) प्राप्त सर्वरों के बीच। विभिन्न संतुलन विधियों के बारे में

यह नीचे कहा जाएगा, अभी के लिए, हम ध्यान दें कि सामने वाला आमतौर पर ऐसा करता है,

जिसे कॉन्फ़िगर किया गया है ताकि यह समान रूप से अनुरोधों के बीच वितरित करे

सर्वर।



यह महत्वपूर्ण है कि सभी बैकएंड सर्वर सही ढंग से सक्षम हैं

पूछताछ का जवाब। आमतौर पर इसके लिए यह आवश्यक है कि उनमें से प्रत्येक के साथ काम करें

वही वर्तमान डेटासेट। अगर हम एक ही में सभी जानकारी संग्रहीत करते हैं

डेटाबेस, डीबीएमएस स्वयं साझा पहुंच और डेटा स्थिरता प्रदान करेगा।

यदि कुछ डेटा सर्वर पर स्थानीय रूप से संग्रहीत किया जाता है (उदाहरण के लिए, php सत्र

ग्राहक), तो आपको उन्हें एक साझा भंडार में स्थानांतरित करने के बारे में सोचना चाहिए, या अधिक के बारे में

परिष्कृत क्वेरी आवंटन एल्गोरिथ्म।



कई सर्वरों में वितरित न केवल काम कर सकते हैं

स्क्रिप्ट, लेकिन डेटाबेस द्वारा की गई गणना भी। अगर कोई DBMS बहुत कुछ करता है

जटिल क्वेरीज़, सर्वर प्रोसेसर का समय लेते हुए, आप कई बना सकते हैं

विभिन्न सर्वरों पर डेटाबेस की प्रतियां। यह सिंक्रनाइज़ेशन का मुद्दा उठाता है

परिवर्तन के तहत डेटा, और कई दृष्टिकोण यहां लागू होते हैं।

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

सर्वर पर सिस्टम को वितरित करने के लिए विभिन्न विकल्प हैं।

उदाहरण के लिए, हमारे पास एक डेटाबेस सर्वर और कई बैकएंड हो सकते हैं (काफी

विशिष्ट योजना), या इसके विपरीत - एक बैकएंड और कई डेटाबेस। और अगर हम पैमाने

बैकएंड सर्वर और डेटाबेस दोनों, आप बैकएंड और डेटाबेस की एक प्रति को जोड़ सकते हैं

एक कार। किसी भी मामले में, जैसे ही हमारे पास कई उदाहरण हैं

किसी भी सर्वर का, यह सवाल उठता है कि उनके बीच ठीक से वितरण कैसे किया जाए

लोड।

संतुलन के तरीके

आइए हम कई सर्वर बनाते हैं (किसी भी उद्देश्य से - http, डेटाबेस, आदि), जिनमें से प्रत्येक अनुरोधों को संसाधित कर सकता है। से पहले

हमारे पास एक कार्य है - उनके बीच के काम को कैसे वितरित किया जाए, कैसे पता लगाया जाए

सर्वर अनुरोध भेजें? अनुरोधों को वितरित करने के दो मुख्य तरीके हैं।

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

बेशक, इन दृष्टिकोणों के संयोजन हैं। उदाहरण के लिए

डीएनएस संतुलन के रूप में इस तरह के एक प्रसिद्ध लोड संतुलन विधि पर आधारित है

उस समय जब ग्राहक के आईपी पते का निर्धारण किया जाता है

कई समान सर्वरों में से एक का पता। इस प्रकार, DNS में कार्य करता है

संतुलन नोड की भूमिका जिससे ग्राहक को "वितरण" प्राप्त होता है। मगर

DNS सर्वर की संरचना के कारण विफलता के एक बिंदु की अनुपस्थिति का पता चलता है

दोहराव - अर्थात्, दो दृष्टिकोणों के गुण संयुक्त हैं। बेशक, यह

संतुलन के नुकसान भी हैं - उदाहरण के लिए, ऐसी प्रणाली को गतिशील रूप से करना मुश्किल है

पुनर्निर्माण।



साइट के साथ काम करना आमतौर पर एक अनुरोध तक सीमित नहीं है।

इसलिए, जब डिजाइन करते हैं, तो यह समझना महत्वपूर्ण है कि क्या अनुक्रमिक प्रश्न हो सकते हैं

क्लाइंट को विभिन्न सर्वरों द्वारा सही ढंग से संसाधित किया जाना चाहिए, या क्लाइंट होना चाहिए

साइट के साथ काम करते समय एक सर्वर से बंधा हुआ। यह विशेष रूप से महत्वपूर्ण है अगर

साइट उपयोगकर्ता के सत्र के बारे में (इसमें) अस्थायी जानकारी संग्रहीत करती है

मुफ्त वितरण भी संभव है - हालांकि, फिर स्टोर करना आवश्यक है

सभी स्टोरेज सर्वर के लिए सामान्य रूप से सत्र)। आगंतुक को "बाइंड" करें

एक विशिष्ट सर्वर इसके आईपी पते द्वारा हो सकता है (जो, हालांकि, बदल सकता है),

या कुकी द्वारा (जिसमें सर्वर पहचानकर्ता पहले से लिखा गया है), या यहां तक ​​कि

बस इसे इच्छित डोमेन पर पुनर्निर्देशित करें।



दूसरी ओर, कंप्यूटिंग सर्वर समान नहीं हो सकते हैं।

कुछ मामलों में, इसके विपरीत करने के लिए एक अलग सर्वर आवंटित करना लाभप्रद है

किसी एक प्रकार के प्रसंस्करण अनुरोध - और ऊर्ध्वाधर पृथक्करण प्राप्त करें

कार्य करता है। फिर क्लाइंट या बैलेंसिंग नोड सर्वर का चयन करेगा

प्राप्त अनुरोध के प्रकार पर निर्भर करता है। यह दृष्टिकोण हमें अलग करने की अनुमति देता है

बाकी से महत्वपूर्ण (या इसके विपरीत, महत्वपूर्ण नहीं, लेकिन भारी) अनुरोध।

डेटा वितरण

हमने सीखा कि संगणनाओं को कैसे वितरित किया जाए, इसलिए बड़ा

उपस्थिति हमारे लिए कोई समस्या नहीं है। हालाँकि, डेटा वॉल्यूम बढ़ता रहता है,

उन्हें संग्रहीत और संसाधित करना अधिक कठिन होता जा रहा है - जिसका अर्थ है कि यह निर्माण का समय है

वितरित डेटा वेयरहाउस। इस मामले में, अब हमारे पास एक या नहीं होगा

डेटाबेस की एक पूर्ण प्रतिलिपि वाले कई सर्वर। इसके बजाय, डेटा

विभिन्न सर्वरों में वितरित किया जाएगा। क्या वितरण योजनाएं संभव हैं?

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

सही डेटा वितरण योजना का चयन करने के लिए, आपको चाहिए

आधार की संरचना का सावधानीपूर्वक विश्लेषण करें। मौजूदा तालिकाओं (और संभवतः

व्यक्तिगत क्षेत्रों) को रिकॉर्ड तक पहुंच की आवृत्ति, आवृत्ति द्वारा वर्गीकृत किया जा सकता है

अद्यतन और संबंध (कई से चयन करने की आवश्यकता है

टेबल)।







जैसा कि ऊपर उल्लेख किया गया है, डेटाबेस के अलावा, साइट को अक्सर आवश्यकता होती है

बाइनरी फ़ाइलों के लिए भंडारण। वितरित फ़ाइल संग्रहण सिस्टम

(वास्तव में, फ़ाइल सिस्टम) को दो वर्गों में विभाजित किया जा सकता है।

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

यह ध्यान दिया जाना चाहिए कि डेटा का वितरण केवल हल नहीं करता है

एक भंडारण मुद्दा है, लेकिन यह भी आंशिक रूप से एक लोड संतुलन मुद्दा है - प्रत्येक पर

सर्वर कम रिकॉर्ड हो जाता है, और इसलिए वे तेजी से संसाधित होते हैं।

गणना और डेटा वितरण विधियों का संयोजन आपको निर्माण करने की अनुमति देता है

संभावित असीमित स्केलेबल वास्तुकला के साथ काम करने में सक्षम

किसी भी राशि का डेटा और कोई भी लोड।

निष्कर्ष

ऊपर संक्षेप में, हम संक्षिप्त सार के रूप में निष्कर्ष तैयार करते हैं।

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

संदर्भ

आप इस विषय का अध्ययन दिलचस्प अंग्रेजी भाषा की साइटों और ब्लॉगों पर कर सकते हैं:

• http://www.highscalability.com/
• http://www.royans.net/arch/
• http: //poorbuthappy.com/ease / ... -bloglines-vox-and-more
• http://www.possibility.com/epowiki/Wiki.jsp?page=Scalability

पुनश्च टिप्पणियाँ, ज़ाहिर है, स्वागत है ;)