ElasticSearch 1.0 - नई विश्लेषिकी विशेषताएं

कई लोगों ने उच्च-स्तरीय खोज सर्वर ElasticSearch के बारे में सुना है, लेकिन हर कोई नहीं जानता कि कई लोग इसका उपयोग अपने इच्छित उद्देश्य के लिए करते हैं। हम विभिन्न संरचितों के वास्तविक समय के एनालिटिक्स के बारे में बात कर रहे हैं और ऐसा नहीं है।

यह लेख इस तथ्य के कारण भी परिपक्व हो गया है कि 2014 में रनेट में कई बड़ी इंटरनेट परियोजनाओं को अपने उत्पाद का उपयोग करने के अवसर के लिए $ 150,000 का भुगतान करने की पेशकश के साथ Google विश्लेषिकी से खुशी के पत्र मिले। मुझे व्यक्तिगत रूप से लगता है कि प्रोग्रामर और एडमिनिस्ट्रेटर के काम के लिए भुगतान करने में कुछ भी गलत नहीं है। लेकिन एक ही समय में, यह एक बल्कि गंभीर निवेश है, और, शायद, हमारे अपने बुनियादी ढांचे और विशेषज्ञों में निवेश भविष्य में अधिक लचीलापन देगा।

ElasticSearch विश्लेषिकी पूर्ण-पाठ खोज और पहलुओं पर आधारित है। खोज में पहलू एक निश्चित विशेषता के आधार पर एकत्रीकरण का एक प्रकार है। आप अक्सर ऑनलाइन स्टोर में फ़िल्टर पहलुओं के पार आते हैं: बाएं या दाएं कॉलम में स्पष्ट चेकमार्क होते हैं। नीचे हमारे मुख्य पृष्ठ http://indexisto.com/ पर एक पहलू परीक्षण खोज का एक उदाहरण है।



एक सप्ताह पहले, इलास्टिकसर्च 1.0 खोज इंजन का एक स्थिर संस्करण जारी किया गया था, जिसमें डेवलपर्स ने पहलुओं पर इतनी गंभीरता से काम किया कि उन्होंने उन्हें एग्रीगेशन भी कहा।

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

सबसे पहले, मैं Google रुझानों से आंकड़े प्रदान करना चाहूंगा, जो स्पष्ट रूप से दिखाता है कि ElasticSearch में कितनी रुचि है:


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

वितरित कंप्यूटिंग

क्वेरी को समानांतर में क्लस्टर पर निष्पादित किया जाता है, उन शार्क पर जिसमें ब्याज का सूचकांक निहित है। Shards अनिवार्य रूप से अच्छे पुराने Lucene Index होते हैं। ElasticSearch जो कुछ भी करता है वह अनुरोध को स्वीकार करता है, नोड्स का निर्धारण करता है जहां सूचकांक के हिस्से जिस पर अनुरोध आया था, इन शार्क को अनुरोध भेजें, शार्क गणना करते हैं और परिणाम को आरंभ करने वाले नोड को भेजते हैं। दीक्षा नोड पहले से ही ग्राहक को समझाता है और भेजता है। डेटा प्रवाह के संदर्भ में, यह मैप कम करने के समान है, जब ल्यूसीन इंडेक्स मैपर होते हैं और आरंभ करने वाला नोड reducer होता है।

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

आइए एक नया अनुरोध करते हैं, "वर्षों से लॉग में कितनी त्रुटियां थीं"। यह क्वेरी लॉग दस्तावेजों में ईआरओआरओआर के लिए खोज करती है, और वर्ष तक पहलू बनाती है।
यह डेटा स्ट्रीम कैसे दिखती है:



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

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

ल्यूसिने पर थोड़ी मदद। एक पाठ प्रतिनिधित्व में "संख्या" पर श्रेणी प्रश्न बहुत कुशल हैं NumericRangeQuery :

Comparisons of the different types of RangeQueries on an index with about 500,000 docs showed that TermRangeQuery in boolean rewrite mode (with raised BooleanQuery clause count) took about 30-40 secs to complete, TermRangeQuery in constant score filter rewrite mode took 5 secs and executing this class took <100ms to complete 

अभ्यास के लिए आगे बढ़ते हैं। डेटा तैयार करें

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

 { "user": "andrey", "title": "Android  1", "body": "Android  1", "postDate": "2011-02-15T11:12:12", "tags": [""], "rank": 67, "comments": 21 } 

मैंने Android के बारे में 10 पोस्ट और iPhone के बारे में 10 पोस्ट बनाए।
पोस्ट में एक सेट से एक या अधिक टैग हो सकते हैं।

• विस्फोट
• अद्यतन
• एप्लिकेशन
• बग

2011 से 2014 तक के वर्षों के पद। रेटिंग 0 से 100 तक । टिप्पणियों की संख्या समान है।

इस परिणाम के रूप में हमारे पास सूचकांक में है:

पुराने स्कूल विश्लेषण (संस्करण 1.0 ईएस तक)

