पूंछ की स्केलिंग

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

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

भिन्नता कहाँ से आती है?

अलग-अलग सिस्टम घटकों में बड़ी पूंछ देरी (देरी वितरण की लंबी पूंछ) के कारण प्रतिक्रिया समय में भिन्नता निम्नलिखित कारणों से हो सकती है:

साझा किए गए संसाधन

साझा संसाधनों के लिए लड़ रहे कई अलग-अलग अनुप्रयोगों द्वारा मशीनों को साझा किया जा सकता है (सीपीयू, प्रोसेसर कैश, मेमोरी, नेटवर्क), प्लस, आवेदन के भीतर ही, साझा संसाधनों के लिए संघर्ष भी हो सकता है;

दानव (डेमन)

पृष्ठभूमि डेमॉन औसत संसाधनों की एक सीमित मात्रा में, औसतन संसाधनों का उपयोग कर सकते हैं और कर सकते हैं, लेकिन जब वे बहु-मिलीसेकंड जंप कर सकते हैं;

वैश्विक साझा संसाधन

विभिन्न मशीनों पर चलने वाले एप्लिकेशन वैश्विक संसाधनों (स्विच, साझा फ़ाइल सिस्टम) के लिए प्रतिस्पर्धा कर सकते हैं;

रखरखाव गतिविधियों

पृष्ठभूमि गतिविधि ( बिगटेबल में लॉग्स की आवधिक संपीड़न, कचरा संग्रह के साथ भाषाओं में कचरा संग्रह, आदि) देरी समय में आवधिक कूद पैदा कर सकता है;

कतारों

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

आयरन परिवर्तनशीलता को भी प्रभावित करता है:

शक्ति की सीमा

आधुनिक सीपीयू को उनके औसत पावर रेंज पर अस्थायी रूप से काम करने में सक्षम बनाने के लिए डिज़ाइन किया गया है, जबकि थ्रॉटलिंग मोड के कारण ओवरहीटिंग से जूझ रहा है, अगर ऐसी गतिविधि लंबे समय तक जारी रहती है;

कचरा संग्रह

SSDs हमें बहुत तेज़ रैंडम रीड एक्सेस देते हैं, लेकिन बड़ी संख्या में डेटा ब्लॉक्स की आवधिक असेंबली की आवश्यकता को वस्तुतः 100 गुना बढ़ा सकते हैं, यहां तक ​​कि लेखन गतिविधि के एक बचे हुए स्तर के साथ;

ऊर्जा प्रबंधन

कई प्रकार के उपकरणों में ऊर्जा-बचत मोड वास्तव में ऊर्जा की एक निश्चित मात्रा को बचा सकता है, लेकिन साथ ही डिवाइस को निष्क्रिय से सक्रिय मोड में जाने पर विलंब समय में वृद्धि करता है।

स्केलिंग द्वारा बढ़ाया गया घटक-स्तरीय परिवर्तनशीलता

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

