कदम दर कदम, या हमने अपनी खोज कैसे बनाई

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

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

ऐसे कार्य जो संसाधित किए गए डेटा, जैसे कि एंटीस्पैम या लिंक ग्राफ़, को और अधिक भ्रम पैदा करने के लिए अलग से काम करने के लिए मजबूर किया गया था। हम समझ गए कि कुछ बदलने की जरूरत है।

तैयार समाधान या खुद के कार्यान्वयन?

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

एक विकल्प के रूप में, हमने कई विकल्पों पर विचार किया। उनमें से एक सेक्टर / क्षेत्र प्रणाली थी। दुर्भाग्य से, हमारी कंपनी के अन्य विभागों में परीक्षणों से पता चला है कि उस समय प्रणाली काफी नम थी, और हम इस पर विश्वास के साथ भरोसा नहीं कर सकते थे।

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

Hadoop टेस्टिंग से पता चला कि जावा हमें डरा नहीं रहा है, और वितरित कंप्यूटिंग सिस्टम के डेवलपर्स के साथ व्यक्तिगत बातचीत के परिणामों के अनुसार, यह पता चला है कि Hadoop की गति स्व-निर्मित कार्यान्वयन से बहुत अलग नहीं है: कि एक अच्छी तरह से डिबग किया गया C ++ कार्यान्वयन Hadoop से केवल डेढ़ गुना तेज है। इससे यह स्पष्ट हो गया कि इसे अपना निर्णय लेने का कोई मतलब नहीं है - हम इसे लागू करने के लिए अधिक ऊर्जा खर्च करेंगे; इसलिए होडोप हमारे लिए आदी हो गए।

बेशक, प्रोग्रामर जिन्होंने साठ सर्वरों के एक कंप्यूटिंग क्लस्टर में प्रत्यारोपित किया, उन्होंने अनुभव किया। वह सब कुछ जो प्रोग्रामर लंबे समय तक करता था और दर्द से, जो कई हफ्तों तक सर्वर पर किया जाता था, अब एक दिन में प्रोग्राम किया गया था और 15-10 मिनट के लिए किया गया था। बेशक, जब लगभग सभी प्रोग्रामर Hadoop में चले गए, तो क्लस्टर के अंदर चलने वाले कार्य इतने तेज़ नहीं थे। फिर भी, एक सामान्य मंच होना बहुत सुविधाजनक था। यह स्पष्ट हो गया कि अंत में हम Hadoop का उपयोग करेंगे।

बिगटेबल क्लोन: एचबीएएस, हाइपरटेबल, कैसेंड्रा

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

नतीजतन, इस तरह से सोचकर, जल्दी या बाद में आप खुद को यह सोचकर पकड़ लेते हैं कि "यह बिगटेबल है", इसलिए हमने प्रसिद्ध ओपन सोर्स समकक्षों का पता लगाने का फैसला किया।

तीन स्वतंत्र रूप से वितरित किए जाने वाले बिगटेबल क्लोन थे: पहला था HBase, एक ही समुदाय के भीतर बनाया गया था, जिसे Hadoop ने बनाया था, दूसरा हाइपरटेबल था, और तीसरा ओपन सोर्स कैसंड्रा समाधान था, जिसे डायनमो से कॉपी किया गया था (जो बदले में अमेज़न पर आधारित था। बिगटेबल)।

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

दो विकल्प बचे थे - कैसंड्रा और एचबीएस। कैसेंड्रा ने अधिक गति प्रदान की, लेकिन डेटा हानि का एक उच्च जोखिम भी दिया। HBase, इसके विपरीत, लिखने की गति कम थी, लेकिन उच्च विश्वसनीयता। इसके अलावा, HBase Hadoop के साथ घनिष्ठता से जुड़ा हुआ है। यह हमारे लिए उसके पक्ष में एक निर्णायक तर्क बन गया।

हमने 16 मशीनों के एक छोटे समूह के साथ HBase का परीक्षण शुरू किया। पहले परीक्षण सफल रहे - सब कुछ पूरी तरह से और एक स्वीकार्य गति से काम किया। जल्द ही क्लस्टर में सर्वरों की संख्या बढ़कर 32 हो गई और फिर 50 हो गई।

तब हमने फैसला किया कि हम तुरंत एक पूर्ण खोज इंजन का निर्माण नहीं करेंगे जो मुख्य के बगल में काम करेगा। जब "भारी" वेब सेवा के दो संस्करण - जल्दी और देर से - समानांतर में विकसित किए जा रहे हैं, तो दूसरा, एक नियम के रूप में, पहले के साथ पकड़ने में विफल रहता है। पहले संस्करण में, नई सुविधाएँ लगातार दिखाई देती हैं, जो दूसरे में बस लागू करने का समय नहीं होता है; परिणामस्वरूप, खोज के एक नए संस्करण के रिलीज़ न होने का जोखिम होगा।

