Solr 대 ElasticSearch

Solr 대 ElasticSearch

---

이러한 기술 간의 핵심 아키텍처 차이점은 무엇입니까?

또한 일반적으로 각각에 더 적합한 사용 사례는 무엇입니까?

---

최신 정보

이제 질문 범위가 수정되었으므로 이와 관련하여 추가 할 수 있습니다.

사이 많은 비교가 있습니다 아파치 SOLR 와 ElasticSearch 나는 사람들을 참조 할 수 있습니다 있도록 사용할 수 내가 가장 중요한 측면을 다루는 즉, 가장 유용한 자신을 발견 :

• Bob Yoplait은 이미 Kimchy의 답변을 ElasticSearch, Sphinx, Lucene, Solr, Xapian에 연결했습니다. 어떤 용도에 적합합니까? , 그가 계속해서 ElasticSearch를 만든 이유를 요약 한이 문서 는 Solr에 비해 훨씬 우수한 분산 모델과 사용 편의성을 제공한다고 생각 합니다 .

• Ryan Sonnek의 실시간 검색 : Solr vs Elasticsearch 는 통찰력있는 분석 / 비교를 제공하고 이미 Solr 사용자가 만족 스러웠음에도 불구하고 Solr에서 ElasticSeach로 전환 한 이유를 설명합니다. 그는 다음과 같이 요약합니다.

  Solr 은 표준 검색 응용 프로그램을 구축 할 때 선택하는 무기가 될 수 있지만 Elasticsearch 는 최신 실시간 검색 응용 프로그램을 만들기 위한 아키텍처를 통해이를 다음 단계로 끌어 올립니다 . Percolation은 혼자서 Solr를 물에서 바로 불어내는 흥미롭고 혁신적인 기능입니다. Elasticsearch는 확장 가능하고 빠르며 . Adios Solr, 당신을 알게되어 기뻤습니다. [내 강조]

• ElasticSearch에 대한 Wikipedia 기사 는 유명한 독일 iX 잡지 의 비교 를 인용하여 장단점을 나열합니다. 여기에는 위에서 이미 말한 내용이 거의 요약되어 있습니다.

  장점 :

  • ElasticSearch가 배포됩니다. 별도의 프로젝트가 필요하지 않습니다. 복제본도 거의 실시간이며 "푸시 복제"라고합니다.
  • ElasticSearch는 Apache Lucene의 거의 실시간 검색을 완벽하게 지원합니다.
  • 멀티 테넌시 처리는 특별한 구성이 아니며 Solr을 사용하면 고급 설정이 필요합니다.
  • ElasticSearch는 게이트웨이 개념을 도입하여 전체 백업을 더 쉽게 만듭니다.

  단점 :

  • 단 한 명의 주요 개발자 [ 처음에 꽤 활동적인 커미터 기반을 가지고있는 것 외에 현재 elasticsearch GitHub 조직 에 따르면 더 이상 적용되지 않음 ]
  • 자동 워밍 기능 없음 [새로운 Index Warmup API 에 따라 더 이상 적용되지 않음 ]

---

초기 답변

완전히 다른 사용 사례를 다루는 완전히 다른 기술이므로 의미있는 방식으로 전혀 비교할 수 없습니다.

• Apache Solr - Apache Solr는 패싯, 확장 성 등과 같은 추가 기능과 함께 사용하기 쉽고 빠른 검색 서버 에서 Lucene의 기능을 제공합니다.

• Amazon ElastiCache - Amazon ElastiCache는 클라우드 에서 인 메모리 캐시 를 쉽게 배포, 운영 및 확장 할 수있는 웹 서비스입니다 .

  • 제발 참고 이 서비스와 원활하게 작동 기존 memcached를 환경과 오늘을 사용하는 것이 아마존 ElastiCache 코드, 응용 프로그램 및 인기있는 도구 있도록 프로토콜을 준수하는 Memcached가, 널리 채택 된 메모리 개체 캐싱 시스템이다 (참조 memcached를 세부 사항).

[내 강조]

아마도 이것은 다음 두 가지 관련 기술과 혼동되었을 수 있습니다.

• ElasticSearch - Apache Lucene을 기반으로 구축 된 오픈 소스 (Apache 2), 분산, RESTful, 검색 엔진입니다.

• Amazon CloudSearch - Amazon CloudSearch는 고객이 빠르고 확장 성이 뛰어난 검색 기능을 애플리케이션에 쉽게 통합 할 수있는 클라우드의 완전 관리 형 검색 서비스입니다.

