Изследователски документ за избор на търсачки
Въведение в Elasticsearch*
Elasticsearch е разпределен търсач и аналитичен двигател в реално време. Това ви помага да обработвате мащабни данни по-бързо от всякога.
Може да се използва за пълнотекстово търсене, структурирано търсене и анализи, а разбира се, можете да комбинирате и трите.
Elasticsearch е търсачка, изградена на базата на пълнотекстовата търсачка Apache Lucene™, която може да се счита за най-напредналата и ефективна пълнофункционална отворена търсачка, достъпна днес.
Но Lucene е просто фреймуърк и за да се възползваш напълно от нейните възможности, трябва да използваш JAVA и да интегрираш Lucene в програмата си. Трябва много учене, за да разбереш как работи, а Lucene е наистина сложна.
Elasticsearch използва Lucene като вътрешен двигател, но при използване на пълен текст е необходим само унифициран API, без да разбирате сложните принципи на Lucene зад него.
Разбира се, Elasticsearch не е просто толкова прост като Lucene, той не само включва функции за пълнотекстово търсене, но може да изпълнява и следните задачи:
- Разпределено съхранение на файлове в реално време и индексиране на всяко поле, за да може да бъде търсено.
- Разпределена търсачка с аналитика в реално време.
- Може да се мащабира до стотици сървъри, за да обработва петабайти структурирани или неструктурирани данни.
С толкова много функции, интегрирани в един сървър, лесно можете да комуникирате с RESTful API на ES чрез клиента или някой от предпочитаните от вас програмни езици.
Започването с Elasticsearch е много лесно. Идва с много разумни стандарти, което го прави добър начин за начинаещи да избегнат работа със сложни теории веднага щом започнат.
Той е инсталиран и готов за употреба, и може да бъде много продуктивен с малки разходи за обучение.
Колкото повече научаваш, толкова повече можеш да се възползваш и от по-напреднали функции на Elasticsearch, а целият енджин може да се конфигурира гъвкаво. Можете да персонализирате собствения си Elasticsearch според собствените си нужди.
Случаи на употреба:
- Уикипедия използва Elasticsearch, за да прави търсения в пълен текст и да маркира ключови думи, както и за предложения за търсене като търсене като "търси как-написваш" и "дали си имал предвид".
- The Guardian използва Elasticsearch, за да обработва дневниците на посетителите, така че редакторите да бъдат информирани за обществените реакции към различни статии в реално време.
- StackOverflow комбинира пълнотекстово търсене с геолокация и релевантна информация, за да предостави представяне на въпроси, свързани с по-подобни на това.
- GitHub използва Elasticsearch, за да извлича над 130 милиарда реда код.
- Всеки ден Goldman Sachs го използва, за да индексира 5TB данни, а много инвестиционни банки го използват за анализ на движенията на фондовия пазар.
Но Elasticsearch не е само за големи предприятия, той също така е помогнал на много стартиращи компании като DataDog и Klout да разширят възможностите си.
Плюсове и минуси на Elasticsearch**:
заслуга
- Elasticsearch е разпределен. Не са необходими други компоненти, а разпределението е в реално време, известно като "Push replication".
- Elasticsearch напълно поддържа търсене в почти реално време с Apache Lucene.
- Обработката на мултитенантност не изисква специална конфигурация, докато Solr изисква по-напреднали настройки.
- Elasticsearch използва концепцията Gateway, за да улесни архивирането.
- Всеки възел образува равна мрежова структура, а когато някои възли се провалят, други възли автоматично се назначават да работят на тяхно място.
Недостатък
- Само един разработчик (настоящата организация Elasticsearch GitHub е повече от това, вече има доста активни поддържащи)
- Не е достатъчно автоматично (не е подходящо за настоящия нов Index Warmup API)
За Солр*
Solr (произнася се "солар") е отворена корпоративна търсачка платформа за проекта Apache Lucene. Основните му функции включват търсене в пълен текст, маркиране на удари, фасетно търсене, динамично клъстериране, интеграция с база данни и обработка на богат текст (например Word, PDF). Solr е силно мащабируем и осигурява разпределено търсене и репликация на индекси. Solr е най-популярната търсачка от корпоративен клас, а Solr4 добавя и поддръжка на NoSQL.
Solr е самостоятелен пълнотекстов сървър за търсене, написан на Java, който работи върху servlet контейнер като Apache Tomcat или Jetty. Solr използва Lucene Java търсещата библиотека като ядро за пълнотекстово индексиране и търсене и разполага с REST-подобни HTTP/XML и JSON API-та. Мощните външни конфигурационни възможности на Solr улесняват адаптацията към много типове приложения без Java кодиране. Solr има архитектура на плъгини, която поддържа по-усъвършенствана персонализация.
Поради сливането на проектите Apache Lucene и Apache Solr през 2010 г., двата проекта бяха създадени и реализирани от един и същ екип на Apache Software Foundation. Що се отнася до технологиите или продуктите, Lucene/Solr или Solr/Lucene са същите.
Плюсове и минуси на Solr:
заслуга
- Solr има по-голяма и по-зряла общност от потребители, разработчици и сътрудници.
- Поддържа добавяне на индекси в различни формати, като HTML, PDF, софтуерни формати на Microsoft Office и формати за обикновен текст като JSON, XML, CSV и др.
- Солр е сравнително зрял и стабилен.
- Търсенето по време на индексиране не се взема предвид, а скоростта е по-бърза.
Недостатък
- Когато индексът е установен, ефективността на търсене намалява, а ефективността на търсене в реално време не е висока.
Elasticsearch срещу Solr*
Solr е по-бърз просто при търсене на съществуващи данни.
При индексиране в реално време, Solr причинява блокиране на входа и слаба производителност на заявките, което Elasticsearch има очевидно предимство.
С увеличаването на обема данни ефективността на търсенето на Solr намалява, докато Elasticsearch не се променя значително.
В обобщение, архитектурата на Solr не е подходяща за приложения за търсене в реално време.
Реални производствени тестове*
Фигурата по-долу показва 50 пъти увеличение на средната скорост на заявки след преминаване от Solr към Elasticsearch.
Обобщение на сравнение между Elasticsearch и Solr
- И двете са лесни за инсталиране;
- Solr използва Zookeeper за разпределено управление, докато самият Elasticsearch има разпределено управление на оркестрация;
- Solr поддържа повече формати данни, докато Elasticsearch поддържа само JSON файлови формати;
- Solr официално предоставя повече функции, докато самият Elasticsearch се фокусира повече върху основните функции, а разширените функции се предоставят предимно от външни плъгини.
- Solr превъзхожда Elasticsearch в традиционните приложения за търсене, но е значително по-малко ефективен от Elasticsearch при работа с приложения за търсене в реално време.
- Solr е мощно решение за традиционни приложения за търсене, но Elasticsearch е по-подходящ за нови приложения за търсене в реално време.
Други решения с отворен код за търсачки, базирани на Lucene*
1: Използвайте Lucene директно
Забележка: Lucene е JAVA търсачка библиотека, която не е пълно решение сама по себе си и изисква допълнителни усилия за разработка.
Предимства: Зряло решение с много успешни случаи. Apache проекти от най-високо ниво, които продължават да се развиват бързо. Голяма и активна общност за разработка, голям брой разработчици. Това е просто библиотека с класове, с достатъчно пространство за персонализация и оптимизация: след проста персонализация може да отговори на повечето често срещани нужди; Оптимизиран да поддържа 1 милиард+ търсения.
Минуси: Изисква допълнителни усилия за разработка. Цялото мащабиране, разпределение, надеждност и т.н. трябва да се реализира сами; В нереално време има времево забавяне между индексирането и търсенето, а мащабируемостта на настоящата схема за търсене "Lucene Near Real Time search" трябва да бъде допълнително подобрена
Входът към хиперлинк е видим.
2:Ката
Забележка: Базирана на Lucene разпределена, мащабируема, устойчива на грешки, почти в реално време схема за търсене.
Плюсове: Разпространява се от кутията с Hadoop. Има механизъм за мащабиране и устойчивост на повреди.
Недостатъци: Това е просто решение за търсене и все пак трябва да реализирате частта с индексирането сами. Що се отнася до функцията за търсене, се изпълняват само най-основните нужди. Има по-малко успешни истории и зрелостта на проекта е малко по-ниска. Тъй като трябва да поддържа дистрибуция, ще бъде трудно да се персонализира за някои сложни изисквания за заявки.
Входът към хиперлинк е видим.
3:Hadoop принос/индекс
Забележка: Режимът Map/Reduction, разпределено решение за индексиране, може да се използва с Katta.
Предимства: Разпределено индексиране и мащабируемост.
Недостатъци: Само схемата за индексиране, не реализацията на търсенето. Работи в пакетен режим с лоша поддръжка за търсене в реално време.
Входът към хиперлинк е видим.
4: Отвореното решение на LinkedIn
Описание: Разнообразие от решения, базирани на Lucene, включително Zoie за търсене в почти реално време, Bobo за фасетно търсене, Decomposer за алгоритми за машинно обучение, Krati за репозиториуми за обобщаване, Sensei за обвиване на схеми на база данни и още
Предимства: Доказано решение, което поддържа разпределена, мащабируема и богата имплементация на функции
Минуси: Твърде тясна връзка с LinkedIn компанията и лоша персонализация
Входът към хиперлинк е видим.
5:Лукандра
Забележка: Въз основа на Lucene, индексът съществува в базата данни на Cassandra
Плюсове: Вижте предимствата на Касандра
Минуси: Вижте недостатъците на Касандра. Също така, това е само демонстрация и не е сериозно проверена
Входът към хиперлинк е видим.
6:HBasene
Забележка: Според Lucene, индексът съществува в базата данни HBase
Ползи: Вижте предимствата на HBase
Недостатъци: Вижте недостатъците на HBase. Също така, в реализацията, луцен термините се съхраняват като редове, но списъците за публикуване, съответстващи на всеки термин, се съхраняват като колони. С нарастването на броя на списъците за публикуване за един срок скоростта на заявката ще бъде значително засегната
Входът към хиперлинк е видим.
7: Xunsearch
Забележка: Xunsearch възприема структуриран йерархичен дизайн, включващ бекенд услуги и фронт-енд пакети за разработка, с ясни йерархии и без пресичане. Бекендът е демон, написан на C/C++, докато фронтендът използва PHP, най-популярния скриптов език, който е по-удобен за уеб търсене. За подробности вижте Архитектурен дизайн.
Входът към хиперлинк е видим.
|
Публикувано в 11.12.2018 г. 13:42:36 ч.
|
|
|
|
