हमने hh.ru पर खोज को कैसे तेज किया

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

Hh.ru पर खोज है:

• 400 प्रति सेकंड अनुरोध;
• रियलटाइम अपडेटेड इंडेक्स के 26 गीगाबाइट;
• 3x प्रतिकृति दर (असफलता अतिरेक);
• 5x प्रदर्शन मार्जिन।

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

यह ज्ञात है कि "माथे" को त्वरित नहीं किया जा सकता है जिसे अक्सर समानांतर किया जा सकता है। 3.1.0 संस्करण के बाद से ल्यूसीन में, खंडों की संख्या के अनुसार प्रत्येक अनुरोध को कई थ्रेड में विभाजित करना संभव था। लेकिन वहाँ था (और संस्करण 4.3 में) एक टिप्पणी "TODO: क्या हमें यह पिरोया जाना चाहिए ...?" कलेक्टर सिंक सिंक हो सकता है? हमेशा सिंगल थ्रेड का उपयोग करें ”।

और संग्राहक (एक तंत्र जो "एक-एक करके" प्राप्त करता है) एक खंड में पाए जाने वाले सभी दस्तावेजों का उपयोग हमारे देश में हर जगह किया जाता है: हमारा पहलू और सॉर्ट कोड उन पर आधारित है।

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

सामान्य योजना इस प्रकार दिखी:

• हम कई खंडों से परिणामों को इकट्ठा करने और संयोजित करने की क्षमता कलेक्टरों में जोड़ते हैं;
• समानांतर खंड ट्रैवर्सल को लागू / सक्षम करना;
• हम सूचकांक को एन बराबर-आकार के खंडों में विभाजित करते हैं;
• लाभ।

आइटम 1. संग्राहक

यह पता चला कि योजना के पहले बिंदु को एक ऐसे कार्य में प्रतिबिंबित करने के परिणामस्वरूप लागू किया गया था जिसका समानांतरकरण से कोई सीधा संबंध नहीं था। परिणामस्वरूप, हमें एक ऐसा तंत्र मिला, जिससे हम खोज परिणामों के पेड़ को कई स्तरों पर संयोजित कर सकते हैं, जैसा कि हम चाहते हैं (अब हमारे पास चार स्तर हैं: दस्तावेज़ों के प्रकार, अनुक्रमित, प्रतिकृतियां, खंड)।

बिंदु 2. खंडों का समानांतर आघात

मैं इस पर और विस्तार से ध्यान दूंगा।

निम्नलिखित IndexSearcher विधि हमारे लिए अत्यंत महत्वपूर्ण थी:

public void search(Weight weight, Filter filter, Collector collector) throws IOException { // TODO: should we make this // threaded...? the Collector could be sync'd? // always use single thread: for (int i = 0; i < subReaders.length; i++) { // search each subreader collector.setNextReader(subReaders[i], docBase + docStarts[i]); final Scorer scorer = (filter == null) ? weight.scorer(subReaders[i], !collector.acceptsDocsOutOfOrder(), true) : FilteredQuery.getFilteredScorer(subReaders[i], getSimilarity(), weight, weight, filter); if (scorer != null) { scorer.score(collector); } } } 

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

 public interface ParallelCollector { /** * creates per-segment collector */ Collector createPartialCollector(); } 

इस दृष्टिकोण के साथ, IndexSearcher का संशोधन सरल निकला:

• हम अपने "कलेक्टर" को स्थानांतरित करते हैं;
• सबरेडर्स पर लूप;
• हम चयनित कलेक्टर को प्राप्त करते हैं और आरंभ करते हैं:
  

    Collector collector = parallelCollector.createPartialCollector(); collector.setNextReader(subReader, subreaderDocBase); 

• पहले से ही रननेबल में हम मौजूदा पुराने कोड को निष्पादित करते हैं और इसे मौजूदा निष्पादक को सबमिट करते हैं;
• त्रुटियों को पकड़ना। हमारे मामले में, हम प्राप्त किए गए पहले अपवाद को पकड़ते हैं और वापस करते हैं।

  public void search(final Weight weight, final Filter filter, final ParallelCollector parallelCollector) throws IOException { final CountDownLatch latch = new CountDownLatch(subReaders.length); final AtomicReference<Throwable> exceptionReference = new AtomicReference<Throwable>(); for (int i = 0; i < subReaders.length; i++) { final int subreaderDocBase = docStarts[i]; final IndexReader subReader = subReaders[i]; executor.submit(new Runnable() { @Override public void run() { try { Collector collector = parallelCollector.createPartialCollector(); collector.setNextReader(subReader, subreaderDocBase); Scorer scorer = (filter == null) ? weight.scorer(subReader, !collector.acceptsDocsOutOfOrder(), true) : FilteredQuery.getFilteredScorer(subReader, getSimilarity(), weight, weight, filter); if (scorer != null) { scorer.score(collector); } } catch (Throwable t) { exceptionReference.compareAndSet(null, t); throw new RuntimeException(t); } finally { latch.countDown(); } } }); } try { latch.await(); } catch (InterruptedException e) { throw new RuntimeException(e); } Throwable possibleException = exceptionReference.get(); if (possibleException != null) { if (possibleException instanceof RuntimeException) { throw (RuntimeException) possibleException; } else if (possibleException instanceof IOException) { throw (IOException) possibleException; } else { throw new RuntimeException(possibleException); } } } 

मद 3. खंडों का टूटना

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

लेकिन डेवलपर्स महान हैं: उन्होंने अधिकतम सेगमेंट साइज को सीमित करने के लिए एक उपकरण दिया, जिसका हमने इस्तेमाल किया - सेटमैक्समर्ज़ एमबी + सेटमैक्समर्ज़ एमबीफ़ोरफॉरमेंस मैरेज ने एक धमाके के साथ समस्या को हल किया।

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

आप इससे समय-समय पर होने वाले मर्जडेलेट्स (पूर्व में एक्सपेन्डेडेलेट्स) और फोर्समार्ज (पूर्व में ऑप्टिमाइज़) से निपट सकते हैं, जो पुराने (संभवतः कई) से "लाइव" दस्तावेजों को एक नए सेगमेंट में कॉपी करते हैं। डिस्क I / O और मेमोरी खपत के मामले में यह ऑपरेशन काफी महंगा है।

छोटे खंड इस तथ्य के कारण लागत को काफी कम कर देते हैं कि दस्तावेजों को अद्यतन करने / हटाने के लिए आपको कम पड़ोसी दस्तावेजों को फिर से लिखना होगा।

परिणाम

इसलिए, लगभग एक महीने के विकास के लिए, हमें एक समानांतर खोज और कई छोटे खंड मिले। इसका क्या मूल्य है?

• तेज़ खोज। अब रिक्तियों के लिए 95% खोज प्रश्नों का परिणाम 10 मिलीसेकंड है, और रिज्यूमे के लिए - 70 मिलीसेकंड। तुलना के लिए, कुछ महीने पहले यह क्रमशः 30 और 270 था।
• ल्यूसीन में एक पैच पेश करने का अवसर (पहले से ही, लेकिन मैं "कोड को कंघी करना चाहता हूं")।
• एक अतिरिक्त सूचकांक अनुकूलन तंत्र से छुटकारा पाना।

स्पष्ट परिणाम

अंतराल - 2 सप्ताह।
लाल रेखा थी, नीली रेखा है, Y अक्ष प्रतिक्रिया समय है।

50 वीं मात्रात्मक, मध्यम कठिनाई खोज:


और 95 वीं मात्रात्मक, अधिकतम परिणामों के साथ खोज क्वेरी: