이러한 기술 간의 핵심 아키텍처 차이점은 무엇입니까?
또한 일반적으로 어떤 사용 사례가 더 적합합니까?
답변
최신 정보
질문 범위가 수정되었으므로 이와 관련하여 추가 할 수도 있습니다.
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 애플리케이션
- 목적 : 최종 사용자 검색 인터페이스 또는 응용 프로그램
참조 기사 : 기업 검색
답변
답변
.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 데이터 관련성 점수 및 순위를 결합하여 성공적인 조합을 찾을 수 있습니다.
참고 : 위의 집계에 대해서는 비슷한 논의가 있었지만 집계 및 관련성 점수는 아닙니다. 중복에 대한 사과입니다. 공개 : 나는 탄성 연구를하지 않으며 탄성 검색으로 자선 활동을하지 않는 한 다른 건축 경로로 인해 가까운 미래에 우수한 사업으로 이익을 얻을 수 없습니다. 나쁜 아이디어는 아닙니다.