SOLR 와 ElasticSearch 제품은 첫눈에 현저하게 유사한 소리와 모두 동일한 백엔드 검색 엔진, 즉 사용 아파치 루씬을 .

하지만 SOLR은 오래, 그리고 성숙 널리 따라 사용되는 매우 다양한, ElasticSearch는 주소로 특별히 개발 된 SOLR의 와 주소로 하드 (어)이다 현대 클라우드 환경에서 확장 성 요구 사항과 단점 SOLR .

따라서 둘 다 원칙적으로 동일한 사용 사례를 다루고 있다고 주장하므로 ElasticSearch 를 최근에 도입 된 Amazon CloudSearch 와 비교하는 것이 가장 유용 할 것입니다 (입문 게시물 Start Searching in One Hour for Less Than $ 100 / Month 참조 ).

---

위의 답변 중 일부는 이제 약간 구식입니다. 제 관점에서 저는 매일 Solr (클라우드 및 비 클라우드)와 ElasticSearch를 모두 사용하고 있는데, 다음과 같은 몇 가지 흥미로운 차이점이 있습니다.

• 커뮤니티 : Solr에는 더 크고 성숙한 사용자, 개발자 및 기여자 커뮤니티가 있습니다. ES에는 작지만 활동적인 사용자 커뮤니티와 성장하는 기여자 커뮤니티가 있습니다.
• 성숙도 : Solr은 더 성숙했지만 ES는 빠르게 성장했으며 안정적이라고 생각합니다.
• 성능 : 판단하기 어렵습니다. 저 / 우리는 직접적인 성능 벤치 마크를 수행하지 않았습니다. LinkedIn의 한 사람이 Solr 대 ES 대 Sensei를 한 번 비교했지만 Solr과 ES 모두에 대해 비전문가 설정을 사용했기 때문에 초기 결과는 무시해야합니다.
• 디자인 : 사람들은 Solr을 좋아합니다. Java API는 다소 장황하지만 사람들은 그것이 결합 된 방식을 좋아합니다. Solr 코드는 불행히도 항상 예쁘지는 않습니다. 또한 ES에는 샤딩, 실시간 복제, 문서 및 라우팅이 내장되어 있습니다. 이 중 일부는 Solr에도 존재하지만 약간의 사후 생각처럼 느껴집니다.
• 지원 : Solr 및 ElasticSearch 모두에 대한 기술 및 컨설팅 지원을 제공하는 회사가 있습니다. 둘 다 지원하는 유일한 회사는 Sematext라고 생각합니다. (공개 : 저는 Sematext 창립자입니다)
• 확장 성 : 둘 다 매우 큰 클러스터로 확장 할 수 있습니다. ES는 Solr 4.0 이전 버전의 Solr보다 확장하기 쉽지만 Solr 4.0에서는 더 이상 그렇지 않습니다.

Solr 대 ElasticSearch 주제에 대한 자세한 내용은 https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ 를 참조하십시오 . 이것은 직접적이고 중립적 인 Solr 대 ElasticSearch 비교를 수행하는 Sematext의 일련의 게시물 중 첫 번째 게시물입니다. 공개 : 저는 Sematext에서 일합니다.

---

여기에있는 많은 사람들이 기능 및 기능 측면에서이 ElasticSearch 대 Solr 질문에 답변했지만 성능 측면에서 비교하는 방법에 대해서는 여기 (또는 다른 곳)에서 많이 논의하지 않습니다.

That is why I decided to conduct my own investigation. I took an already coded heterogenous data source micro-service that already used Solr for term search. I switched out Solr for ElasticSearch then I ran both versions on AWS with an already coded load test application and captured the performance metrics for subsequent analysis.

Here is what I found. ElasticSearch had 13% higher throughput when it came to indexing documents but Solr was ten times faster. When it came to querying for documents, Solr had five times more throughput and was five times faster than ElasticSearch.

---

Since the long history of Apache Solr, I think one strength of the Solr is its ecosystem. There are many Solr plugins for different types of data and purposes.

Search platform in the following layers from bottom to top:

• 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

Reference article : Enterprise search

---

I have created a table of major differences between elasticsearch and Solr and splunk, you can use it as 2016 update:

---

I have been working on both solr and elastic search for .Net applications. The major difference what i have faced is

Elastic search :

• 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)

---

