elastic search

검색엔진의 시초, Lucene

모든 검색엔진의 시초는 루씬(Lucene).
더그 커팅이 고안한 역색인(Inverted Index) 구조인 아파치 루씬을 기반으로 분산처리를 가능하게 한 아파치 솔라(Solr)가 등장해서 검색엔진 시장을 장악했고, 몇 년 후에 역시 루씬을 기반으로 한 Elastic Search가 등장해 지금은 검색엔진 분야에서 지배적인 위치에 있다.

서치엔진 순위 트렌드. 2016년 무렵부터 ES가 가장 많이 사용되고 있다.(https://db-engines.com/en/ranking_trend/search+engine)

ES와 RDBMS

조금 더 쉬운 개념 파악을 위해서 ES에서 사용되는 데이터 구조를 RDBMS에 대응해보면 다음과 같이 맵핑된다.

데이터 구조

Elastic Search는 기본적으로 http 프로토콜로 접근이 가능한 REST API를 통해 데이터 조작을 지원한다. 이를 역시 RDBMS의 SQL과 맵핑해보면:

ES의 HTTP METHOD와 SQL

역색인

일반적인 DB에서는 볼 수 없는 개념인 ‘역색인'은 뭘까?
간단하게 컨셉만 훑어보면,
일반적인 색인의 목적은 ‘문서의 위치’에 대한 index를 만들어서 빠르게 그 문서에 접근하고자 하는 것인데, 역색인은 반대로 ‘문서 내의 문자와 같은 내용물’의 맵핑 정보를 색인해놓는 것이다.
역색인은 검색엔진과 같은 문서의 내용의 검색이 필요한 형태에서 전문 검색의 형태로 주로 쓰인다.
쉬운 예시로 들어보면 일반 색인(forward index)은 책의 목차와 같은 의미이고, 역색인(inverted index)은 책 가장 뒤의 단어 별 색인 페이지와 같다.

모든 단어가 어떤 document에 있는지 색인해두는 것을 역색인이라고 한다. (https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up)

만약 DB에서 “Trade”라는 문구가 포함된 문자열을 찾으려고 한다면 SQL에서는 %Trade% 라고 명확히 입력해야 검색이 가능할 것이다. trade, TRADE, trAde…. 등의 문자열은 직접 하나하나 명시하기 전에는 찾을 수 없을 것이다. ES의 역색인을 활용하면 대소문자 구분 없이 어떤 문구가 들어와도 찾을 수 있다.

ES의 특징과 장단점

ES도 NoSQL의 일종으로 분류할 수 있고, 분산처리를 통해 실시간성으로 빠른 검색이 가능하다. 특히 기존의 데이터로 처리하기 힘든 대량의 비정형 데이터 검색이 가능하며 전문 검색(full text) 검색과 구조 검색 모두를 지원한다.
기본적으로는 검색엔진이지만 MongoDB나 Hbase와 같은 대용량 스토리지로도 활용이 가능하다.

ES의 장점과 단점에 대해서 간단히 살펴보자.

장점

• 오픈소스 검색엔진이다. 활발한 오픈소스 커뮤니티가 ES를 끊임없이 개선하고 발전시키고 있다.
• 전문검색
  내용 전체를 색인해서 특정 단어가 포함된 문서를 검색할 수 있다. 기능별, 언어별 플러그인을 적용할 수 있다.
• 통계 분석
  비정형 로그 데이터를 수집하여 통계 분석에 활용할 수 있다. Kibana를 연결하면 실시간으로 로그를 분석하고 시각화할 수 있다.
• Schemaless
  정형화되지 않은 문서도 자동으로 색인하고 검색할 수 있다.
• RESTful API
  HTTP기반의 RESTful를 활용하고 요청/응답에 JSON을 사용해 개발 언어, 운영체제, 시스템에 관계없이 다양한 플랫폼에서 활용이 가능하다.
• Multi-tenancy
  서로 상이한 인덱스일지라도 검색할 필드명만 같으면 여러 인덱스를 한번에 조회할 수 있다.
• Document-Oriented
  여러 계층 구조의 문서로 저장이 가능하며, 계층 구조로된 문서도 한번의 쿼리로 쉽게 조회할 수 있다.
• 역색인(Inverted Index)
• 확장성
  분산 구성이 가능하다. 분산 환경에서 데이터는 shard라는 단위로 나뉜다.

단점

• 완전 실시간은 아니다.
  색인된 데이터는 1초 뒤에나 검색이 가능하다. 내부적으로 commit과 flush같은 복잡한 과정을 거치기 때문.
• Transaction Rollback을 지원하지 않는다.
  전체적인 클러스터의 성능 향상을 위해 시스템적으로 비용 소모가 큰 롤백과 트랜잭션을 지원하지 않는다. 조심하자..
• 데이터의 업데이트를 제공하지 않는다.
  업데이트 명령이 올 경우 기존 문서를 삭제하고 새로운 문서를 생성한다. 업데이트에 비해서 많은 비용이 들지만 이를 통해 불변성(Immutable)이라는 이점을 취한다.

ES 기본용어

하나의 Index는 복수의 Shard로 구성. Shard와 Lucene Index는 1:1로 맵핑된다.

• Index
  데이터 저장 공간
  하나의 물리 노드에 여러개 논리 인덱스 생성
  하나의 인덱스가 여러 노드에 분산 저장 (M:N)
• Shard
  색인된 문서는 하나의 인덱스 — 인덱스 내부에 색인된 데이터는 여러개의 파티션으로 나뉘어 구성됨.
  (파티션 = 샤드)
• Type
  인덱스의 논리적 구조
  6.1부터 인덱스당 하나의 타입만 설정 가능(6.0 이하에서는 music 인덱스에서 rock, pop등 장르별로 분리하는데 타입을 사용할 수 있었음)
• Document
  데이터가 저장되는 최소 단위
  JSON 포맷으로 저장
  DB의 Row에 대응됨.
• Field
  문서를 구성하기 위한 속성
  DB의 컬럼과 비교할 수 있음
  하나의 필드는 목적에 따라 다수의 데이터 타입을 가질 수 있음
• Mapping
  문서의 필드, 필드 속성을 정의하고 그에 따른 색인 방법을 정의하는 프로세스
  스키마 정의 프로세스라고 보면 된다.

https://jaemunbro.medium.com/elastic-search-%EA%B8%B0%EC%B4%88-%EC%8A%A4%ED%84%B0%EB%94%94-ff01870094f0