NALSD इंटरव्यू के दौरान क्या सोचें

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

तो, अंतर क्या है? इस साक्षात्कार के लिए कैसे तैयार रहें? चलो गैर-अमूर्त हैं, और एक उदाहरण का उपयोग करें। अधिक गैर-सार होने के लिए, आइए हम भौतिक दुनिया से कुछ लेते हैं, जैसे कि आपसे वास्तविक साक्षात्कार में बिल्कुल वही बात नहीं पूछी जाएगी (कम से कम, Google साक्षात्कार में नहीं) :)

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

NALSD साक्षात्कार: एक सार्वजनिक पुस्तकालय प्रणाली डिजाइन।

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

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

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

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

मान लीजिए 6 का एक औसत झटका-अप कारक, जो हमें 6000 पुस्तकों की एक इकाई भंडारण क्षमता की ओर ले जाएगा। कम भंडारण का मतलब होगा सबसे लोकप्रिय नामों (अच्छी तरह से, छोटी इकाइयां अभी भी उपयोगी हो सकती हैं - जैसे, "ट्वाइलाइट" के साथ एक छोटा मॉल कियोस्क, लेकिन चलो इसे अभी हमारे डिजाइन के बाहर रखें)।

एक स्थिर स्थिति में, हर दिन रिटर्न और उधार लगभग समान होते हैं (कुछ फैलाव के साथ), लेकिन हमें चोटी के रिटर्न की योजना भी बनानी चाहिए (जो बाहरी सिंक की घटनाएं हो सकती हैं: छुट्टियां, रुझान आदि)। सही तरीका यह है कि एक सांख्यिकीय मॉडल बनाया जाए और उसे चलाया जाए। लेकिन अभी के लिए, चलो बस एक बफर के रूप में रखना। इसका मतलब है कि हमें 2000 के लिए 6000 किताबों को हाथ से निकालने के लिए तैयार रखना चाहिए।

योग करने के लिए: हमें 8000 पुस्तकों के भंडारण के साथ एक पुस्तकालय इकाई की आवश्यकता है। हर दिन इसे बहाल करने के लिए महंगा होने की उम्मीद है, इसलिए हमें उम्मीद करनी चाहिए कि यह एक या दो सप्ताह के लिए पर्याप्त होगा। दो सप्ताह, 6000 पुस्तकें, संभव रिटर्न तिरछा के साथ, यह एक दिन में लगभग 300 किताबें हैं। शुरुआती दिन के लिए, हम टर्नओवर की शुरुआती 2000 पुस्तकों को टर्नओवर करने के लिए पूरे स्टोरेज (8000 पुस्तकों) को भर सकते हैं। ३ दिन में २००० = प्रतिदिन ६०० पुस्तकें, तिरछा बफर = day०० पुस्तकें प्रतिदिन।

चलो हमारे भंडारण के थ्रूपुट और सीमाओं का अनुमान लगाते हैं। 1 पुस्तक लगभग 2 रैखिक सेमी स्पेस, 8000 पुस्तकें = 160 मीटर है। हम इसे 4 बार लंबवत मोड़ सकते हैं, इसलिए यह 40 रैखिक मीटर है। यदि हम इसे ~ 5-मीटर रैक में विभाजित करते हैं, तो हमें 4 अलमारियों के साथ 8 रैक मिलेंगे, प्रत्येक 5 मीटर लंबा होगा। एक लाइब्रेरियन (या रोबो-लाइब्रेरियन) को दो रैक के साथ काम करने में सक्षम होना चाहिए; एक एकल पुस्तक का एक निष्कर्षण लगेगा: अलमारियों पर चलने के लिए 5 सेकंड, पुस्तक को अपने स्थान पर खींचने / लगाने में 5 सेकंड, चलने के लिए 5 सेकंड (कुल 15 सेकंड)। 4 लाइब्रेरियन हमें प्रति मिनट 15 पुस्तकों का शिखर थ्रूपुट देंगे। इस प्रकार, अधिकतम प्रति घंटे 900 पुस्तकों की हैंडलिंग।