इसलिए, हमने छोटे से शुरू करने का फैसला किया: एक ऐसा कार्य करें जो हमारे मुख्य खोज इंजन में जानबूझकर हल नहीं किया गया है, और इसे नई प्रौद्योगिकियों की मदद से हल करें और नई वास्तुकला पर ध्यान केंद्रित करें। इस तरह के कार्य के रूप में, हमने हमारे हित के दस्तावेजों का एक त्वरित और नियमित क्रॉल चुना। वास्तव में, लगभग 3 महीनों में हमने मौजूदा मकड़ी के बगल में इसका विशेष संस्करण लॉन्च किया, लेकिन तुरंत समग्र खोज इंजन कार्य चक्र में शामिल किया गया। इसे स्थिर करने, इसे ठीक करने और HBase के लिए पैच बनाने के लिए एक और 3 महीने लग गए, जिसके बाद हमने पुरानी मकड़ी को बंद कर दिया और पूरी तरह से नई प्रणाली में बदल दिया।

प्रारंभिक अनुमानों के अनुसार, पूरी प्रक्रिया में लगभग डेढ़ से दो महीने लगने चाहिए थे। हालाँकि, हमने शर्तों को कम करके आंका - यह पता चला कि HBase उन कामों में अपने काम की स्थिरता और अपने काम की स्थिरता से बहुत दूर था, जिनके लिए हमने इसका इस्तेमाल किया था। हमने अपने स्वयं के समाधान को विकसित करने के लिए कई बार कोशिश की, लेकिन हर बार जब हमने स्थिति का विश्लेषण किया और इस नतीजे पर पहुँचे कि अभी भी हमारी ज़रूरतों के लिए HBase को दर्जी बनाना आसान होगा।

हमारा समर्थन अनुभव

Hadoop और HBase के "taming" की प्रक्रिया में, हमें एहसास हुआ कि हमें और अधिक अनुभवी लोगों की मदद की आवश्यकता है - यही कारण है कि हमने क्लोदेरा से व्यावसायिक समर्थन प्राप्त किया।

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

समस्याएं और हमने उन्हें कैसे हल किया