Android पोस्ट में टैग वितरण
तुरंत अभ्यास में, हम दिखाएंगे कि पूर्ण-पाठ खोज और पहलुओं को मिलाकर क्या विश्लेषण किया जा सकता है। हम शीर्षक फ़ील्ड के लिए एक Android खोज क्वेरी और टैग फ़ील्ड के लिए एक मुखर क्वेरी करते हैं:

 { "query": { "wildcard": { "title": "Android*" } }, "facets": { "tags": { "terms": { "field": "tags" } } } } 

जवाब में, हमें मिलता है:

 "facets": { "tags": { "_type": "terms", "missing": 0, "total": 18, "other": 0, "terms": [ { "term": "", "count": 5 }, { "term": "", "count": 5 }, { "term": "", "count": 4 }, { "term": "", "count": 4 } ] } } 

ठीक है, तुलना के लिए, एक ही बात है, लेकिन अगर हम iPhone के बारे में पोस्ट देख रहे हैं:

 "facets": { "tags": { "_type": "terms", "missing": 0, "total": 16, "other": 0, "terms": [ { "term": "", "count": 5 }, { "term": "", "count": 5 }, { "term": "", "count": 4 }, { "term": "", "count": 2 } ] } } 

जैसा कि आप विश्लेषिकी से देख सकते हैं, iPhones अक्सर विस्फोट करते हैं, और एंड्रॉइड अपडेट किए जाते हैं।

साल तक iPhone पोस्ट के बार चार्ट
एक और उदाहरण जहां हम देखते हैं कि समय के साथ iPhones में रुचि कैसे बदल गई है। IPhone क्वेरी, पोस्टडेट फ़ील्ड द्वारा पहलू:

 { "query": { "wildcard": { "title": "iPhone" } }, "facets": { "articles_over_time": { "date_histogram": { "field": "postDate", "interval": "year" } } } } 

उत्तर है:

 "facets": { "articles_over_time": { "_type": "date_histogram", "entries": [ { "time": 1293840000000, "count": 2 }, { "time": 1325376000000, "count": 4 }, { "time": 1356998400000, "count": 2 }, { "time": 1388534400000, "count": 2 } ] } } 

जैसा कि आप देख सकते हैं, ब्याज की वृद्धि 2012 में हुई (टाइमस्टैम्प के जवाब में)।

यह बहुत स्पष्ट है कि यह कैसे काम करता है। ElasticSearch में बुनियादी पहलू प्रकार

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

पहलुओं और पूर्ण-पाठ प्रश्नों को मिलाकर, आप कई अलग-अलग चयन प्राप्त कर सकते हैं।

ES 1.0 में एनालिटिक्स - नया स्कूल!

जैसा कि आपने देखा, संस्करण 1.0 से पहले ईएस में पहलुओं ने बस दस्तावेजों की संख्या वापस कर दी। अनुरोध बहुत सपाट थे (कोई घोंसला नहीं)। लेकिन क्या होगा अगर हम वर्षों से iPhone पोस्ट प्राप्त करना चाहते हैं, और फिर इन पदों की औसत रेटिंग की गणना करें?
ES 1.0 में, यह एकत्रीकरण ढांचे के लिए संभव बनाया गया है।

दो प्रकार के एकत्रीकरण हैं:
बकेट - जो पाए गए दस्तावेजों की संख्या की गणना करता है, और "टोकरी" में पाए गए दस्तावेजों की आईडी भी जोड़ता है। उदाहरण के लिए, शब्द, श्रेणी, हिस्टोग्राम जैसे उपरोक्त मुखर प्रश्न बकेट एग्रीगेट हैं। अब वे न केवल दस्तावेजों की संख्या की गिनती करते हैं, उदाहरण के लिए, टैग क्षेत्र में शर्तों से, बल्कि इन दस्तावेजों की आईडी भी सूचीबद्ध करें: टैग "बग" के साथ 7 दस्तावेज, इन दस्तावेजों की आईडी 2,5,6,10,17,19,20
Calc - जो केवल एक संख्या गिनता है। उदाहरण के लिए, एक संख्यात्मक क्षेत्र, मिनिमा, मैक्सिमा और रकम का औसत मूल्य।

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

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

• शीर्षक में iPhone वाले पोस्ट के चयन को सीमित करें
• साल के हिसाब से हिस्टोग्राम-बकेट-फैक्ट्स बनाएं
• प्राप्त "बास्केट" पर हम टैग्स द्वारा टर्म-बकेट-फेसलेट बनाते हैं।
• प्राप्त "बास्केट" (टैग के साथ) के अनुसार हम रेटिंग द्वारा औसत एकत्रीकरण करते हैं
• चूंकि हमें केवल सबसे उबाऊ टैग की आवश्यकता है, हम उन्हें नेस्टेड एग्रीगेशन (औसत रेटिंग) में प्राप्त मूल्य से सॉर्ट करते हैं।

 { "query": { "wildcard": { "title": "iphone" } }, "aggs": { "post_over_time_agg": { "date_histogram": { "field": "postDate", "interval": "year" }, "aggs": { "tags_agg": { "terms": { "field": "tags", "size": 1, "order": { "avg_rating_agg": "asc" } }, "aggs": { "avg_rating_agg": { "avg": { "field": "rank" } } } } } } } } 

