आप Google नहीं हैं

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

यह बिल्कुल नहीं है कि तर्कसंगत लोग कैसे निर्णय लेते हैं। लेकिन वास्तव में इसलिए डेवलपर्स उदाहरण के लिए, MapReduce का उपयोग करने का निर्णय लेते हैं।

जैसा कि जो हेलरस्टीन ने स्नातक छात्रों के लिए डेटाबेस पर अपने व्याख्यान में उल्लेख किया (54 वें मिनट में):

तथ्य यह है कि दुनिया में लगभग 5 कंपनियां हैं जो इस तरह के महत्वाकांक्षी कार्य करती हैं। बाकी सभी के लिए ... वे एक अविश्वसनीय-सहिष्णु प्रणाली प्रदान करने के लिए अविश्वसनीय संसाधन खर्च करते हैं जो उन्हें वास्तव में ज़रूरत नहीं है। 2000 के दशक में लोगों को एक तरह की "googleing" थी: "हम सब कुछ ठीक उसी तरह करेंगे जैसे कि Google करता है, क्योंकि हम दुनिया की सबसे बड़ी डेटा प्रोसेसिंग सेवा का प्रबंधन भी करते हैं ..." [विडंबना है कि वह अपना सिर हिलाता है और दर्शकों से हँसी की प्रतीक्षा करता है]

आपके डेटा सेंटर की बिल्डिंग में कितने फ्लोर हैं? Google ने मेक्स काउंटी, ओक्लाहोमा में स्थित इस विशेष डेटा सेंटर में कम से कम चार पर रहने का फैसला किया।

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

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

हां, यह लेख कार्गो पंथ का एक और विरोधी है। लेकिन रुकिए, मेरे पास आपके लिए एक उपयोगी चेकलिस्ट है, जिसका उपयोग आप अधिक सूचित निर्णय लेने के लिए कर सकते हैं।

कूल फ्रेमवर्क: UNPHAT

अगली बार जब आप अपने सिस्टम को आकार देने (पुनः) के लिए कुछ नई कूल तकनीक का उपयोग कर रहे हैं, तो मैं आपसे आग्रह करता हूं कि आप रुकें और बस यूनाईटेड सिस्टम का उपयोग करें:

1. (अंडरस्टैंड) समस्या को समझने से पहले संभावित समाधान के बारे में सोचने की कोशिश भी न करें। आपका मुख्य लक्ष्य समस्या के संदर्भ में "समाधान" करना है, न कि समाधान के संदर्भ में।
2. सूची (eNumerate) कई संभावित समाधान। अपने पसंदीदा विकल्प पर तुरंत अपनी उंगली को इंगित करने की आवश्यकता नहीं है।
3. एक अलग समाधान पर विचार करें, और फिर प्रलेखन (पेपर) , यदि कोई हो, पढ़ें।
4. ऐतिहासिक संदर्भ को परिभाषित करें जिसमें यह समाधान बनाया गया था।
5. माचिस की तीली से लाभ अपने लक्ष्य को प्राप्त करने के लिए निर्णय लेने वालों को बलिदान करने के लिए क्या विश्लेषण करना पड़ा।
6. सोचो (सोचो) ! शांत और शांति से विचार करें कि यह समाधान आपकी आवश्यकताओं को पूरा करने के लिए कितना उपयुक्त है। अपने दिमाग को बदलने के लिए आपको वास्तव में क्या बदलने की आवश्यकता है? उदाहरण के लिए, कितना कम डेटा होना चाहिए, ताकि आप Hadoop का उपयोग न करना पसंद करें?

आप अमेज़न नहीं हैं

UNPHAT का उपयोग करना आसान है। एक कंपनी के साथ मेरी हाल की बातचीत को याद करें जिसने जल्दबाजी में कैसंड्रा को रात में डाउनलोड किए गए डेटा को पढ़ने की एक गहन प्रक्रिया के लिए उपयोग करने का फैसला किया।

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

अमेज़ॅन सब कुछ बहुत बेचता है। यदि फ़ंक्शन "टोकरी में जोड़ें" अचानक काम करना बंद कर देता है, तो वे बहुत सारे पैसे खो देंगे। क्या आपको भी उसी क्रम की समस्या है?

