Solr 및 ElasticSearch [닫기]

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

또한 일반적으로 어떤 사용 사례가 더 적합합니까?

최신 정보

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

Apache Solr 과 ElasticSearch를 비교할 수있는 방법이 많이 있으므로 가장 유용한 부분, 즉 가장 중요한 부분을 다루는 내용을 참조하겠습니다.

• Bob Yoplait은 이미 kimchy의 답변을 ElasticSearch, Sphinx, Lucene, Solr, Xapian에 연결했습니다. 어느 것이 어떤 용도에 적합합니까? 그는 이유 요약하는 나서서 ElasticSearch 만든 그의 의견에 훨씬 우수한 분산 모델과 사용 편의성을 제공 SOLR에 비해합니다.

• Ryan Sonnek의 실시간 검색 : Solr vs Elasticsearch 는 통찰력있는 분석 / 비교를 제공하며, Solr 사용자가 이미 행복한데도 Solr에서 ElasticSeach로 전환 한 이유를 설명합니다.

  Solr 은 표준 검색 응용 프로그램을 구축 할 때 선택의 무기가 될 수 있지만 Elasticsearch 는 최신 실시간 검색 응용 프로그램을 작성하기위한 아키텍처 를 통해 다음 단계로 나아가고 있습니다. Percolation은 솔러를 물 밖으로 직접 날려주는 흥미롭고 혁신적인 기능입니다. Elasticsearch는 확장 가능하고 빠르며 통합하려는 꿈입니다 . 아디오스 솔러 [강조 광산]

• 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 와 비교하는 것이 가장 유용 할 것입니다 ( 두 번에 $ 100 / 월 미만의 한 시간에 검색 시작 소개 게시물 참조 ).

위의 답변 중 일부가 약간 오래되었습니다. 내 관점에서 볼 때 매일 Solr (Cloud 및 non-Cloud) 및 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 4.0에서는 더 이상 그렇지 않습니다.

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

나는 많은 사람들 이이 기능 및 기능면 에서이 ElasticSearch vs Solr 질문에 대답했지만 성능면에서 어떻게 비교되는지에 대해서는 여기 (또는 다른 곳)에서 많이 논의하지는 않습니다.

그래서 내가 직접 조사 하기로 결정했습니다 . 용어 검색에 이미 Solr을 사용한 이미 코딩 된 이기종 데이터 소스 마이크로 서비스를 사용했습니다. Solr for ElasticSearch를 전환 한 다음 이미 코딩 된로드 테스트 애플리케이션을 사용하여 AWS에서 두 버전을 모두 실행하고 후속 분석을위한 성능 지표를 캡처했습니다.

여기 내가 찾은 것이 있습니다. 문서를 색인화 할 때 ElasticSearch의 처리량은 13 % 높았지만 Solr은 10 배 빨랐습니다. 문서를 쿼리 할 때 Solr은 처리량이 5 배 더 많았으며 ElasticSearch보다 5 배 더 빨랐습니다.

Apache Solr의 오랜 역사 이후 Solr의 장점 중 하나는 생태계 라고 생각 합니다. 다양한 유형의 데이터 및 목적을위한 많은 Solr 플러그인이 있습니다.

아래에서 위로 다음 레이어의 검색 플랫폼 :

• 데이터
  • 목적 : 다양한 데이터 유형 및 소스를 나타냅니다.
• 문서 작성
  • 목적 : 색인 작성을위한 문서 정보 빌드
• 인덱싱 및 검색
  • 목적 : 문서 색인 작성 및 조회
• 논리 향상
  • 목적 : 검색 쿼리 및 결과 처리를위한 추가 논리
• 검색 플랫폼 서비스
  • 목적 : 서비스 플랫폼을 제공하기 위해 검색 엔진 코어의 추가 기능을 추가하십시오.
• UI 애플리케이션
  • 목적 : 최종 사용자 검색 인터페이스 또는 응용 프로그램

참조 기사 : 기업 검색

elasticsearch와 Solr과 splunk의 주요 차이점에 대한 표를 작성했으며 2016 업데이트로 사용할 수 있습니다.

.Net 응용 프로그램에 대한 solr 및 탄력적 검색을 모두 수행하고 있습니다. 내가 직면 한 주요 차이점은

탄력적 검색 :

• 더 많은 코드와 더 적은 구성, 그러나 API는 변경되지만 여전히 코드 변경입니다.
• 복잡한 유형의 경우 유형 내 유형, 즉 중첩 유형 (Solr에서는 달성 할 수 없음)

