Вопрос по search, elasticsearch, solr, lucene – Solr против ElasticSearch

695

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

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

Еще одно сравнение 2015 года:quora.com/… rleir
Увидетьsolr-vs-elasticsearch.com Philip Bergström
Этот пост новый & amp; довольно хорошо с моей точки зрения,datanami.com/2015/01/22/solr-elasticsearch-question Eric Wang
Вы можете посмотреть на это:stackoverflow.com/questions/2271600/… Bob Yoplait

Ваш Ответ

12   ответов
535
Update

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

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

Bob Yoplait already linked kimchy's answer to ElasticSearch, Sphinx, Lucene, Solr, Xapian. Which fits for which usage?, which summarizes the reasons why he went ahead and created ElasticSearch, which in his opinion provides a much superior distributed model and ease of use in comparison to Solr.

Ryan Sonnek's Realtime Search: Solr vs Elasticsearch provides an insightful analysis/comparison and explains why he switched from Solr to ElasticSeach, despite being a happy Solr user already - he summarizes this as follows:

Solr may be the weapon of choice when building standard search applications, but Elasticsearch takes it to the next level with an architecture for creating modern realtime search applications. Percolation is an exciting and innovative feature that singlehandedly blows Solr right out of the water. Elasticsearch is scalable, speedy and a dream to integrate with. Adios Solr, it was nice knowing you. [emphasis mine]

The Wikipedia article on ElasticSearch quotes a comparison from the reputed German iX magazine, listing advantages and disadvantages, which pretty much summarize what has been said above already:

Advantages:

ElasticSearch is distributed. No separate project required. Replicas are near real-time too, which is called "Push replication". ElasticSearch fully supports the near real-time search of Apache Lucene. Handling multitenancy is not a special configuration, where with Solr a more advanced setup is necessary. ElasticSearch introduces the concept of the Gateway, which makes full backups easier.

Disadvantages:

Only one main developer [not applicable anymore according to the current elasticsearch GitHub organization, besides having a pretty active committer base in the first place] No autowarming feature [not applicable anymore according to the new Index Warmup API] Initial Answer

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

Apache Solr - Apache Solr offers Lucene's capabilities in an easy to use, fast search server with additional features like faceting, scalability and much more

Amazon ElastiCache - Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud.

Please note that Amazon ElastiCache is protocol-compliant with Memcached, a widely adopted memory object caching system, so code, applications, and popular tools that you use today with existing Memcached environments will work seamlessly with the service (see Memcached for details).

[emphasis mine]

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

ElasticSearch - It is an Open Source (Apache 2), Distributed, RESTful, Search Engine built on top of Apache Lucene.

Amazon CloudSearch - Amazon CloudSearch is a fully-managed search service in the cloud that allows customers to easily integrate fast and highly scalable search functionality into their applications.

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

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

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

+1 есть мысли по поводу потребления памяти?
Не забывайте об агрегациях, которые ElasticSearch предлагает для тех, кому требуется OLAP-подобная функциональность. Облако Солр имеет лишь ограниченную огранку. А если вам нужны оповещения о агрегатах, ES перколяция доставляет.
Все преимущества ElasticSearch, перечисленные в разделе журнала iX, теперь также неверны. 1) SolrCloud больше не является отдельным проектом. Действительно, Solr и Lucene теперь являются частью одного проекта. 2) Solr поддерживает NRT. 3) Solr обрабатывает несколько коллекций в одном кластере. 4) Solr также добавил функцию репликации, которая упрощает резервное копирование.
Теперь, когда за компанией стоитelasticsearch один главный недостаток разработчика должен быть устранен.
Похоже, ElasticSearch решает проблемы с автоподогревом. Увидетьgithub.com/elasticsearch/elasticsearch/issues/1913
8

вы можете использовать ее как обновление 2016 года:enter image description here

Solr Streaming API предоставляет возможности MapReduce
Строка схемы данных немного вводит в заблуждение ... В Elastic есть сопоставления, которые по сути являются схемой (но не требуются по умолчанию). Solr поставляется таким образом, что необходимо установить конфигурацию перед тем, как она будет работать, есть несколько предоставленных примеров конфигураций, которые вы можете выбрать сразу, и одна из них не содержит схем, хотя тщательно управляемые схемы, вероятно, более распространены при использовании solr.
14

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

solr stack

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

Data Purpose: Represent various data types and sources Document building Purpose: Build document information for indexing Indexing and searching Purpose: Build and query a document index Logic enhancement Purpose: Additional logic for processing search queries and results Search platform service Purpose: Add additional functionalities of search engine core to provide a service platform. UI application Purpose: End-user search interface or applications

