Когда использовать Elastic Search и когда использовать Apache Solr? Чья производительность лучше? [Дубликат]

Несмотря на то, что все вышеупомянутые ссылки заслуживают внимания, и в прошлом мне это очень понравилось, поскольку лингвист «подвергался» различным поисковым системам Lucene за последние 15 лет, я должен сказать, что разработка эластичного поиска очень быстро в Python. При этом некоторые из кодов чувствовали себя неинтуитивными для меня. Итак, я обратился к одному компоненту стека ELK Kibana с точки зрения с открытым исходным кодом и обнаружил, что в Kibana я могу с легкостью создать несколько загадочный код elasticsearch. Кроме того, я мог бы запросить запросы Chrome Sense в Kibana. Если вы используете Kibana для оценки es, это еще больше ускорит вашу оценку. То, что заняло несколько часов, чтобы работать на других платформах, работало в JSON in Sense поверх elasticsearch (интерфейс RESTful) за несколько минут в худшем случае (самые большие наборы данных); в секундах в лучшем случае. Документация для поиска elasticsearch, а также более 700 страниц, не отвечала на мои вопросы, которые обычно решались в документации SOLR или другой Lucene, что, очевидно, занимало больше времени для анализа. Кроме того, вы можете захотеть взглянуть на Агрегаты в эластичном поиске, которые вывели Faceting на новый уровень.

Большее изображение: если вы занимаетесь наукой о данных, текстовой аналитикой или вычислительной лингвистикой, у elasticsearch есть некоторые алгоритмы ранжирования, которые, похоже, хорошо внедряются в области поиска информации. Если вы используете какие-либо TF / IDF-алгоритмы, частоту текста / обратную частоту документов, elasticsearch расширяет этот алгоритм 1960-х до нового уровня, даже используя BM25, Best Match 25 и другие алгоритмы ранжирования ранжирования. Итак, если вы забиваете или ранжируете слова, фразы или предложения, elasticsearch делает этот выигрыш «на лету», без больших накладных расходов на другие подходы к анализу данных, которые занимают часы - еще одна экономия времени elasticsearch. С помощью es, сочетающего в себе сильные стороны bucketing от агрегатов с оценкой и ранжированием релевантности данных JSON в реальном времени, вы можете найти выигрышную комбинацию, в зависимости от вашего гибкого (истории) или архитектурного (использования) подхода.

Примечание. Наблюдалось аналогичное обсуждение вышеперечисленных агрегатов, но не по скоплениям и подсчету релевантности - извинения за любое перекрытие. Раскрытие информации: я не работаю на эластичность и не буду в состоянии в ближайшем будущем извлечь выгоду из их превосходной работы из-за другого архитектурного пути, если я не сделаю какую-то благотворительную работу с elasticsearch, что не будет плохой идеей

Если вы уже используете SOLR, продолжайте придерживаться его. Если вы запускаете, перейдите для поиска Elastic.

Максимальные основные проблемы были исправлены в SOLR и довольно зрелые.

Добавить вложенный файл в solr очень сложный и вложенный поиск данных также очень сложный. но Elastic Search легко добавить вложенный документ и поиск

С давней истории Apache Solr, я думаю, что одна сила Solr - его экосистема. Существует много плагинов Solr для различных типов данных и целей.

[/g1]

Поисковая платформа в нижеследующих слоях:

• Цель данных: представлять различные типы данных и источники
• Создание документа Цель: сбор информации о документе для индексирования
• Индексирование и поиск Цель: сборка и запрос индекса документа
• Улучшение логики Назначение: Дополнительная логика для обработки поисковые запросы и результаты
• Служба поисковой платформы Цель: Добавить дополнительные функции ядра поисковой системы для предоставления сервисной платформы.
• Приложение пользовательского интерфейса Цель: интерфейс или приложения для поиска конечных пользователей

Справочная статья: Поиск предприятия

Я создал таблицу основных различий между elasticsearch и Solr и splunk, вы можете использовать ее как обновление 2016:

Я вижу, что многие люди здесь ответили на этот вопрос ElasticSearch vs Solr с точки зрения возможностей и функциональности, но я не вижу здесь много обсуждения (или в другом месте) относительно того, как они сравниваются с точки зрения производительности.

Вот почему я решил провести собственное исследование . Я взял уже закодированную гетерогенную микросхему источника данных, которая уже использовала Solr для поиска по срокам. Я отключил Solr для ElasticSearch, тогда я запустил обе версии на AWS с уже запрограммированным тестовым приложением и запустил метрики производительности для последующего анализа.

Вот что я нашел. ElasticSearch имел на 13% большую пропускную способность, когда дело доходило до индексирования документов, но Solr был в десять раз быстрее. Когда дело дошло до запросов на документы, Solr имел в пять раз больше пропускной способности и был в пять раз быстрее, чем ElasticSearch.

Представьте пример использования:

1. Множество (100+) небольших (10Mb-100Mb, 1000-100000 документов) индексов поиска.
2. Они используют много приложений (микросервисы)
3. Каждое приложение может использовать более одного индекса
4. Индекс малого размера, да. Но огромная нагрузка (сотни запросов поиска в секунду) и запросы сложны (множественные агрегации, условия и т. Д.)
5. Время простоя не разрешено
6. Все это работает много лет, и постоянно растет.

Идея иметь отдельный экземпляр ES для каждого индекса - в этом случае огромные накладные расходы.

Основываясь на моем опыте, такой вариант использования

FIRST.

