Elasticsearch란
Elasticsearch는 Apache Lucene기반의 Java 오픈소스 분산 검색 엔진이다. 기본적으로 데이터를 인덱싱하여 저장하고, 검색, 집계등의 기능을 수행한다. 기존 RDBMS에서 다루기 어려운 full text search 기능이 제공된다.
Elasticsearch 기본 개념
Document
Elasticsearch에서 데이터의 최소 단위이다. RDBMS에서의 row와 비슷하다. Document는 JSON 객체이며, 다양한 필드를 포함하고, document안에 document가 필드로 존재할 수 있다.
Field
Document안에 들어가는 데이터이다. RDBMS에서의 column과 비슷하다.
Type
여러 document가 모여서 하나의 type을 이룬다. RDBMS에서의 table과 비슷하다. Elasticsearch 6.1 부터는 하나의 index(여러 type이 모인 것)당 하나의 type만을 가질수 있게 되었고, 7.0 부터는 type이 사라지고 대신 고정자 _doc 으로 접근해야 한다 (i.e. "http://localhost:9200/index/_doc/1").
Index
데이터가 검색될 수 있는 구조로 변경하기 위해 원본 문서를 검색어 토큰들로 변환(indexing)하여 저장한 것. 여러 type이 모여 한 개의 index를 이룬다. RDBMS에서의 database와 table의 역할을 한다. RDBMS에서는 여러 database의 데이터를 한번에 조회할 수 없지만 Elasticsearch에서는 가능하다 (multitenancy). index는 shard라는 단위로 분산되어 저장된다. Lucene에서 index 파일들은 immutable(불변)하다. Update 시에는 내부적으로 수정될 document를 삭제후 다시 insert한다. 따라서 수정이 잦은 문서를 elasticsearch에 저장하는 것은 비효율적이다.
Shard
Index가 분산되어 처리되는 단위를 뜻한다. 각 shard는 물리적 노드들에 나뉘어서 저장된다. Shard는 두 종류로 나뉜다.
- Primary shard: 모든 document들은 하나의 primary shard에 저장된다. Primary shard의 기본 개수는 5개이다.
- Replica shard: Primary shard의 복제본이다. 원본 데이터에 fault 발생시 복구하기 위해 사용된다 (fault tolerance). Replica shard의 기본 개수는 1개이다.
Segment
Segment는 shard가 물리적으로 나뉘어서 저장되는 단위이다. Document가 처음부터 segment에 저장되는 것은 아니다. Indexing된 document는 먼저 시스템의 메모리 버퍼에 저장되고, 이 때는 document가 검색되지 않는다. Elasticsearch의 refreash 과정을 거쳐야 segment 단위로 physically 저장되고 검색이 된다. Segment는 immutable 하며 document가 update 되면 새로운 segment가 생성된다. Segment가 많아질수록 search 할 때 성능이 낮아질 수 있다. 따라서 Elasticsearch 내부에서 background로 segment merging을 진행한다.
Mapping
Elasticsearch의 index에 들어가는 데이터의 type을 정의하는 것이다. RDBMS에서의 schema와 유사하다. Elasticsearch는 선 indexing 후 mapping을 지원하며, 새로운 필드가 추가되면 동적으로 해당 필드 indexing 후 mapping까지 해준다.
Elasticsearch의 특징
실시간 분석
Elasticsearch는 Hadoop과 같은 배치 기반의 분산 처리 시스템과는 달리 클러스터가 실행되고 있는 동안 데이터가 입력으로 들어오고, 인덱싱이 되며, 실시간에 가까운(near real-time) 속도로 인덱싱된 데이터의 검색, 집계가 가능하다. 하지만 실제 운영을 했을때 간헐적으로 많은 request로 인한 HTTP 429 에러를 리턴한다. 실시간에 가까운 처리가 가능하지만, 모든 request를 실시간으로 처리하기 보단 서비스 구조에서 캐시 레이어를 두고 사용하는 것이 더 안정적인 운영을 할 수 있는 방법인 것 같다. (또는 클러스터 사이즈를 많이 키우거나)
full text search 엔진
Elasticsearch는 흔히 아는 forward index가 아닌 inverted index 구조를 사용하여 데이터를 저장한다. document가 포함하는 word를 저장할 때 forward index 구조가 key를 document, value를 words로 한다면 inverted index 구조는 key를 word, value를 documents로 한다.
Forward Index
| Document | Words |
|---|---|
| doc1 | apple, google, samsung |
| doc2 | airflow, spark, google |
| doc3 | google, kiensis, toy, apple |
Inverted Index
| Word | Document |
|---|---|
| doc1, doc2, doc3 | |
| spark | doc2 |
| apple | doc1, doc3 |
full text에서 특정 문자열을 찾을 때 inverted index 구조의 성능이 매우 좋다. 문자열 내의 단어를 key로 검색해서 단어들이 포함된 document를 빠르게 찾을 수 있기 때문이다.
RESTFul API
Elasticsearch는 모든 데이터 조회, 입력, 삭제를 http 프로토콜을 통해 REST API로 처리한다. GET, PUT, POST, DELETE, HEAD 등의 method들이 사용된다.
Multitenancy
Elasticsearh의 데이터들은 인덱스라는 단위로 구성되며 분산되어 서로 다른 저장소에 저장된다. 서로 다른 인덱스 이지만 별도의 커넥션 없이 하나의 쿼리로 묶어서 검색하여 하나의 출력으로 리턴할 수 있다.
Kibana
Elasticsearch 시각화 툴이다. Elasticsearch JSON기반 데이터 통신을 지원하기에 다양한 클라이언트와 연동이 가능하고, 그 중 유명져서 ELK stack에 포함된게 Kibana다.
Reference