अगर हम रिक्वेस्ट हैंडलिंग टाइम (10s), सर्च टाइम (5s), सिस्टम में ट्रैक करने का समय (2s) को भी ध्यान में रखते हैं, तो हमें 400 किताबें / घंटे की चोटी मिलेगी। इसलिए, हमें 2 घंटे में एक दिन में 800 पुस्तकों के हमारे अनुमान को संभालने में सक्षम होना चाहिए।

आइए अन्य पहलुओं की गणना करें: 4 लाइब्रेरियन द्वारा 400 पुस्तकों / घंटे को देने में सक्षम होने के लिए, हमें लाइन में प्रतीक्षा कर रहे 100 लोगों के लिए पर्याप्त जगह की आवश्यकता है, और प्रवेश द्वार के दोनों दिशाओं में 400 लोगों / घंटे को चलने की अनुमति चाहिए । इसका मतलब है कि हमारा मुख्य थ्रॉटलिंग वेटिंग स्पेस और बिल्डिंग डोर होगा।

इसका मतलब है कि हमें वास्तविक डिजाइन के लिए उचित गणना के दौरान भंडारण स्थान और प्रतीक्षा क्षेत्र के बीच एक इष्टतम संतुलन का पता लगाने में सक्षम होना चाहिए।

यह इस स्तर के लिए है, यह आगे बढ़ने का समय है। हमारे पास 10000 पुस्तकों / दिन के रूप में समग्र पुस्तकालय नेटवर्क मांगों का अनुमान है। एक इकाई 800 पुस्तकें / दिन है, इसलिए हमें 12.5 इकाइयों की आवश्यकता है। यदि हम एक समान भौगोलिक वितरण करते हैं, तो प्रत्येक पाठक को 1-2 इकाइयों (शहर की सीमा पर) और 3-4 (शहर के अंदर) की सीमा के भीतर होना चाहिए। यह चोटियों को थोड़ा चिकना करने और शीर्ष पुस्तकों की कमी को पूरा करने की क्षमता देगा।

हम यह भी जानते हैं कि हर पुस्तकालय को किसी भी समय (अग्नि, निरीक्षण, फ्रिज के दरवाजे को रिप्रेंट आदि को बंद किया जा सकता है), और यह कि हमारे पास जितनी अधिक इकाइयाँ होंगी, इन घटनाओं के संयोग की संभावना उतनी ही अधिक होगी। इस प्रकार, हमें प्रत्येक 5-6 इकाइयों के लिए 1 निरर्थक इकाई की आवश्यकता है। इसलिए, कुल मिलाकर, हमें अपने शहर की मांगों को पूरा करने के लिए 15 इकाइयों की आवश्यकता है, अगर हम प्रत्येक इकाई के भीतर आवश्यक आपूर्ति बनाए रखेंगे।

जैसा कि हमने पहले ही सोचा था, हमें हर हफ्ते या दो (पहले हमने दो अनुमान लगाया) स्टोरेज को फिर से भरना होगा - ट्रेंड्स का पालन करने के लिए स्टोरेज का लगभग आधा हिस्सा बदला जाना चाहिए। तो नई डिलीवरी की 4000 किताबें और उससे 4000 किताबें हटा दी गईं। प्रत्येक रिस्टॉक पर, हमें 4000 पुस्तकों को निकालने और 4000 नई प्रविष्टियाँ वापस लाने की आवश्यकता है। हमारी 400 पुस्तकों / घंटे की थ्रूपुट के साथ, एक रेस्टॉक 10 बहुत गहन घंटे होंगे। खैर, यह अभी भी ठीक लगता है, खासकर जब से थोक संचालन आमतौर पर सस्ता होता है; लेकिन वैसे भी - हमें यह ध्यान रखना चाहिए कि रेस्टॉक ऑपरेशन सिर्फ सेवारत की तुलना में 5 गुना अधिक महंगा है।

