Elasticsearch는 스키마가 존재하지 않는 데이터를 분산 저장/검색하는 엔진입니다. ELK의 요소 중 하나로서, 간략한 소개는 아래 글에서 다룬 적이 있습니다. 따라서 이번 포스트는 Elasticsearch의 세부적인 구조는 어떻게 생겼는지, 데이터를 어떻게 저장하고 조회하는지 살펴보는데 힘을 실었습니다.
https://citizen.tistory.com/22
ELK 스택 #1 (ELK에 대해서)
1. ELK stack이란 ELK 스택은 Elasticsearch, Logstash, Kibana의 로그 수집 및 시각화를 위한 세 가지 오픈소스 프로젝트를 의미하는 약어입니다. 이미 수년 전부터 사용자 시스템 및 애플리케이션 로그 분석
citizen.tistory.com
1. ElasticSearch의 주요 용어
Node
데이터를 저장하는 하나의 서버입니다. 각 Node에는 고유한 이름이 붙으며, 어떤 데이터를 찾거나 인덱싱이 필요하면 ElasticSearch는 해당하는 Node 안에서 작업을 관리합니다.
Cluster
ElasticSearch는 분산 저장/검색 프레임워크이며, 그렇기에 Node 역시 하나 이상으로 존재합니다. 이 Node들의 집합을 Cluster라고 부릅니다. 그러나 Cluster 안에는 단순히 데이터를 저장하는 Node들만 있는게 아닙니다. ElasticSearch는 Cluster의 관리를 유연하게 하기위해서 Node를 아래 3가지 유형으로 구분합니다.
Master Node: Cluster 전반에 걸쳐 인덱싱과 조회 작업을 매니징하는NodeData Node: 실제로 데이터가 저장되어 있는NodeClient Node: ElasticSearch 엔진으로 들어온 작업 요청을Master/Data Node에게 전달하는 역할을 수행
document
document는 ElasticSearch에서 가장 기본적인 데이터 단위입니다. 개별 documet는 고유한 식별자를 가지고 있습니다. document의 포맷은 JSON을 따르며 각 요소값들은 key:value 형태로 구성됩니다.
field
document 안에서 개별 key에 매칭되는 요소값을 field라고 부릅니다.
index/type
index는 document들 중에 비슷한 특징을 가진 것들만 모아둔 컬렉션입니다. ElasticSearch의 명령 쿼리(데이터 삽입/수정/삭제/조회)들은 이 인덱스 수준에서 수행됩니다. type은 이러한 index 안의 sub-class 같은 요소이며 초창기까지 쓰이다가 Elastic 7.0 버전 이후로는 index에 완전히 흡수되어 사용되지 않는 개념입니다.
shard
어떤 index는 대량의 데이터를 담아야할 수 있습니다. 가끔은 그 용량이 Node 하나의 하드 용량을 넘어서는 수준일 수 있으며, 이런 경우에는 index의 데이터를 여러 개의 shard라는 조각으로 분리하고 분산 저장합니다. shard를 도입함에 따라 데이터 처리 과정이 병렬적으로 신속하게, 그리고 큰 부하없이 이뤄질 수 있습니다.
replica
replica는 shard의 복사본이며, 큰 규모의 시스템(특히나 클라우드) 환경에서 일부 shard가 소실되거나 장애가 발생했을 때, 이를 복구하는 용도로 활용됩니다. replica는 원본 shard(primary shard)가 있는 Node를 제외한 다른 장소에 보관된다는 특징이 있습니다.
2. 관계형 데이터베이스(RDBMS)와의 비교
위에서 설명한 ElasticSearch의 요소와 관계형 데이터베이스의 구성요소들을 매핑 시켜 표로 정리해보았습니다.
RDBMS는 분산처리 개념이 없기에 ElasticSearch의 Node, Cluster에 대응하는 요소가 없다고 봐도 무방하며, index가 사실상 RDBMS의 database 역할을 담당합니다. RDBMS에서 각 table은 여러 줄의 record(row)로, 그리고 record의 요소들은 column별로 구분되어 표시됩니다. 이를 ElasticSearch 구조에 빗대보면, 각기 다른 field 값을 지닌 document가 모여서 type을 형성한다고 볼수 있습니다.
3. ElasticSearch의 인덱싱 방식: Inverted Index
Elasticsearch의 인덱싱 메커니즘은 살짝 독특한 자료구조를 기반으로 합니다. 어떤 특정 키워드가 포함된 문서를 찾는 가장 일반적인 시도라면 모든 문서들을 하나하나 열람하여 해당 키워드를 찾는 방법일 것입니다. 문서의 수가 많아지거나, 키워드 검색 쿼리의 수행 횟수가 증가할수록 이러한 시도는 시간도 많이 걸리고 자원을 많이 소모할 것임을 충분히 예상 가능합니다.
상기 서술한 문제를 효율적으로 풀기 위해 설계된 인덱싱 메커니즘이 Inverted Index인데요. 각 키워드가 어떤 문서들에 속해 있는지를 해쉬맵 형태의 자료구조로 저장하는 기법입니다. 위 그림을 예시로 들면, "blue"라는 키워드는 Document 1과 3에서, "sky"라는 키워드는 Document 2,3에서 발견할 수 있음을 테이블로 표시하고 있습니다. 만약 "bright blue butterfly"라는 단어가 포함된 document를 조회하고자 하면, 우측 테이블로부터 "bright", "blue", "butterfly"에 해당하는 키워드가 Document 3에 공통적으로 등장한다는 결론을 얻어낼 수 있습니다.
앞서 본 "blue"와 같은 키워드를 Elasticsearch에서는 텀(term) 또는 토큰(token)이라고도 하며, document에 존재하는 데이터(e.g., "The bright blue butterfly hangs...")들은 토큰 형태(e.g., 'The' / 'bright' / 'blue' ...)로 쪼개져 정렬된 뒤 Inverted Index 테이블에 반영됩니다.