Основная проблема - игнорирование фундаментальной обратной совместимости.

. так здорово! (Примечание: представьте себе SQL-сервер, который потребует от вас небольших изменений во всех ваших SQL-операторах, когда он обновлен ... не может этого себе представить. Но для ES это нормально)

Утечки, которые будут удалены следующий крупный релиз настолько сексуальный! (Примечание: вы знаете, Java содержит некоторые изъяны, которые старше 20 лет, но все еще работают в реальной версии Java ...)

И не только это, иногда у вас даже есть то, что нигде не задокументировано (лично натолкнулся только один раз, но ...)

Итак. Если вы хотите обновить ES (потому что вам нужны новые функции для какого-либо приложения или вы хотите получить исправления ошибок), вы находитесь в аду. Особенно, если речь идет о основном обновлении версии.

Клиентский API не будет обратно совместим. Установки индекса не будут совместимы. И обновление всех приложений / служб в тот же момент с обновлением ES нереально.

Но вы должны делать это время от времени. Нет другого способа.

Существующие индексы автоматически обновляются? - Да. Но это не поможет вам, когда вам нужно будет изменить некоторые настройки старого индекса.

Чтобы жить с этим, вам нужно постоянно вкладывать много энергии в ... передовую совместимость ваших приложений / услуг с будущим релизы ES. Или вам нужно построить (и в любом случае постоянно поддерживать) какое-то промежуточное ПО между вашими приложениями / услугами и ES, которые предоставляют вам совместимый клиентский API. (И вы не можете использовать Transport Client (потому что для обновления любой младшей версии ES требуется обновление jar), и этот факт не облегчает вашу жизнь).

Это выглядит просто и доступно. дешево? Нет, это не так. Отнюдь не. Непрерывное обслуживание сложной инфраструктуры, основанной на ES, является дорогой во всех возможных смыслах.

SECOND. Простой API? Ну ... нет. Когда вы действительно используете сложные условия и агрегации ... JSON-запрос с 5 вложенными уровнями - это что угодно, но не просто.

К сожалению, у меня нет опыта работы с SOLR, не могу сказать что-нибудь об этом.

Но Sphinxsearch намного лучше этого сценария, поскольку полностью совместим с SphinxQL.

Примечание: Sphinxsearch / Manticore действительно интересны. Это не основанный на Люсине, а результат сильно отличается. Содержит несколько уникальных функций из коробки, которые ES не имеют и сумасшедшие быстро с индексами малого / среднего размера.

Я использую только Elastic-search. Поскольку я нашел solr, очень сложно начать. Функции Elastic-search:

1. Легко запускается, очень мало настроек. Даже новичок может настраивать кластер поэтапно.
2. Simple Restful API, который использует запрос NoSQL. И многие языковые библиотеки для легкого доступа.
3. Хороший документ, вы можете прочитать книгу:. На официальном сайте есть веб-версия.

Я вижу, что некоторые из вышеперечисленных ответов сейчас немного устарели. С моей точки зрения, и я ежедневно работаю с Solr (Cloud и non-Cloud) и ElasticSearch, вот некоторые интересные отличия:

• Сообщество: у Solr есть больший, более зрелый пользователь , dev и сообщество разработчиков. ES имеет меньшее, но активное сообщество пользователей и растущее сообщество участников
• . Зрелость: Solr более зрелая, но ES быстро растет, и я считаю ее стабильной
• Производительность: сложная судить. Мы не проводили прямых тестов производительности. Человек в LinkedIn сравнивал Solr vs. ES с Sensei один раз, но исходные результаты следует игнорировать, потому что они использовали не экспертную настройку для Solr и ES.
• Дизайн: Люди любят Solr. Java API несколько подробный, но людям нравится, как он складывается. Код Solr, к сожалению, не всегда очень красив. Кроме того, ES имеет осколки, репликацию в реальном времени, встроенную документацию и маршрутизацию. Хотя некоторые из них существуют и в Solr, он чувствует себя немного как последующий.
• Поддержка: есть компании, предоставляющие техническую и консультационную поддержку для Solr и ElasticSearch. Я думаю, что единственная компания, которая обеспечивает поддержку для обоих, - это Sematext (раскрытие: I'm Sematext основатель)
• Масштабируемость: оба могут быть масштабированы до очень больших кластеров. ES легче масштабировать, чем версия Solr версии 4.0 до Solr 4.0, но с Solr 4.0 это уже не так.

Для более полного освещения темы Solr vs. ElasticSearch см. http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/ . Это первое сообщение в серии сообщений от Sematext, где делается прямая и нейтральная сопоставление Solr vs. ElasticSearch. Раскрытие информации: Я работаю в Sematext.

У меня есть Elasticsearch в течение 3 лет и Solr в течение месяца, я чувствую, что кластер elasticsearch довольно прост в установке по сравнению с установкой Solr. У Elasticsearch есть сводный справочный документ с большим объяснением. Один из вариантов использования я застрял в агрегировании гистограмм, который был доступен в ES, но не найден в Solr.

Я работал как с solr, так и с эластичным поиском приложений .Net. Основное отличие, с которым я столкнулся, -

Эластичный поиск:

• Больше кода и меньше конфигурации, однако есть api для изменения, но все же это изменение кода
• для сложных типов, тип внутри типов, т.е. вложенные типы (не удалось достичь в solr)

Solr:

• меньше кода и более конфигурация и, следовательно, меньшее обслуживание
• для группировки результатов во время запроса (много работы для достижения в упругом поиске коротким нет прямого пути)