इस कंपनी ने कैसेंड्रा का उपयोग करने का निर्णय लिया क्योंकि पोस्टग्रेक्यूएल प्रश्न को पूरा करने में कई मिनट लग गए, और उन्होंने फैसला किया कि ये उनके हार्डवेयर के हिस्से पर तकनीकी सीमाएं थीं। कुछ बिंदुओं को स्पष्ट करने के बाद, हमने महसूस किया कि तालिका में 80 बाइट्स की लगभग 50 मिलियन पंक्तियाँ थीं। अगर आपको इसके बारे में पूरी तरह से जाना है तो इसे SSD से पढ़ने में लगभग 5 सेकंड का समय लगेगा। यह धीमा है, लेकिन यह उस समय क्वेरी निष्पादन की गति की तुलना में तेजी के दो क्रम है।

इस स्तर पर, मेरे पास कई सवाल थे (यू = समझें, समस्या को समझें!) और मैंने लगभग 5 अलग-अलग रणनीतियों का वजन करना शुरू किया जो मूल समस्या को हल कर सकते थे (एन = ई-न्यूमरेट, कुछ संभावित समाधानों की सूची!), लेकिन किसी भी मामले में। यह क्षण पहले से ही स्पष्ट था कि कैसंड्रा का उपयोग मौलिक रूप से गलत निर्णय था। वे सभी की जरूरत थी थोड़ा धैर्य स्थापित करने के लिए, शायद डेटाबेस के लिए एक नया डिजाइन और, संभवतः (हालांकि संभावना नहीं), एक अलग तकनीक का विकल्प ... लेकिन निश्चित रूप से गहन रिकॉर्डिंग के साथ कुंजी-मूल्य डेटा भंडारण नहीं है अमेज़ॅन ने अपनी टोकरी के लिए बनाया!

आप लिंक्डइन नहीं हैं

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

तुलना के लिए, याद रखें कि कफका लिंक्डइन पर सभी विश्लेषणात्मक घटनाओं को संभालने के लिए बनाया गया था। यह केवल डेटा की एक विशाल राशि है। कुछ साल पहले भी, यह प्रतिदिन लगभग 1 ट्रिलियन की घटना थी , जिसमें प्रति सेकंड 10 मिलियन संदेशों का शिखर भार था। बेशक, मैं समझता हूं कि काफ्का को कम भार के साथ काम करने के लिए इस्तेमाल किया जा सकता है, लेकिन 10 ऑर्डर कम?

सूर्य, एक बहुत ही विशाल वस्तु है, और यह पृथ्वी की तुलना में भारी मात्र 6 ऑर्डर है।

हो सकता है कि डेवलपर्स ने भी अपेक्षित जरूरतों और काफ्का के उद्देश्य की अच्छी समझ के आधार पर एक जानबूझकर निर्णय लिया। लेकिन मुझे लगता है कि वे बल्कि काफ्का के लिए (आमतौर पर उचित) सामुदायिक उत्साह से भर गए थे और लगभग कभी नहीं सोचा था कि क्या यह वास्तव में वे उपकरण थे जिनकी उन्हें जरूरत थी। जरा सोचिए ... 10 ऑर्डर!

क्या मैंने पहले ही कहा था? आप अमेज़न नहीं हैं

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

जब तक अमेज़ॅन ने SOA (सर्विस-ओरिएंटेड आर्किटेक्चर) पर स्विच करने का फैसला किया, उनके पास लगभग 7,800 कर्मचारी थे और उनकी बिक्री $ 3 बिलियन से अधिक थी ।

सैन फ्रांसिस्को में कॉन्सर्ट हॉल बिल ग्राहम ऑडिटोरियम में 7,000 लोग बैठते हैं। अमेज़ॅन के पास लगभग 7,800 कर्मचारी थे जब उन्होंने एसओए पर स्विच किया।

इसका मतलब यह नहीं है कि आपको एसओए में संक्रमण को स्थगित कर देना चाहिए जब तक कि आपकी कंपनी 7800 कर्मचारियों के स्तर तक नहीं पहुंच जाती ... बस हमेशा अपने सिर के साथ सोचें । क्या यह वास्तव में आपके कार्य का सबसे अच्छा समाधान है? आपके सामने वास्तव में क्या कार्य है और क्या इसे हल करने के लिए कोई अन्य तरीके हैं?

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

