डेटा सेंटर के साथ विलंबता क्या है? मैं यह मानता हूं कि अंतर के परिमाण के आदेश हैं


18

मैं ऐसी किसी चीज़ का पता लगाने की कोशिश कर रहा हूं, जिसका मुझे कोई अच्छा जवाब नहीं मिल रहा है।

अगर मैं डेटा सेंटर में बैठा एक REDIS कैश (या कुछ बाहरी इन-मेमोरी कैश) और एक ही डेटा सेंटर में एक एप्लीकेशन सर्वर कह रहा हूं, तो डेटा पढ़ने के लिए नेटवर्क कनेक्शन (विलंबता, थ्रूपुट) की गति क्या होगी इन दो मशीनों के बीच?

क्या नेटवर्क "गति", उदाहरण के लिए, अभी भी कम से कम परिमाण का एक क्रम होगा RAM की गति जो REDIS पर कैश से मेरे डेटा की मांग कर रही है?

मेरा अंतिम प्रश्न है - क्या यह सब REDIS की स्मृति में बैठकर वास्तव में कोई उपयोगिता प्रदान कर रहा है? इसके साथ विरोध अगर REDIS इसके बजाय एक SSD के लिए यह सब कर रहा था? याददाश्त महंगी है। यदि नेटवर्क वास्तव में डेटा सेंटर के साथ एक अड़चन नहीं है, तो मेमोरी का मूल्य है। नहीं तो नहीं।

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


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

जवाबों:


20

"विलंबता चार्ट सभी को पता होना चाहिए" के कई संस्करण हैं जैसे:

बात यह है कि, वास्तव में, केवल विलंबता से अधिक है। यह कारकों का एक संयोजन है।

तो, एक डेटा सेंटर के भीतर नेटवर्क विलंबता क्या है? विलंबता, अच्छी तरह से मैं कहूंगा कि यह "हमेशा" 1ms से नीचे है। क्या यह रैम से तेज है? क्या यह रैम के करीब है? मुझे ऐसा नहीं लगता।

लेकिन सवाल यह है कि क्या यह प्रासंगिक है। क्या आपको पता होना चाहिए कि डेटम है? आपका सवाल मेरे लिए मायने रखता है। जैसा कि सब कुछ की लागत है, क्या आपको अधिक रैम प्राप्त करना चाहिए ताकि सभी डेटा रैम में रह सकें या समय-समय पर डिस्क से पढ़ना ठीक हो।

आपकी "धारणा" यह है कि यदि एसएसडी की गति की तुलना में नेटवर्क विलंबता अधिक (धीमी) है, तो रैम में सभी डेटा होने से आपको लाभ नहीं होगा क्योंकि आपके पास नेटवर्क धीमा होगा।

और ऐसा प्रतीत होता है। लेकिन, आपको कंसीडर को भी ध्यान में रखना होगा। यदि आप एक बार में डेटा के लिए 1,000 अनुरोध प्राप्त करते हैं, तो क्या डिस्क 1,000 समवर्ती अनुरोध कर सकती है? बेशक नहीं, तो उन 1,000 अनुरोधों को पूरा करने में कितना समय लगेगा? रैम की तुलना में?

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

ठीक उसी तरह जब तक कि 12Gbps डिस्क बाजार में दिखाई नहीं देता, 10Gbps नेटवर्क लिंक एक भी स्ट्रीम द्वारा ओवरलोड नहीं किया जाएगा क्योंकि डिस्क अड़चन थी।

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

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


अब तक मैं आपके प्रश्न के कुछ विवरणों से बचता था - विशेष रूप से, रेडिस भाग।

Redis एक ओपन सोर्स (BSD लाइसेंस प्राप्त), इन-मेमोरी डेटा स्ट्रक्चर स्टोर है, जिसका इस्तेमाल डेटाबेस, कैश और मैसेज ब्रोकर के रूप में किया जाता है। - https://redis.io/

ठीक है, इसका मतलब है कि सब कुछ स्मृति में है। क्षमा करें, यह तेज़ SSD ड्राइव आपको यहाँ मदद नहीं करेगा। रेडिस डेटा को डिस्क पर बनाये रख सकता है, इसलिए इसे पुनः आरंभ करने के बाद रैम में लोड किया जा सकता है। यह केवल डेटा को "खोने" के लिए नहीं है या फिर से शुरू होने के बाद एक ठंडा कैश को फिर से खोलना है। तो इस मामले में, आपको रैम का उपयोग करना होगा, चाहे जो भी हो। अपना डेटा सेट रखने के लिए आपके पास पर्याप्त रैम होना चाहिए। पर्याप्त रैम नहीं है और मुझे लगता है कि आपका ओएस उपयोग करेगा swap- शायद एक अच्छा विचार नहीं है।


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

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

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

