स्केलिंग-अप बनाम-आउट के कारण नहीं?

Question

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

बनाम स्केलिंग के लिए आपके पास क्या कारण हैं? मूल्य, प्रदर्शन, दृष्टि, अनुमानित उपयोग? यदि हां, तो यह आपके लिए कैसे काम करता है?

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

इतने सारे एंटरप्राइज़ सिस्टम OLTP हैं और डेटा shard'd नहीं हैं, लेकिन कई लोगों की इच्छा क्लस्टर या स्केल-आउट है। क्या यह नई तकनीकों या कथित प्रदर्शन की प्रतिक्रिया है?

आज सामान्य रूप से एप्लिकेशन या हमारे प्रोग्रामिंग मैट्रा स्केल-आउट के लिए खुद को बेहतर उधार देते हैं? क्या हमें भविष्य में इस प्रवृत्ति को हमेशा ध्यान में रखना चाहिए?

Answer 1

आश्चर्य की बात नहीं है, यह सब आपकी समस्या पर निर्भर करता है। यदि आप इसे आसानी से उपप्रोबम्स में विभाजित कर सकते हैं जो अधिक संवाद नहीं करते हैं, तो स्केलिंग से छोटी गति होती है। उदाहरण के लिए, 1 बी वेब पृष्ठों में एक शब्द खोजना एक मशीन द्वारा 1 बी पृष्ठों को खोजना, या 1 एम मशीनों द्वारा 1000 पृष्ठों को दक्षता में महत्वपूर्ण हानि के बिना किया जा सकता है (इसलिए 1,000,000x स्पीडअप के साथ)। इसे "शर्मनाक समानांतर" कहा जाता है।

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

बेशक, यह एक काफी सैद्धांतिक दृष्टिकोण है। अन्य कारक, जैसे I/O, विश्वसनीयता, प्रोग्रामिंग में आसान (एक बड़ी साझा-मेमोरी मशीन आमतौर पर क्लस्टर की तुलना में बहुत कम सिरदर्द देती है) का भी बड़ा प्रभाव हो सकता है।

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

Answer 2

क्योंकि

• स्केलिंग बॉक्स के आकार के द्वारा अंत में सीमित हैं आप वास्तव में खरीद सकते हैं
• अत्यंत लागत अप्रभावी है, उदा बन सकता है 128 कोर और 128 जी रैम वाली मशीन 8 कोर और 8 जी रैम के साथ 16 से काफी महंगा है।
• कुछ चीजें अच्छी तरह से स्केल नहीं होती हैं - जैसे आईओ पढ़ने के संचालन।
• स्केलिंग करके, यदि आपका आर्किटेक्चर सही है, तो आप उच्च उपलब्धता भी प्राप्त कर सकते हैं। एक 128-कोर, 128 जी रैम मशीन बहुत महंगा है, लेकिन दूसरा अनावश्यक होने के लिए आनुपातिक है।

और कुछ हद तक, क्योंकि Google यही करता है।

Answer 3

embarrassingly parallel समस्याओं के लिए स्केलिंग आउट सर्वोत्तम है। इसमें कुछ काम होता है, लेकिन कई वेब सेवाएं उस श्रेणी में फिट होती हैं (इस प्रकार वर्तमान लोकप्रियता)। अन्यथा आप Amdahl's law में भागते हैं, जिसका मतलब है कि गति प्राप्त करने के लिए आपको बाहर निकलना होगा। मुझे संदेह है कि आप उस समस्या में भाग गए हैं। आईओ बाध्य संचालन भी काफी हद तक स्केलिंग के साथ अच्छा प्रदर्शन करते हैं क्योंकि आईओ के लिए इंतजार करना समानांतर है जो समानांतर है।

Answer 4

ब्लॉग पोस्ट Scaling Up vs. Scaling Out: Hidden Costs जेफ एटवुड द्वारा सॉफ़्टवेयर लाइसेंसिंग और बिजली लागत जैसे कुछ रोचक बिंदुओं पर विचार करना है।