यहां तक ​​कि Google भी Google नहीं है।

अत्यधिक लोड डेटा धाराओं (Hadoop या Spark) के प्रसंस्करण के लिए सिस्टम का उपयोग करने के उदाहरण वास्तव में आश्चर्यजनक हो सकते हैं। बहुत बार, पारंपरिक DBMS लोड के लिए बेहतर होते हैं, और कभी-कभी डेटा की मात्रा इतनी कम होती है कि उपलब्ध मेमोरी भी उनके लिए पर्याप्त होगी। क्या आप जानते हैं कि आप $ 10,000 के लिए कहीं 1TB RAM खरीद सकते हैं? यदि आपके एक बिलियन उपयोगकर्ता हैं, तब भी आप उनमें से प्रत्येक को 1 KB RAM प्रदान कर सकेंगे।

शायद यह आपके लोड के लिए पर्याप्त नहीं होगा, क्योंकि आपको डिस्क पर पढ़ने और लिखने की आवश्यकता होगी। लेकिन क्या आपको वास्तव में पढ़ने और लिखने के लिए कई हज़ार डिस्क की आवश्यकता है? यहाँ वास्तव में आपके पास कितना डेटा है? GFS और MapReduce को इंटरनेट पर कंप्यूटिंग समस्याओं को हल करने के लिए बनाया गया था ... उदाहरण के लिए, पूरे इंटरनेट में खोज इंडेक्स को पुन: परिकलित करने के लिए।

हार्ड ड्राइव के लिए कीमतें अब 2003 की तुलना में बहुत कम हैं जब जीएफएस प्रलेखन प्रकाशित हुआ था।

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

हो सकता है कि आप पहले से स्केलेबिलिटी पर विचार करना चाहते हैं। क्या आपने पहले से ही सभी आवश्यक गणनाएं कर ली हैं? क्या आप SSD की कीमतों में गिरावट की तुलना में तेजी से डेटा जमा करेंगे? आपके व्यवसाय को कितनी बार बढ़ना होगा ताकि सभी उपलब्ध डेटा अब एक डिवाइस पर फिट न हों? 2016 तक, स्टैक एक्सचेंज केवल 4 एसक्यूएल सर्वरों के समर्थन के साथ प्रति दिन 200 मिलियन प्रश्नों का प्रसंस्करण कर रहा था: स्टैक ओवरफ्लो के लिए मुख्य एक, बाकी सब के लिए एक और दो प्रतियां।

फिर से, आप UNPHAT का सहारा ले सकते हैं और फिर भी Hadoop या Spark का उपयोग करने का निर्णय ले सकते हैं। और फैसला सही भी हो सकता है। मुख्य बात यह है कि आप वास्तव में अपनी समस्या को हल करने के लिए सही तकनीक का उपयोग करते हैं । वैसे, यह Google पर अच्छी तरह से जाना जाता है: जब उन्होंने फैसला किया कि MapReduce अनुक्रमण के लिए उपयुक्त नहीं था, तो उन्होंने इसका उपयोग करना बंद कर दिया।

पहले चीजें पहले, समस्या को समझें

मेरा संदेश कुछ नया नहीं हो सकता है, लेकिन यह इस रूप में हो सकता है कि यह आपको जवाब देगा या हो सकता है कि यूएनपीएटीएटी को याद रखना और इसे जीवन में लागू करना आपके लिए सरल होगा। यदि नहीं, तो आप Hammock Driven Development , या Paul की पुस्तक , How to Solve , या Hamming 's The Art of Doing Science and Engineering में रिच हिकी बात देख सकते हैं। क्योंकि मुख्य बात जो हम पूछते हैं वह सब सोचना है!

और वास्तव में उस समस्या को समझें जिसे आप हल करने की कोशिश कर रहे हैं। पॉल के प्रेरणादायक शब्दों में:

“ ऐसे सवाल का जवाब देना मूर्खता है जिसे आप नहीं समझते हैं। उस लक्ष्य के लिए प्रयास करना दुखद है जिसे आप प्राप्त नहीं करना चाहते। "

रूसी अनुवाद

अनुवाद: अलेक्जेंडर त्रेगूबोव
एलेक्सी इवानोव (@ponchiknews) द्वारा संपादित
समुदाय: @ponchiknews
चित्रा: LucidChart सामग्री टीम