लेकिन 10g नेटवर्क लिंक कम अंत है। मेरे सर्वर 200gigabit (हाँ, 2x100g लिंक) के साथ मेरी रीढ़ से जुड़े हैं।
टॉमटॉम

3

कंप्यूटर सिस्टम में कैश की कई परतें होती हैं। API और डेटाबेस क्वेरीज़ को कैशिंग करके एप्लिकेशन लेयर में एक को सम्मिलित करना फायदेमंद हो सकता है। और संभवतः उपयोगकर्ता सत्रों की तरह अस्थायी डेटा।

Redis जैसे डेटा स्टोर एक नेटवर्क (तेज़) या UNIX सॉकेट (इससे भी तेज़) पर ऐसी सेवा प्रदान करते हैं, जैसे आप एक डेटाबेस का उपयोग करेंगे।

आपको यह मापने की आवश्यकता है कि आपका आवेदन वास्तव में कैसा प्रदर्शन करता है, लेकिन चलो एक उदाहरण बनाते हैं। मान लें कि एक सामान्य उपयोगकर्ता अनुरोध 5 एपीआई प्रश्न करता है जो प्रत्येक में 50 एमएस लेता है। 250 एमएस उपयोगकर्ता का पता लगाने योग्य विलंबता है। परिणामों के कैशिंग के विपरीत। भले ही शहर भर में कैश एक अलग उपलब्धता क्षेत्र में है (इष्टतम नहीं), हिट्स संभवत: 10 एमएस हैं। जो कि 5x स्पीडअप होगा।

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

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

याददाश्त महंगी है।

100 ns एक्सेस समय पर DRAM ठोस अवस्था के स्थायी भंडारण की तुलना में लगभग 100x तेज है। यह इस प्रदर्शन के लिए अपेक्षाकृत सस्ती है। कई अनुप्रयोगों के लिए, थोड़ा अधिक रैम मूल्यवान गति और प्रतिक्रिया समय खरीदता है।


क्या आप कृपया स्पष्ट कर सकते हैं कि आपने कैसे गणना की है कि उन 5 एपीआई प्रश्नों में से प्रत्येक में 50 एमएस हैं? क्या यह डेटाबेस की मार और आवेदन की आड़ में क्वेरी कर रहा है और परिणाम सेट की गणना कर रहा है, बनाम पूरे शहर में एक कैश मार रहा है जो होता है कि क्वेरी स्ट्रिंग को कुंजी के रूप में कैश किया गया है, और उस परिणाम की कैश्ड प्रतिलिपि है सेट?
नीरज मुरारका

1
मैंने उन नंबरों को बनाया, लेकिन हाँ। किसी क्वेरी को करने और परिणाम की गणना करने से उस पूर्व-संगणित परिणाम को प्राप्त करने की तुलना में धीमा होने की संभावना है। रेडिस जैसे कार्यान्वयन सादगी और गति के लिए स्मृति में होते हैं। IP नेटवर्क या UNIX सॉकेट ट्रांसपोर्ट को ट्रैवर्स करना भी काफी तेज़ हो सकता है। सभी ने कहा, यह कैशिंग सामान हर डिजाइन के लिए आवश्यक नहीं है।
जॉन महोवाल्ड

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

1
रिमोट डेटासेंटर सबसे खराब स्थिति है, आदर्श रूप से कैश टियर अपने ग्राहकों से 1 एमएस से कम है। शायद एक ही उपलब्धता क्षेत्र, या एक ही मेजबान पर भी। अगर आप चाहें तो लगातार स्टोरेज को कैश कर सकते हैं। या, आप प्राथमिक डेटाबेस के लिए ठोस राज्य भंडारण का उपयोग कर सकते हैं, सभी प्रश्नों को गति दे सकते हैं, और संभवतः कैशिंग टीयर की आवश्यकता नहीं है। कई संभावित डिजाइन हैं।
जॉन महोवाल्ड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.