Solr :

• 더 적은 코드와 더 많은 구성 및 따라서 적은 유지 관리
• 쿼리 중 결과를 그룹화하기위한 것 (일관된 방법으로 탄력적 인 검색을 수행하기위한 많은 작업)

지난 15 년 동안 다양한 Lucene 검색 엔진에 언어학자가 노출 된 것처럼 위의 모든 링크는 장점이 있고 과거에 큰 도움이되었지만, 탄성 검색 개발은 Python에서 매우 빠르다고 말해야합니다. 즉, 일부 코드는 직관적이지 않습니다. 그래서 오픈 소스 관점에서 ELK 스택의 한 구성 요소 인 Kibana에 접근하여 Kibana에서 다소 복잡한 암호 검색 코드를 매우 쉽게 생성 할 수 있음을 발견했습니다. 또한 Chrome Sense es 쿼리를 Kibana로 가져올 수도 있습니다. Kibana를 사용하여 es를 평가하면 평가 속도가 더 빨라집니다. 다른 플랫폼에서 실행하는 데 몇 시간이 걸렸던 것은 Elasticsearch (RESTful 인터페이스)의 Sense에서 JSON으로 시작하여 최악의 경우 (최대 데이터 세트) 몇 분 만에 실행되었습니다. 몇 초 만에. 700 페이지 이상인 elasticsearch에 대한 문서는 일반적으로 SOLR 또는 다른 Lucene 문서에서 해결 될 것이라는 질문에 대답하지 않았으므로 분석에 더 많은 시간이 걸렸습니다. 또한 Faceting을 새로운 수준으로 끌어 올린 탄력적 검색에서 집계를 살펴볼 수도 있습니다.

더 큰 그림 : 데이터 과학, 텍스트 분석 또는 전산 언어학을 수행하는 경우 elasticsearch는 정보 검색 영역에서 혁신적으로 보이는 일부 순위 알고리즘을 가지고 있습니다. TF / IDF 알고리즘, 텍스트 빈도 / 역 문서 빈도를 사용하는 경우 elasticsearch는 BM25, Best Match 25 및 기타 관련성 순위 알고리즘을 사용하여이 1960 년대 알고리즘을 새로운 수준으로 확장합니다. 따라서 단어, 구 또는 문장의 점수를 매기거나 순위를 매기는 경우, 탄성 검색은 시간이 걸리는 다른 데이터 분석 접근 방식의 큰 오버 헤드없이 또 다른 탄성 검색 시간을 절약 할 수 있습니다. es를 사용하면 집계에서 얻은 버킷 팅의 장점과 실시간 JSON 데이터 관련성 점수 및 순위를 결합하여 성공적인 조합을 찾을 수 있습니다.

참고 : 위의 집계에 대해서는 비슷한 논의가 있었지만 집계 및 관련성 점수는 아닙니다. 중복에 대한 사과입니다. 공개 : 나는 탄성 연구를하지 않으며 탄성 검색으로 자선 활동을하지 않는 한 다른 건축 경로로 인해 가까운 미래에 우수한 사업으로 이익을 얻을 수 없습니다. 나쁜 아이디어는 아닙니다.

유스 케이스를 상상해보십시오.

1. 작은 (10Mb-100Mb, 1000-100000 개의 문서) 검색 색인이 많이 (100+) 있습니다.
2. 그들은 많은 응용 프로그램 (마이크로 서비스)에서 사용하고 있습니다.
3. 각 응용 프로그램은 둘 이상의 색인을 사용할 수 있습니다
4. 크기별 인덱스가 작습니다. 그러나 엄청난 양의 부하 (초당 수백 건의 검색 요청)와 요청은 복잡합니다 (여러 집계, 조건 등)
5. 가동 중지 시간은 허용되지 않습니다
6. 이 모든 것이 몇 년 동안 일해 왔으며 끊임없이 성장하고 있습니다.

각 인덱스마다 개별 ES 인스턴스를 갖는 아이디어는이 경우 엄청난 오버 헤드입니다.

내 경험을 바탕으로 이러한 유스 케이스는 Elasticsearch에서 지원하기가 매우 복잡합니다.

왜?

먼저.

주요 문제는 근본적인 역 호환성 무시입니다.

