Solr vs. ElasticSearch [закрыто]

Каковы основные архитектурные различия между этими технологиями?

Кроме того, какие варианты использования обычно более подходят для каждого?

Обновить

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

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

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

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

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

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

  Преимущества :

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

  Недостатки :

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

Начальный ответ

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

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

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

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

[Акцент мой]

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

• ElasticSearch - это открытый исходный код (Apache 2), распределенный, RESTful, поисковый движок, построенный на основе Apache Lucene.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Solr:

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

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

Более широкая картина: если вы занимаетесь наукой о данных, анализом текста или компьютерной лингвистикой, в Flexiblesearch есть несколько алгоритмов ранжирования, которые, похоже, успешно внедряются в области поиска информации. Если вы используете какие-либо алгоритмы TF / IDF, текстовую частоту / частоту обратных документов ,asticsearch расширяет этот алгоритм 1960-х годов на новый уровень, даже используя BM25, Best Match 25 и другие алгоритмы ранжирования по релевантности. Таким образом, если вы оцениваете или ранжируете слова, фразы или предложения, FlexibleSearch делает это на лету, без больших накладных расходов, связанных с другими подходами к анализу данных, которые занимают часы - еще одна экономия времени. Сочетая в себе некоторые сильные стороны объединения из агрегирования с оценкой и ранжированием релевантности данных JSON в реальном времени, вы можете найти выигрышную комбинацию,

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

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

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

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

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

Почему?

ПЕРВЫЙ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы уже используете SOLR, оставайтесь на этом. Если вы запускаете, перейдите на Elastic search.

Максимальное количество серьезных проблем было исправлено в SOLR, и он вполне зрел.

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

Я использую только Elastic-поиск. Поскольку я нашел Solr очень трудно начать. Особенности Elastic-поиска:

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

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