Solr против ElasticSearch

Ответ 1

Update

Теперь, когда область вопроса была исправлена, я могу добавить что-то в этом отношении:

Существует много сравнений между Apache Solr и ElasticSearch доступно, поэтому я расскажу о тех, кого я нашел наиболее полезными, т.е. охватывающих наиболее важные аспекты:

• Боб Йоплайт уже связал кимчский ответ ElasticSearch, Sphinx, Lucene, Solr, Xapian. Что подходит для использования?, в котором излагаются причины, по которым он пошел дальше, и создал ElasticSearch, который, по его мнению, обеспечивает гораздо более высокую распределенную модель и удобство использования по сравнению с Solr.

• Ryan Sonnek Поиск в реальном времени: Solr vs Elasticsearch обеспечивает проницательный анализ/сравнение и объясняет, почему он переключился с Solr на ElasticSeach, несмотря на будучи счастливым пользователем Solr - он суммирует это следующим образом:

  Solr может быть лучшим выбором при построении стандартного поиска приложений, но Elasticsearch переводит его на следующий уровень с помощью для создания современных приложений поиска в реальном времени. Перколяция - захватывающая и инновационная функция, которая односторонне удаляет Solr прямо из воды. Elasticsearch является масштабируемым, быстрым и мечта интегрироваться с. Адиос Солр, было приятно узнать тебя. [акцент мой]

• Статья в Википедии об ElasticSearch цитирует comparison из известного немецкого журнала iX, перечисляя преимущества и недостатки, которые в значительной степени суммируйте сказанное выше:

  <сильные > Преимущества:

  • Распространяется ElasticSearch. Никакого отдельного проекта не требуется. Реплики также находятся в режиме реального времени, который называется "Push-репликация".
  • ElasticSearch полностью поддерживает поиск в реальном времени Apache Lucene.
  • Обработка многоуровневости не является специальной конфигурацией, где с Solr требуется более сложная настройка.
  • ElasticSearch представляет концепция шлюза, которая облегчает создание резервных копий.

  Недостатки

  • Только один главный разработчик [больше не применим в соответствии с текущей elasticsearch организацией GitHub, кроме того, база коммиттера в первую очередь]
  • Нет функции автосогласования [больше не применимо в соответствии с новым Index Warmup API]

Исходный ответ

Это совершенно разные технологии, предназначенные для совершенно разных вариантов использования, поэтому их нельзя сравнивать ни в каком значимом смысле:

• Apache Solr - Apache Solr предлагает возможности Lucene в удобном и быстром поисковом сервере с дополнительные функции, такие как огранка, масштабируемость и многое другое

• Amazon ElastiCache - Amazon ElastiCache - это веб-сервис, который упрощает развертывание, работу и масштабирование в -memory cache в облаке.

  • Обратите внимание, что Amazon ElastiCache совместим с протоколом Memcached, широко используемой системы кэширования объектов памяти, поэтому код, приложения и популярные инструменты, которые вы используете сегодня в существующих средах Memcached, будут работать без проблем с сервисом (см. Memcached).

[акцент мой]

Возможно, это так или иначе запуталось со следующими двумя связанными технологиями:

• ElasticSearch - это Open Source (Apache 2), Distributed, RESTful, поисковая система, построенная поверх Apache Lucene.

• Amazon CloudSearch - Amazon CloudSearch - это полностью управляемая служба поиска в облаке, которая позволяет клиентам легко интегрировать быстрые и масштабируемые функции поиска в свои приложения.

Предложения Solr и ElasticSearch кажутся похожими на первый взгляд, и оба используют одну и ту же бэкэнд-поисковую систему, а именно Apache Lucene.

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

Как таковой, было бы наиболее полезно сравнить ElasticSearch с недавно введенным Amazon CloudSearch (см. вводный пост Начать поиск за один час менее чем за $100/Месяц), поскольку оба претендуют на то, чтобы в принципе использовать одни и те же варианты использования.

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Solr:

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

Несмотря на то, что все вышеупомянутые ссылки заслуживают внимания и в прошлом мне очень помогли, так как лингвист "подвергался" различным поисковым машинам 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, что не будет плохой идеей

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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

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

Основываясь на моем опыте, такой вариант использования очень сложно поддерживать с помощью Elasticsearch.

Почему?

FIRST.

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

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

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

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

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

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

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

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

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

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

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

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

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

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