Справочная статья:Корпоративный поиск

Upvote для хорошей диаграммы
1

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

6

чень помогли мне как лингвисту, «разоблаченному» За последние 15 лет я обращал внимание на то, что в различных поисковых системах Lucene разработка упругого поиска в 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 и другие алгоритмы ранжирования по релевантности. Таким образом, если вы оцениваете или ранжируете слова, фразы или предложения ,asticsearch делает это на лету, без больших накладных расходов на другие подходы к анализу данных, которые занимают часы - еще одна экономия времени эластичного поиска. Сочетая в себе некоторые сильные стороны объединения из агрегирования с оценкой и ранжированием релевантности данных JSON в реальном времени, вы можете найти выигрышную комбинацию, в зависимости от вашего гибкого (истории) или архитектурного (сценарии использования) подхода.

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

2

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

4

A lot(100+) of small(10Mb-100Mb, 1000-100000 documents) search indexes. They are using by a lot of applications (microservices) Each application can use more than one index Small by size index, yes. But huge load(hundreds search-requests per second) and requests are complex (multiple aggregations, conditions and so on) Downtimes are not allowed All of that is working years long, and constantly growing.

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

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

Зачем?

ПЕРВЫЙ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

198

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

Community: Solr has a bigger, more mature user, dev, and contributor community. ES has a smaller, but active community of users and a growing community of contributors Maturity: Solr is more mature, but ES has grown rapidly and I consider it stable Performance: hard to judge. I/we have not done direct performance benchmarks. A person at LinkedIn did compare Solr vs. ES vs. Sensei once, but the initial results should be ignored because they used non-expert setup for both Solr and ES. Design: People love Solr. The Java API is somewhat verbose, but people like how it's put together. Solr code is unfortunately not always very pretty. Also, ES has sharding, real-time replication, document and routing built-in. While some of this exists in Solr, too, it feels a bit like an after-thought. Support: there are companies providing tech and consulting support for both Solr and ElasticSearch. I think the only company that provides support for both is Sematext (disclosure: I'm Sematext founder) Scalability: both can be scaled to very large clusters. ES is easier to scale than pre-Solr 4.0 version of Solr, but with Solr 4.0 that's no longer the case.

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

+1 Есть мысли по поводу потребления памяти?
Я хотел бы добавить, что с DataStax вы получаете почти в режиме реального времени репликацию с Solr.
Спасибо за то, что поделились хорошо написанным мнением из первых рук и разработчиками. Сообщения в блоге. Прошло 2 года с этого поста. Я думаю, что сообщество извлекло бы пользу, если бы вы могли поделиться своими мыслями по пути. Что-то, что может помочь людям решить, какой из них лучше использовать для поиска.
@Rubytastic - вы можете оставить комментарий к сообщению, чтобы привлечь внимание автора и получить некоторую информацию об использовании памяти. Ноblog.sematext.com/2012/05/17/elasticsearch-cache-usage сообщение может уже иметь то, что вы ищете.
+1 Отличный пост в блоге. Раздел и обзор соглашений об именах идеально подходит для тех, кто только начинает исследовать эти продукты.
21

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

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

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

Интересно, что я только что оценил Solr и Elasticsearch и обнаружил, что индексирование одного и того же набора документов 1M заняло в Elasticsearch вдвое больше времени, чем Solr.
11

Основное различие, с которым я столкнулся, состоит в том,

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

More code and less configuration, however there are api's to change but still is a code change for complex types, type within types i.e nested types(wasn't able to achieve in solr)

Solr:

less code and more configuration and hence less maintenance for grouping results during querying(lots of work to achieve in elastic search in short no straight way)
1

очень трудно начать. Особенности Elastic-поиска:

Easy to start, very few setting. Even a newbie can setup a cluster step by step. Simple Restful API which using NoSQL query. And many language libraries for easy accessing. Good document, you can read the book: . There is a web version on official website.
2

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

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

Я мог бы также создать что-то новое, но только потому, что я использую новую технологию или другую архитектуру, это не означает, что это лучше, чем то, что уже есть на рынке.
Эластичный поиск является новым, поэтому он использует новейшие технологии / архитектуру.
Согласитесь, но, как архитектор, вы определенно пойдете лучше, чем то, что уже есть на рынке. Мои 2 цента :)
Почему вы рекомендуете Elastic для новых проектов?

Похожие вопросы