उत्तर है:

 "aggregations": { "post_over_time_agg": { "buckets": [ { "key": 1293840000000, "doc_count": 2, "tags_agg": { "buckets": [ { "key": "", "doc_count": 1, "avg_rating_agg": { "value": 14.0 } } ] } }, { "key": 1325376000000, "doc_count": 4, "tags_agg": { "buckets": [ { "key": "", "doc_count": 1, "avg_rating_agg": { "value": 34.0 } } ] } }, { "key": 1356998400000, "doc_count": 2, "tags_agg": { "buckets": [ { "key": "", "doc_count": 2, "avg_rating_agg": { "value": 41.0 } } ] } }, { "key": 1388534400000, "doc_count": 2, "tags_agg": { "buckets": [ { "key": "", "doc_count": 1, "avg_rating_agg": { "value": 23.0 } } ] } } ] } } 

जैसा कि आप देख सकते हैं, 2011 और 2012 में लोगों को iPhones के विस्फोटों के बारे में पोस्ट मिला, 2013 में नए अनुप्रयोगों के बारे में, और 2014 में बग के बारे में।

वास्तविक कार्यों के लिए

एक ऑनलाइन स्टोर का मानक कार्य विज्ञापन अभियान की प्रभावशीलता की गणना करना या उपयोगकर्ताओं के समूह के व्यवहार का विश्लेषण करना है। कल्पना करें कि आप अपने http सर्वर के सभी लॉग को ElasticSearch में धकेलते हैं, जबकि आपके द्वारा संग्रहित दस्तावेज़ में अपना थोड़ा अधिक डेटा जोड़ते हैं, उदाहरण के लिए, Bitrix में।

 { "url": "http://myshop.com/purchase/confirmed", "date": "2014-02-15T11:12:12", "agent": "Chrome/32.0.1667.0", "geo": "", "utm_source": "super_banner", "userRegisterDate": "2011-02-15T11:12:12", "orderPrice": 4000, "orderCategory": [" ",""] } 

इस मामले में, दस्तावेज़ योजना निर्धारित नहीं है। इस पृष्ठ पर एक आदेश है - जोड़ा गया आदेशप्रासिस , नहीं - जोड़ा नहीं गया है।
केवल इस तरह के लॉग के साथ, आप पहले से ही बहुत कुछ कर सकते हैं जो Google एनालाटिक्स कर सकता है।

उदाहरण 1: कोहोर्ट विश्लेषण करने के लिए, उदाहरण के लिए, उपयोगकर्ताओं को पंजीकरण की तारीख से विभाजित करने और यह देखने के लिए कि पंजीकरण की तारीख से 2 महीने के भीतर उनके द्वारा कितने ऑर्डर रखे गए थे, औसत ऑर्डर राशि की गणना करने के लिए। यहाँ लोचदार खोज के लिए एक तार्किक अनुरोध कैसा दिखता है:

• शब्द "खरीद / पुष्टि" के url के लिए एक पाठ अनुरोध करें
• उपयोगकर्ता पंजीकरण दिनांक से date_histogram पहलुओं को बनाएं
• श्रेणी "उपयोगकर्ता पंजीकरण तिथि" के प्रारंभिक मूल्य के साथ एक date_range पहलू बनाएं (आप अनुरोध में इसका उल्लेख कर सकते हैं) और अंतिम + 2 महीने
• क्षेत्र और ऑर्डर पर औसत प्राप्त करें प्राप्त बाल्टी में भुगतान करें

उदाहरण 2: आज तक चैनलों पर अपने लक्ष्य और रूपांतरण ट्रैक करें। उदाहरण के लिए, लक्ष्य url / खरीद / पुष्टि पर जाना है
प्रश्न:

• शब्द "खरीद / पुष्टि" के url के लिए एक पाठ अनुरोध करें
• 1 दिन के ब्रेकडाउन के साथ url पर जाने की तारीख के अनुसार डेट_हिस्टोग्राम पहलू बनाएं
• utm_source द्वारा शब्द का पहलू बनाएं
• गिनती-एकत्रीकरण करें

निष्कर्ष

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

मैं यह भी जोड़ता हूं कि प्रवेश सीमा बहुत कम है। 5 मिनट में स्थापना, फिर आप कम से कम कर्ल के साथ खेल सकते हैं, यहां तक ​​कि एक प्लग-इन क्रोम के साथ जो http अनुरोधों को उत्पन्न कर सकता है। हमारे पास http://indexisto.com/ है, अब 7 मशीनों का एक क्लस्टर आश्चर्यजनक रूप से स्थिर है।

सभी एकत्रीकरण की विशेषताएं यहां वर्णित हैं https://github.com/elasticsearch/elasticsearch/issues/3300