검색 엔진 선택 연구 문서
Elasticsearch 소개*
Elasticsearch는 실시간 분산 검색 및 분석 엔진입니다. 이 시스템은 그 어느 때보다 빠르게 대규모 데이터를 처리할 수 있도록 도와줍니다.
전체 텍스트 검색, 구조화된 검색, 분석 등에 사용할 수 있으며, 물론 이 세 가지를 모두 결합할 수도 있습니다.
Elasticsearch는 현재 사용 가능한 가장 진보되고 효율적인 완전한 기능을 갖춘 오픈 소스 검색 엔진 프레임워크라고 할 수 있는 전체 텍스트 검색 엔진 Apache Lucene™을 기반으로 한 검색 엔진입니다.
하지만 Lucene은 단지 프레임워크일 뿐이며, 그 기능을 최대한 활용하려면 JAVA를 사용하고 Lucene을 프로그램에 통합해야 합니다. 작동 원리를 이해하는 데 많은 학습이 필요하고, 루센은 정말 복잡합니다.
Elasticsearch는 Lucene을 내부 엔진으로 사용하지만, 전체 텍스트 검색을 할 때는 복잡한 Lucene의 작동 원리를 이해하지 못한 통합 API만 사용하면 됩니다.
물론 Elasticsearch는 Lucene만큼 단순하지 않으며, 전체 텍스트 검색 기능뿐만 아니라 다음과 같은 작업도 수행할 수 있습니다:
- 분산 실시간 파일 저장 및 모든 필드 인덱싱을 통해 검색할 수 있습니다.
- 실시간 분석이 가능한 분산 검색 엔진.
- 수백 대의 서버로 확장하여 페타바이트 단위의 구조화 또는 비구조화 데이터를 처리할 수 있습니다.
이렇게 많은 기능이 하나의 서버에 통합되어 있어 클라이언트나 원하는 프로그래밍 언어를 통해 ES의 RESTful API와 쉽게 소통할 수 있습니다.
Elasticsearch를 시작하는 것은 매우 간단합니다. 기본적인 기본 설정이 많아 초보자가 복잡한 이론을 시작하자마자 피할 수 있는 좋은 방법입니다.
설치되어 사용 준비가 되어 있으며, 적은 학습 비용으로 매우 생산적일 수 있습니다.
더 많이 배우면 Elasticsearch의 고급 기능도 활용할 수 있고, 전체 엔진을 유연하게 구성할 수 있습니다. 자신의 필요에 따라 Elasticsearch를 맞춤화할 수 있습니다.
사용 사례:
- 위키피디아는 Elasticsearch를 사용하여 전체 텍스트 검색과 키워드 강조, 검색-입력 및 '의미 있는 검색'과 같은 검색 제안도 제공합니다.
- 가디언은 Elasticsearch를 사용해 방문자 로그를 처리하여 편집자들이 다양한 문서에 대한 대중의 반응을 실시간으로 알 수 있도록 합니다.
- StackOverflow는 전체 텍스트 검색과 위치 및 관련 정보를 결합하여 이와 유사한 질문들을 표현합니다.
- GitHub는 Elasticsearch를 사용해 1,300억 줄 이상의 코드를 검색합니다.
- 골드만 삭스는 매일 5TB의 데이터를 색인화하는 데 이 데이터를 사용하며, 많은 투자은행들이 주식 시장 움직임을 분석하는 데 사용합니다.
하지만 Elasticsearch는 대기업뿐만 아니라 DataDog과 Klout 같은 많은 스타트업들이 역량을 확장하는 데에도 도움을 주었습니다.
Elasticsearch**의 장단점:
장점
- Elasticsearch는 분산 처리되어 있습니다. 다른 구성 요소가 필요하지 않으며, 배포는 실시간으로 이루어지며, 이를 '푸시 복제'라고 합니다.
- Elasticsearch는 Apache Lucene과 함께 거의 실시간 검색을 완벽하게 지원합니다.
- 멀티테넌시 처리는 특별한 설정이 필요하지 않지만, Solr는 더 고급 설정이 필요합니다.
- Elasticsearch는 백업을 더 쉽게 하기 위해 게이트웨이 개념을 사용합니다.
- 각 노드는 동등한 네트워크 구조를 형성하며, 일부 노드가 실패하면 다른 노드들이 자동으로 그 자리를 대신해 작업하도록 배정됩니다.
결점
- 개발자는 한 명뿐입니다(현재 Elasticsearch GitHub 조직은 그 이상이며, 이미 꽤 활발한 유지보수자들이 있습니다).
- 자동화가 충분하지 않아 (현재 새로운 인덱스 워밍업 API에 적합하지 않음)
솔르* 소개
Solr(발음은 'solar')는 Apache Lucene 프로젝트를 위한 오픈소스 엔터프라이즈 검색 플랫폼입니다. 주요 기능으로는 전체 텍스트 검색, 히트 표시, 면형 검색, 동적 클러스터링, 데이터베이스 통합, 그리고 리치 텍스트(예: Word, PDF) 처리 등이 있습니다. Solr는 매우 확장 가능하며 분산 검색 및 인덱스 복제를 제공합니다. Solr는 가장 인기 있는 엔터프라이즈급 검색 엔진이며, Solr4는 NoSQL 지원도 추가합니다.
Solr는 Apache Tomcat이나 Jetty와 같은 서블렛 컨테이너에서 실행되는 자바로 작성된 독립형 전체 텍스트 검색 서버입니다. Solr는 Lucene Java 검색 라이브러리를 전체 텍스트 인덱싱 및 검색의 핵심으로 사용하며, REST와 유사한 HTTP/XML 및 JSON API를 지원합니다. Solr의 강력한 외부 구성 기능 덕분에 Java 코딩 없이도 다양한 유형의 애플리케이션에 쉽게 적응할 수 있습니다. Solr는 더 고급 맞춤화를 지원하는 플러그인 아키텍처를 갖추고 있습니다.
2010년 Apache Lucene와 Apache Solr 프로젝트의 합병으로 인해, 두 프로젝트는 동일한 Apache Software Foundation 개발팀에 의해 생성되고 구현되었습니다. 기술이나 제품에 관해서는 Lucene/Solr 또는 Solr/Lucene가 동일합니다.
Solr의 장단점:
장점
- Solr는 더 크고 성숙한 사용자, 개발자, 기여자 커뮤니티를 보유하고 있습니다.
- HTML, PDF, Microsoft Office 소프트웨어 형식, JSON, XML, CSV 등 일반 텍스트 형식과 같은 여러 형식의 인덱스 추가를 지원합니다.
- 솔르는 비교적 성숙하고 안정적입니다.
- 인덱싱 중 검색은 고려되지 않으며, 속도가 더 빠릅니다.
결점
- 인덱스가 설정되면 검색 효율이 감소하고 실시간 인덱스 검색 효율이 높지 않습니다.
Elasticsearch 대 Solr*
Solr은 단순히 기존 데이터를 검색할 때 더 빠릅니다.
실시간 인덱싱 시 Solr는 IO 차단과 쿼리 성능 저하를 유발하는데, 이는 Elasticsearch가 분명히 우위에 있는 부분입니다.
데이터 양이 증가할수록 Solr의 검색 효율성은 낮아지지만, Elasticsearch는 크게 변하지 않습니다.
요약하자면, Solr의 아키텍처는 실시간 검색 애플리케이션에 적합하지 않습니다.
실제 생산 테스트*
아래 그림은 Solr에서 Elasticsearch로 전환한 후 평균 쿼리 속도가 50배 증가한 것을 보여줍니다.
Elasticsearch와 Solr 비교 요약
- 두 가지 모두 설치가 쉽습니다;
- Solr는 분산 관리를 위해 Zookeeper를 활용하고, Elasticsearch 자체는 분산 오케스트레이션 관리를 지원합니다;
- Solr는 더 많은 데이터 형식을 지원하는 반면, Elasticsearch는 JSON 파일 형식만 지원합니다;
- Solr는 공식적으로 더 많은 기능을 제공하는 반면, Elasticsearch 자체는 핵심 기능에 더 집중하고, 고급 기능은 주로 서드파티 플러그인에서 제공합니다.
- Solr는 전통적인 검색 애플리케이션에서 Elasticsearch보다 성능이 뛰어나지만, 실시간 검색 애플리케이션을 처리할 때는 Elasticsearch보다 효율이 크게 떨어집니다.
- Solr는 전통적인 검색 애플리케이션에 강력한 솔루션이지만, Elasticsearch는 신흥 실시간 검색 애플리케이션에 더 적합합니다.
기타 루센 기반 오픈 소스 검색 엔진 솔루션*
1: 루센을 직접 사용하세요
참고: Lucene은 JAVA 검색 라이브러리로, 독립적으로 완전한 솔루션이 아니며 추가 개발 노력이 필요합니다.
장점: 성숙한 해결책으로 많은 성공적인 사례가 있습니다. 빠르게 발전하는 Apache 최상위 프로젝트들. 크고 활발한 개발 커뮤니티와 많은 개발자들이 있습니다. 클래스 라이브러리일 뿐이며, 맞춤화와 최적화가 가능한 충분한 공간이 있습니다: 간단한 맞춤화 후에는 대부분의 일반적인 요구를 충족할 수 있습니다; 10억+건 검색을 지원하도록 최적화되었습니다.
단점: 추가 개발 노력이 필요합니다. 모든 확장, 배포, 신뢰성 등은 본인이 직접 구현해야 합니다; 비실시간 검색에서는 인덱싱과 검색 사이에 시간 지연이 있으며, 현재의 "Lucene 근실시간 검색" 탐색 방식의 확장성이 더욱 개선되어야 합니다
하이퍼링크 로그인이 보입니다.
2: 카타
참고: 루센 기반 지원 분산, 확장 가능, 내결함성, 거의 실시간 검색 방식.
장점: Hadoop과 함께 기본 배포. 확장 및 내결함 메커니즘을 갖추고 있습니다.
단점: 그냥 검색 솔루션일 뿐이고, 인덱싱 부분은 직접 구현해야 한다는 점입니다. 검색 기능 측면에서는 가장 기본적인 필요만 충족됩니다. 성공 사례는 적고, 프로젝트의 성숙도도 약간 낮습니다. 배포를 지원해야 하기 때문에 복잡한 쿼리 요구사항에 맞게 맞춤화하기 어려울 것입니다.
하이퍼링크 로그인이 보입니다.
3: Hadoop 기여/인덱스
참고: 분산 인덱싱 솔루션인 Map/Reduce 모드를 Katta와 함께 사용할 수 있습니다.
장점: 분산 인덱싱과 확장성.
단점: 인덱싱 방식만 적용되고 검색 구현은 그렇지 않습니다. 배치 모드에서 작동하지만 실시간 검색 지원이 부족합니다.
하이퍼링크 로그인이 보입니다.
4: 링크드인의 오픈소스 솔루션
설명: Lucene 기반 솔루션 범위 내에는 거의 실시간 검색을 위한 Zoie, 면(facet search)을 위한 Bobo, 머신러닝 알고리즘을 위한 Decomposer, 요약 저장소를 위한 Krati, 데이터베이스 스키마 래핑을 위한 Sensei 등이 포함됩니다
장점: 분산되고 확장 가능하며 풍부한 기능 구현을 지원하는 검증된 솔루션
단점: LinkedIn 회사와 너무 밀접하게 연결되어 있고 맞춤화가 부족함
하이퍼링크 로그인이 보입니다.
5: 루칸드라
참고: 루센을 기반으로 한 색인은 카산드라 데이터베이스에 존재합니다
장점: Cassandra의 장점을 참고하세요
단점: 카산드라의 단점을 참고하세요. 또한, 이건 단지 데모일 뿐이고 충분히 검증된 것은 아닙니다
하이퍼링크 로그인이 보입니다.
6: H바세네
참고: Lucene을 기반으로 한 인덱스는 HBase 데이터베이스에 존재합니다
장점: HBase의 장점을 참고하세요
단점: HBase의 단점을 참고하자. 또한, 구현에서는 루세네 용어는 행으로 저장되지만, 각 용어에 대응하는 게시 목록은 열로 저장됩니다. 한 단어의 게시 목록 수가 증가함에 따라 쿼리 속도가 크게 영향을 받습니다
하이퍼링크 로그인이 보입니다.
7: 순서치
참고: Xunsearch는 백엔드 서비스와 프론트엔드 개발 패키지를 포함하는 구조화된 계층적 설계를 채택하며, 명확한 계층 구조와 교차가 없습니다. 백엔드는 C/C++로 작성된 데몬이며, 프론트엔드는 웹 검색 프로젝트에 더 편리한 가장 인기 있는 스크립팅 언어인 PHP를 사용합니다. 자세한 내용은 아키텍처 디자인을 참조하세요.
하이퍼링크 로그인이 보입니다.
|
게시됨 2018. 12. 11. 오후 1:42:36
|
|
|
|