एक औसत पुस्तक (2 सेमी * 20 सेमी * 30 सेमी) 1.5 लीटर मात्रा है, इसलिए 4000 पुस्तकें = 6 घन मीटर है। यह एक एकल औसत प्रकाश कार्गो वाहन में फिट होना चाहिए। 1 घन मीटर का वजन 600 किलोग्राम, 6 मीटर ^ 3 = 3.6 टन है। एक औसत प्रकाश कार्गो वाहन ~ 1.5 टन को संभालने में सक्षम है, इसलिए हमें उनमें से 3 की आवश्यकता है। अतिरेक के लिए एक प्लस। हमारे पास हर 2 सप्ताह में एक बार 15 पुस्तकालय इकाइयाँ ताज़ा होती हैं, जिसका अर्थ है कि यह समय पर कड़ी होगी, इसलिए हमें एक और कार की आवश्यकता है।

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

समय समाप्त हो गया है। तो, NALSD प्रश्न में ऐसा क्या खास है? स्केलेबिलिटी किसी भी बड़े सिस्टम डिज़ाइन से अपेक्षित है। लेकिन NALSD इंटरव्यू में, किसी को विशिष्ट होना चाहिए।

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

मुझे अभी भी याद है कि कैसे मेरे NALSD इंटरव्यू के दौरान मैं एक एकल HDD के IOPS के साथ 600 के बराबर था, सिर्फ इसलिए कि मैंने हाल ही में कुछ RAID सरणी के अनुकूलन पर काम किया था, जहाँ पूरे सरणी में 600 IOPS थे ... साक्षात्कारकर्ता को थोड़ा आश्चर्य हुआ: 600 IOPS प्रति ड्राइव? : डी

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

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

एसआरई के रूप में, हमें वास्तविक हार्डवेयर सीमाओं की बाधाओं के भीतर वास्तविक प्रणालियों की मापनीयता के बारे में सोचना होगा। एक सुंदर एल्गोरिथ्म हो सकता है जो रैम की कुछ मात्रा में विशाल समय जटिलता का आदान-प्रदान करता है ... लेकिन फिर भी, 1 सीपीयू प्रति 1 जीबी रैम कुछ ऐसा नहीं है जिसे हम आज बना सकते हैं। इसलिए अगर हमारे पास 1 PiB RAM है, तो हमारे पास लगभग 10k CPU भी हैं। या 20 कि। या यहां तक ​​कि 30k। इसका मतलब है कि हमें वास्तविक (वास्तविक) इष्टतम पर ध्यान केंद्रित करना चाहिए, जो आज वास्तविकता में उपलब्ध है, न कि आदर्श परिस्थितियों में वैश्विक इष्टतम पहुंच योग्य।

आपको सटीक संख्या याद नहीं होनी चाहिए, लेकिन आपको परिमाण के आदेश प्राप्त करने के लिए अंगूठे के नियमों को लागू करने में सक्षम होना चाहिए। जैसे, IOPSes: HDD लगभग 100s, SSD लगभग 100s हजारों। लेकिन ये 100s HDD से SSD जैसे कि 1: 3 या 1: 4 के बीच कीमत के अंतर के साथ आते हैं। यह आस-पास की हर चीज को भी नजरअंदाज कर रहा है: रैक स्पेस, ड्राइव्स, नेटवर्क पोर्ट्स और अन्य चीजों के लिए ब्लेड, जो पेटा और एक्सा-स्केल पर काम करने के बाद अब सस्ते नहीं हैं।

अब अपनी कुर्सी पर आराम करें, आराम करें और सदस्यता पर ताजे चिकन अंडे के विकास और वितरण की एक प्रणाली डिजाइन करने का प्रयास करें।