सभी समस्याएं जो हमें HBase और Hadoop के साथ थीं, उन्हें Maxim Lapan द्वारा की गई एक रिपोर्ट में Mail.Ru Group Technology Forum में विस्तार से वर्णित किया गया था (यहाँ देखें: http://techforum.mail.ru/video/ )। मैं उन्हें संक्षेप में रेखांकित करूंगा।

पहला: हमारी तालिका का आयतन लगातार बढ़ रहा है। शुरुआत में, हमें उम्मीद थी कि तालिका 5-10 बिलियन दस्तावेज होगी। हालांकि, यह जल्दी से स्पष्ट हो गया कि यह संख्या बहुत बड़ी होनी चाहिए, और 20-40 बिलियन URL को डेटाबेस में रखा जाना चाहिए। इसका मतलब यह था कि हम क्लस्टर की मात्रा का अनुमान लगाने में गलत थे: परिणामस्वरूप, हमें इसे पहले 100 तक और फिर 170 सर्वरों तक विस्तारित करना पड़ा। नतीजतन, हम सबसे बड़े समूहों में से एक के मालिक बन गए, जिस पर HBase तैनात है; किसी भी मामले में, रूस में बड़े क्लस्टर हमारे लिए अज्ञात हैं।

HBase के उपयोग के साथ एक दूसरी समस्या उत्पन्न हुई। हर दिन हमने लगभग 500 मिलियन, या यहां तक ​​कि एक अरब दस्तावेज भी पंप किए। उस समय, हमारे पास सामग्री के साथ 5-10 बिलियन दस्तावेज थे; इस प्रकार, बेस वॉल्यूम का लगभग 10-20% दैनिक अद्यतन किया गया था। ऑपरेशन के इस मोड के साथ, बॉक्स से बाहर स्थापित HBase, हमेशा इस डेटाबेस को वापस करने की कोशिश में व्यस्त रहता है, जो नेटवर्क और डिस्क संसाधनों का उपभोग करता है। नतीजतन, कार्यों को बहुत धीरे-धीरे निष्पादित किया जाता है। HBase सेट करके इस समस्या को हल करना संभव नहीं था, इसलिए हमें इसे पैच करना पड़ा। नतीजतन, हमने अलग-अलग जटिलता के कई पैच पोस्ट किए, जिससे HBase के साथ आधिकारिक संचालन के लिए समय कम करने में मदद मिली।

तीसरी समस्या यह थी कि एक बड़े डेटाबेस पर कार्यों का दैनिक पास बहुत धीमा था, क्योंकि डेटा को स्कैन करते समय एक लापरवाह फिल्टर ने इस तथ्य को जन्म दिया कि तालिका से सभी मान उठाए गए थे, जिसमें वहां संग्रहीत सामग्री भी शामिल थी; यह इस तथ्य के कारण था कि योजनाबद्ध 2-3 घंटों के बजाय कार्य दिनों के लिए किया गया था। यह देखते हुए कि हमारा क्लस्टर अक्सर उस समय दुर्घटनाग्रस्त हो जाता है, कार्य आसानी से पूरा नहीं हो पाता। समाधान को पैच के रूप में भी लागू किया गया था, जो "त्वरित स्कैन" के कारण तालिका के माध्यम से मार्ग को गति देने की अनुमति देता है। हमने इसे ट्रैक ट्रैकर अपाचे https://issues.apache.org/jira/browse/HBASE-5416 में चर्चा के लिए पोस्ट किया, जहां अधिकांश सक्रिय HBase डेवलपर्स इकट्ठा हुए, लेकिन चूंकि पैच कई HBase रूट तत्वों को प्रभावित करता है, इसलिए यह नहीं किया गया है आम कोड में एकीकृत। यह पैच सबसे बड़ा हो गया, और यह अपने विकास के अंत के साथ था कि हमारे क्लस्टर ने आखिरकार काम करना शुरू कर दिया।

चौथी बड़ी समस्या जिसे हमने अभी तक दूर नहीं किया है वह है HBase क्षेत्रों में असंतुलन।

यहां यह HBase में वेब पेजों को संग्रहीत करने के दृष्टिकोण पर अधिक विस्तार से विचार करने योग्य है। HBase का उपयोग करने का एक उत्कृष्ट उदाहरण एक कुंजी के रूप में URL के साथ दस्तावेज़ सामग्री को संग्रहीत करना है। URL में डोमेन उल्टे क्रम में लिखे गए हैं, ताकि न केवल साइट के पृष्ठ, बल्कि एक डोमेन के उप-डोमेन पास में स्थित हों, उदाहरण के लिए इस तरह:



यह दृष्टिकोण उसके तर्क से बहका, और हमने वही किया। समस्या यह है कि URL का सेट समय के साथ विस्तारित होता है, और यह संभावना है कि हम एक ही डोमेन से कई पृष्ठ पाएंगे। HBase में संबंधित क्षेत्र औसत से अधिक "मोटा" होगा।

इस समस्या को दूर करने के लिए, HBase में एक क्षेत्रीय विभाजन तंत्र है। लेकिन उल्टा तंत्र - विलय - अस्थिर है। संतुलन बनाए रखने के लिए क्षेत्रों की संख्या में निरंतर वृद्धि से उनके रखरखाव के लिए बड़ी ओवरहेड लागत होती है।

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

जब हम समाधान पर काम कर रहे थे, तो हमारे खोज घटकों के अधिक से अधिक Hadoop में चले गए। अब Hadoop और HBase में अनुक्रमण को छोड़कर सभी घटक काम करते हैं।
शायद, अंत में हमने वही किया जो हम शुरू से चाहते थे: हमारे पास वितरित कंप्यूटिंग, डेटा विश्लेषण के लिए एक मंच है। यह कहने के लिए नहीं है कि हम इससे पूरी तरह से संतुष्ट हैं - केवल इसलिए कि रास्ते से गुजरने की प्रक्रिया में, मंच से मुझे और क्या प्राप्त करना है, इसकी समझ आती है। लेकिन अब उस समय से जब तक एक नया URL इंडेक्स में दिखाई देता है, तब तक 2 से 5 दिन लगते हैं। खोज इंजन के पुराने संस्करण में, यह दो सप्ताह या अधिक से हो सकता है। हमारा अगला लक्ष्य समय को मिनटों तक कम करना है। खोज इंजन के नए संस्करण की वास्तुकला मौजूदा एक से मौलिक रूप से अलग होने की संभावना है।

MapReduce और स्पाइडर

MapReduce प्रतिमान और डीबग किए गए Hadoop तकनीक से क्लस्टर को स्केल करना आसान हो जाता है। हम सर्वरों की संख्या 1.5 गुना बढ़ाते हैं - कार्य शुरू होने लगते हैं [लगभग] 1.5 गुना तेज। हालांकि, MapReduce के प्रतिमान पर सभी कार्य "गिर" नहीं हैं, और कुछ बस इससे किसी भी सुधार का अनुभव नहीं करते हैं। यह सच है, उदाहरण के लिए, एक वेब स्पाइडर के लिए: किसी साइट को पंप करने के लिए स्लॉट पर कब्जा करना लाभदायक नहीं है - हमेशा धीमी गति से होस्टिंग होगी, क्योंकि कीमती स्लॉट को आवश्यक से अधिक समय तक आयोजित करना होगा।

इसके अलावा, "MapReduce के भीतर सब कुछ करते हैं" दृष्टिकोण संसाधनों के अक्षम उपयोग की ओर जाता है, क्योंकि पृष्ठों को पंप करने के लिए एक तेज़ नेटवर्क की आवश्यकता होती है, और कहते हैं, पृष्ठ सामग्री को पार्स करने के लिए एक तेज़ सीपीयू की आवश्यकता होती है।

यह ठीक-ठीक हमारे क्रॉलर में हुए अलगाव की प्रक्रिया है। इससे पहले कि यह एक अखंड कार्य था जो उत्पादित किया गया था:

• DNS- रिज़ॉल्यूशन + पेजिंग (नेटवर्क की आवश्यकता है)
• सामग्री पार्सिंग (CPU)
• लिंक की जाँच और आयात (CPU + RAM का एक बहुत)
• सामग्री भंडारण और बैकअप (डिस्क)
• पम्पिंग कतार (CPU + RAM के बहुत सारे) का पुनर्निर्माण करें

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

Hadoop में जाने से हमें बैकअप स्टोरेज की समस्या से बचा लिया गया और हमें CPU और RAM की आवश्यकता वाले कार्यों के लिए आसान मापनीयता मिली। क्रॉलर ने केवल पंपिंग फ़ंक्शन करना शुरू किया और उसका नाम बदलकर भ्रूण कर दिया गया:



अब जब हमारे पास MapReduce में सभी "व्यावसायिक तर्क" हैं, और दस्तावेज स्वयं HBase में हैं, तो भाषा की एक नई परिभाषा का परिचय एक दिन का कार्य बन गया है।

हमने एकल Hadoop कंप्यूटिंग प्लेटफॉर्म के लिए संक्रमण की जांच की। हमारी परियोजना के लिए Hadoop की शुरूआत शायद सबसे क्रांतिकारी वास्तुशिल्प समाधान था। ऑफ़लाइन गणना करने वाले घटकों के लिए Hadoop और MapReduce का संक्रमण जारी है। "ऑनलाइन" भाग की वास्तुकला जो उपयोगकर्ता प्रश्नों को संसाधित करती है, साथ ही साथ खोज सूचकांक बनाने की प्रक्रिया भी बाद में चर्चा की जाएगी।

डेटा अनुक्रमण

डेटा अनुक्रमण MapReduce के बाहर होता है, लेकिन इसे व्यक्तिगत मशीनों के बीच भी वितरित किया जाता है और यह बड़े पैमाने पर आसान होता है।

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

एक सामान्य अनुक्रमणिका मशीन कुछ इस तरह दिखती है:



इंडेक्सर्स के लिए अड़चनें सीपीयू और डिस्क हैं, यही कारण है कि इंडेक्स को कोर की संख्या से डिस्क से लैस किया जाता है; प्रसंस्करण कतारों की संख्या समान है।

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

इस तथ्य के बावजूद कि इंडेक्सर्स स्वयं MapReduce प्रतिमान के बाहर काम करते हैं, Hadoop इस कार्य में भी मदद करता है: माइक्रोबेस का केंद्रीय भंडारण और मुख्य बैकअप HDFS है। इसके अलावा, इंडेक्सर्स के भारी हिस्सों का भी Hadoop में अनुवाद किया जाता है, ताकि इंडेक्सर्स अपने प्रत्यक्ष कार्य के साथ अधिक चिंतित हों - एक बाइनरी डेटा इंडेक्स का संकलन।

खोज डेमॉन

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

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

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

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

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

-, master-workers. (mdb), , :



, , , .

, « ». , , . , , – .

, ():



.. — . , : , web.

, , . , 3- ? search-manager : – . , — . “middle-end”- :



smanager-meta smanager-. , 20 .

« » . « » 15 , « web-» — .

smanager-meta : , . .

अंतभाषण

Mail.Ru , , GoGo, 10 . . – .

. , . . , Apache HBase. . , , , .

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

एंड्री कालिनिन, सर्च प्रोजेक्ट मैनेजर
जन किसेल, सर्च इन्फ्रास्ट्रक्चर टीम लीडर