주요 변경 사항이 너무 멋집니다! (참고 : 업그레이드 할 때 모든 SQL 문에서 약간의 변경을 수행 해야하는 SQL 서버를 상상해보십시오 ... 상상할 수는 없지만 ES의 경우 정상입니다)

다음 주요 릴리스에서 더 이상 사용되지 않는 폐기는 너무 섹시합니다! (참고 : Java에는 20 세 이상이지만 더 이상 실제 Java 버전에서 작동하지 않는 일부 사용 중단이 포함되어 있습니다 ...)

그리고 그뿐만 아니라 때로는 문서화되지 않은 무언가가 있습니다 (개인적으로 한 번만 나왔지만 ...)

그래서. ES를 업그레이드하려면 (일부 앱의 새로운 기능이 필요하거나 버그 수정을 원하기 때문에) 지옥에 있습니다. 특히 메이저 버전 업그레이드에 관한 것입니다.

클라이언트 API는 이전 버전과 호환되지 않습니다. 인덱스 설정은 이전 버전과 호환되지 않습니다. ES 업그레이드로 모든 앱 / 서비스를 동시에 업그레이드하는 것은 현실적이지 않습니다.

그러나 당신은 때때로 그것을해야합니다. 다른 방법은 없습니다.

기존 색인이 자동으로 업그레이드됩니까? - 예. 그러나 이전 인덱스 설정을 변경해야 할 때는 도움이되지 않습니다.

그에 부응하려면 앞으로 출시 될 ES 릴리스와 앱 / 서비스의 호환성에 많은 힘을 투자해야합니다. 또는 앱 / 서비스와 ES 사이에 일종의 미들웨어를 빌드하고 (어쨌든 지속적으로 지원해야) 다시 호환되는 클라이언트 API를 제공합니다. (그리고 모든 마이너 버전 ES 업그레이드마다 jar 업그레이드가 필요하기 때문에 Transport Client를 사용할 수 없으며, 이로 인해 인생이 더 쉬워지지는 않습니다)

간단하고 저렴 해 보입니까? 아뇨. 그것과는 거리가 멀다. ES를 기반으로하는 복잡한 인프라의 지속적인 유지 관리는 모든 의미에서 비싸다.

둘째. 간단한 API? 글쎄 ... 아니 복잡한 조건과 집계를 실제로 사용하는 경우 ... 중첩 된 수준이 5 개인 JSON 요청은 간단하지만 간단하지는 않습니다.

불행히도, 나는 SOLR에 대한 경험이 없으며 그것에 대해 아무 말도 할 수 없습니다.

그러나 Sphinxsearch는 이전 버전과 호환되는 SphinxQL로 인해이 시나리오보다 훨씬 낫습니다.

참고 : Sphinxsearch / Manticore는 실제로 흥미 롭습니다. Lucine을 기반으로하지 않으므로 결과적으로 크게 다릅니다. ES에는없는 몇 가지 고유 한 기능이 포함되어 있으며 중소형 인덱스로 빠르고 빠릅니다.

이미 SOLR을 사용하고 있다면 그대로 유지하십시오. 시작하는 경우 탄력적 검색으로 이동하십시오.

SOLR에서 최대 주요 문제가 해결되었으며 매우 성숙했습니다.

나는 3 년 동안 Elasticsearch를 사용하고 약 한 달 동안 Solr을 사용했으며, Elasticsearch 클러스터는 Solr 설치와 비교하여 설치가 매우 쉽다고 생각합니다. Elasticsearch에는 훌륭한 설명이 포함 된 도움말 문서 풀이 있습니다. 유스 케이스 중 하나는 ES에서 사용할 수 있지만 Solr에서는 찾을 수없는 히스토그램 집계와 관련이 있습니다.

Elastic-search 만 사용합니다. solr이 시작하기가 매우 어렵다는 것을 알았으므로. 탄력적 검색 기능 :

1. 시작하기 쉽고 설정이 거의 없습니다. 초보자조차도 단계별로 클러스터를 설정할 수 있습니다.
2. NoSQL 쿼리를 사용하는 간단한 Restful API. 그리고 쉽게 접근 할 수있는 많은 언어 라이브러리.
3. 좋은 문서, 당신은 책을 읽을 수 있습니다 :. 공식 웹 사이트에는 웹 버전이 있습니다.

매우 복잡하고 중첩 된 데이터 검색도 매우 복잡한 중첩 문서를 추가하십시오. 중첩 된 문서 및 검색을 쉽게 추가 할 수있는 Elastic Search