पूरे सिस्टम में व्यक्तिगत घटकों की देरी के वितरण में परिवर्तनशीलता; उदाहरण के लिए, एक प्रणाली पर विचार करें जहां 99% मामलों में प्रत्येक सर्वर 10 एमएस के लिए जिम्मेदार है, और शेष प्रतिशत में - 1 सेकंड से अधिक। यदि उपयोगकर्ता के अनुरोध को इस तरह के एक सर्वर द्वारा संसाधित किया जाता है, तो 100 में से केवल एक प्रतिक्रिया धीमी होगी (एक सेकंड से अधिक)। नीचे दी गई छवि दिखाती है कि इस परिदृश्य में सर्वर-स्तरीय विलंबता लंबे अनुरोधों के अनुपात (बहुत कम) पर निर्भर करती है। यदि किसी उपयोगकर्ता अनुरोध को 100 ऐसे सर्वरों से प्रतिक्रियाएं एकत्र करनी हैं, तो उपयोगकर्ता अनुरोधों के 63% (1 - 0.99 ^ 100) * 100) को 1 सेकंड (ग्राफ़ में "x" से अधिक समय लगेगा। भले ही बहु-प्रतिसाद 10,000 प्रति अनुरोध केवल एक बार होता है, 2,000 ऐसे सर्वरों के साथ एक सेवा के लिए, लगभग हर 5 वां उपयोगकर्ता एक सेकंड (ग्राफ पर "ओ") से अधिक समय तक इंतजार करेगा।

तालिका 1 Google सेवाओं में से एक के लिए माप दिखाती है, जिसका तर्क उपरोक्त परिदृश्य के समान है। रूट सर्वर इंटरमीडिएट सर्वर के माध्यम से बहुत बड़ी संख्या में लीफ सर्वर के माध्यम से अनुरोध वितरित करता है। तालिका शाखा प्रणाली की निर्भरता और देरी के वितरण को दर्शाती है। घोड़े के सर्वर पर मापा गया एक यादृच्छिक अनुरोध के लिए देरी का 99 वां प्रतिशत 10 एमएस है। हालांकि, सभी अनुरोधों के लिए 99 प्रतिशत की देरी 140 एमएस है, और 95% अनुरोधों के लिए देरी की 99 वीं प्रतिशतता 70 एमएस है, अर्थात्। सबसे धीमे 5% प्रश्नों की प्रतीक्षा में 99 वें प्रतिशत तक देरी के आधे समय का योगदान होता है। इन पद्धतियों पर ध्यान केंद्रित करने वाले तरीके सबसे धीमी गति से पूरे सिस्टम के प्रदर्शन पर बहुत महत्वपूर्ण प्रभाव डाल सकते हैं।

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

अलग-अलग घटकों के देरी समय की परिवर्तनशीलता का उन्मूलन

निम्नलिखित इंजीनियरिंग समाधान इसके साथ मदद कर सकते हैं:

सेवाओं का वर्गीकरण और उच्च-स्तरीय कतारों का कार्यान्वयन

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

कतार के सिर के कारण घटे ताले (हेड-ऑफ-लाइन ब्लॉकिंग)

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

पृष्ठभूमि गतिविधि प्रबंधन और सिंक्रनाइज़ व्यवधान

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

विलंब भिन्नता के साथ कैसे जीना है

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

एकल अनुरोध के भीतर अल्पकालिक उपाय

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

हेज के अनुरोध

देरी की परिवर्तनशीलता को कम करने का एक आसान तरीका कई प्रतिकृतियों के लिए मूल अनुरोध को दोहराना और परिणाम के रूप में पहली प्रतिक्रिया का उपयोग करना है। हम ऐसे अनुरोधों को "बचाव अनुरोध" कहते हैं, क्योंकि ग्राहक पहले एक प्रतिकृति के लिए एक अनुरोध भेजता है जिसे वह सबसे उपयुक्त मानता है, और फिर, थोड़ी देरी के बाद, माध्यमिक अनुरोध भेजना शुरू कर देता है। क्लाइंट केवल पहले के बाद आए उत्तरों को अस्वीकार कर देता है। और यद्यपि इस पद्धति का कार्यान्वयन "माथे पर" सिस्टम में अस्वीकार्य भार जोड़ता है, ऐसे कई विकल्प हैं जो देरी के समय को गंभीरता से कम कर सकते हैं, जबकि केवल लोड को थोड़ा बढ़ा सकते हैं। उदाहरण के लिए, आप द्वितीयक अनुरोधों के वितरण में देरी कर सकते हैं जब तक कि पहले अनुरोध के लिए प्रतीक्षा करने का समय अनुरोधों के इस वर्ग के लिए देरी के 95 वें प्रतिशत से अधिक न हो। यह दृष्टिकोण केवल 5% अनुरोधों के लिए लोड में वृद्धि की ओर जाता है, जबकि एक ही समय में देरी वितरण की पूंछ को काफी छोटा करता है। यह विधि काम करती है क्योंकि देरी का स्रोत एक विशिष्ट अनुरोध और इसकी विशेषताएं नहीं है, लेकिन सबसे अधिक संभावना है कि हस्तक्षेप के कुछ अन्य रूप। उदाहरण के लिए, Google प्रदर्शन परीक्षण में, जहां 1000 कुंजी के मान पढ़े जाते हैं, 100 से अधिक सर्वरों में वितरित बिगटेबल टेबल में संग्रहीत, 10 एमएस देरी के बाद हेज अनुरोध भेजना, 1800 से 74 एमएस तक सभी 1000 कुंजी प्राप्त करने में देरी के 99.9 वें प्रतिशत को कम कर देता है। यह केवल 2% अधिक अनुरोध भेजता है। हेज अनुरोधों के ओवरहेड को मुख्य अनुरोधों की तुलना में कम प्राथमिकता देकर आगे कम किया जा सकता है।

बंधे हुए अनुरोध

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

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

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

, , . , 3 , : ; ; (hot spot), ( ) . Distributed Shortest-Positioning Time First system ( — . ), , , , , , .

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

, , ( ). , , : -, , — , ( , ). -, , , , .

-

Google (), , ( ) . - . — 20 , 5% 1/20 , 1--1 (With an average of, say, 20 partitions per machine, the system can shed load in roughly 5% increments and in 1/20th the time it would take if the system simply had a one-to-one mapping of partitions to machines). BigTable (tablets) , 20-1000 . -, .. , , . - , आभासी प्रोसेसर (आभासी प्रोसेसर-विभाजन), द्वारा वर्णित के साथ Stoica और विभाजन विधि डेविट ।

चयनात्मक प्रतिकृति

- , . , , , - -. Google , -. - , . , .

, (Latency-induced probation)

, , , ( ) . : (interference from unrelated networking traffic ). , , , , . , , , - .

बड़ी सूचना पुनर्प्राप्ति प्रणाली

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

काफी अच्छा है

, , (« ») . , — (. ) — , 1000 , , . , Google , , , . ; , .

(canary requests)

, , . Google « »; , , . , . , , . , , DOS-.
- , , . 1. , Google , .

, , , , , . , () : -, , , . -, . -, , (tolerate inconsistent update models for (inherently more latency-tolerant) mutations). , , , , ( Paxos Lamport एल्गोरिथ्म ), क्योंकि इन एल्गोरिदम को केवल 3-5 प्रतिकृतियां करनी चाहिए - वे परिभाषा द्वारा मजबूत हैं।

लोहे में रुझान और उनका प्रभाव

, , . , . , , . , . , ( bisection bandwidth ) , (per-message overheads) ( , remote direct-memory access), संबंधित अनुरोधों की लागत को कम करेगा, इस संभावना को प्रदान करेगा कि अनावश्यक कार्यों से बचने के लिए रद्द करने के अनुरोध समय पर प्राप्त होंगे। किसी एक संदेश को संसाधित करने की लागत को कम करने से स्वाभाविक रूप से मल्टीप्लेक्सिंग में सुधार होगा और कतार के प्रमुख के कारण अवरुद्ध होने से बच जाएगा।

निष्कर्ष

- , . . , .. , , . , .. . , , , . , , . , , Google. , - .
, , , , c . , , . , () .