While all of the above links have merit, and have benefited me greatly in the past, as a linguist "exposed" to various Lucene search engines for the last 15 years, I have to say that elastic-search development is very fast in Python. That being said, some of the code felt non-intuitive to me. So, I reached out to one component of the ELK stack, Kibana, from an open source perspective, and found that I could generate the somewhat cryptic code of elasticsearch very easily in Kibana. Also, I could pull Chrome Sense es queries into Kibana as well. If you use Kibana to evaluate es, it will further speed up your evaluation. What took hours to run on other platforms was up and running in JSON in Sense on top of elasticsearch (RESTful interface) in a few minutes at worst (largest data sets); in seconds at best. The documentation for elasticsearch, while 700+ pages, didn't answer questions I had that normally would be resolved in SOLR or other Lucene documentation, which obviously took more time to analyze. Also, you may want to take a look at Aggregates in elastic-search, which have taken Faceting to a new level.

Bigger picture: if you're doing data science, text analytics, or computational linguistics, elasticsearch has some ranking algorithms that seem to innovate well in the information retrieval area. If you're using any TF/IDF algorithms, Text Frequency/Inverse Document Frequency, elasticsearch extends this 1960's algorithm to a new level, even using BM25, Best Match 25, and other Relevancy Ranking algorithms. So, if you are scoring or ranking words, phrases or sentences, elasticsearch does this scoring on the fly, without the large overhead of other data analytics approaches that take hours--another elasticsearch time savings. With es, combining some of the strengths of bucketing from aggregations with the real-time JSON data relevancy scoring and ranking, you could find a winning combination, depending on either your agile (stories) or architectural(use cases) approach.

Note: did see a similar discussion on aggregations above, but not on aggregations and relevancy scoring--my apology for any overlap. Disclosure: I don't work for elastic and won't be able to benefit in the near future from their excellent work due to a different architecural path, unless I do some charity work with elasticsearch, which wouldn't be a bad idea

---

Imagine the use case:

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

Idea to have individual ES instance per each index - is huge overhead in this case.

Based on my experience, this kind of use case is very complex to support with Elasticsearch.

Why?

FIRST.

The major problem is fundamental back compatibility disregard.

Breaking changes are so cool! (Note: imagine SQL-server which require you to do small change in all your SQL-statements, when upgraded... can't imagine it. But for ES it's normal)

Deprecations which will dropped in next major release are so sexy! (Note: you know, Java contain some deprecations, which 20+ years old, but still working in actual Java version...)

And not only that, sometimes you even have something which nowhere documented (personally came across only once but... )

So. If you want to upgrade ES (because you need new features for some app or you want to get bug fixes) - you are in hell. Especially if it is about major version upgrade.

Client API will not back compatible. Index settings will not back compatible. And upgrade all app/services same moment with ES upgrade is not realistic.

But you must do it time to time. No other way.

Existing indexes is automatically upgraded? - Yes. But it not help you when you will need to change some old-index settings.

To live with that, you need constantly invest a lot of power in ... forward compatibility of you apps/services with future releases of ES. Or you need to build(and anyway constantly support) some kind of middleware between you app/services and ES, which provide you back compatible client API. (And, you can't use Transport Client (because it required jar upgrade for every minor version ES upgrade), and this fact do not make your life easier)

Is it looks simple & cheap? No, it's not. Far from it. Continuous maintenance of complex infrastructure which based on ES, is way to expensive in all possible senses.

SECOND. Simple API ? Well... no really. When you is really using complex conditions and aggregations.... JSON-request with 5 nested levels is whatever, but not simple.

---

Unfortunately, I have no experience with SOLR, can't say anything about it.

But Sphinxsearch is much better it this scenario, becasue of totally back compatible SphinxQL.

Note: Sphinxsearch/Manticore are indeed interesting. It's not Lucine based, and as result seriously different. Contain several unique features from the box which ES do not have and crazy fast with small/middle size indexes.

---

I have use Elasticsearch for 3 years and Solr for about a month, I feel elasticsearch cluster is quite easy to install as compared to Solr installation. Elasticsearch has a pool of help documents with great explanation. One of the use case I was stuck up with Histogram Aggregation which was available in ES however not found in Solr.

---

If you are already using SOLR, remain stick to it. If you are starting up, go for Elastic search.

Maximum major issues have been fixed in SOLR and it is quite mature.

---

I only use Elastic-search. Since I found solr is very hard to start. Elastic-search's features:

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

---

Add an nested document in solr very complex and nested data search also very complex. but Elastic Search easy to add nested document and search

참고URL : https://stackoverflow.com/questions/10213009/solr-vs-elasticsearch