2021. 7. 14. 00:43ㆍDB
Elastic Search의 개념
Elasticsearch란 아파치 루씬(Lucene) 기반의 오픈소스 실시간 분산 검색 엔진으로 JSON 기반의 비정형 데이터 분산 검색 및 분석을 지원합니다. 설치와 서버 확장이 매우 편리하며, 실시간 검색 서비스 지원, 분산 및 병렬처리, 그리고 멀티테넌시 기능을 제공하고 다양한 기능을 플러그인 형태로 구현하여 적용할 수 있는 것이 큰 특징입니다. 또한 클러스터로 구성할 수 있기 때문에 검색 대상의 용량이 증가했을 때 대응하기가 매우 수월합니다.
Elastic Search의 검색이 빠른 이유
Elastic Search와 RDB의 비교
Elastic Search는 기존의 RDBMS와 데이터를 저장하는 방식이 다릅니다. 각 text들이 포함된 document들을 나열된 형태로 저장합니다. 아래의 그림과 같이 document들이 indexing되어 key, value 형태로 mapping됩니다.
Elasticsearch 구조
논리적 구조
도큐먼트(Document)
Elasticsearch 데이터 최소 단위(RDBMS의 Row와 비슷). JSON 오브젝트 하나. 하나의 Document는 다양한 필드로 구성되어 있으며, 이 필드에는 데이터 필드에 해당하는 데이터 타입이 들어감. 중첩구조를 지원하기 때문에 Document 내부에 Document가 들어가는 것도 가능함.
타입(Type)
여러개의 Document가 모여서 한개의 Type을 이룸(RDBMS의 Table과 비슷). 하지만 Elasticsearch 7.0부터 Type이 완전히 사라졌으며, 현재 Index가 RDBMS의 Table과 Database 역할을 한다고 생각하면 됨.
필드(Field)
필드(Field)는 Document에 들어가는 데이터 타입으로 RDBMS의 열(Column)과 비슷하다. 하지만 Elasticsearch의 필드는 RDBMS보다 동적이다. RDBMS에서는 하나의 열(Column)이 하나의 데이터 타입만 가질 수 있지만, Elasticsearch에서는 하나의 필드(Field)가 여러개의 데이터 타입을 가질 수 있다.
매핑(Mapping)
매핑(Mapping)은 필드와 필드의 속성을 정의하고 색인 방법을 정의한다. 매핑 정보에 여러가지 데이터 타입 지정이 가능하지만 필드명 자체는 중복이 불가능하다.
인덱스(Index)
여러개의 Type이 모여 한개의 Index를 이룸(RDBMS의 Database와 비슷). Elasticsearch 6.1부터는 하나의 Index는 하나의 Type만 가질 수 있기 때문에 Database + Table의 역할.
RDBMS는 쿼리 하나로 여러 데이터베이스의 데이터를 동시에 조회할 수 없지만, Elasticsearch는 가능함(멀티테넌시)
Elasticsearch를 클러스터(분산환경)으로 구성했을 경우 Index는 여러 노드에 분산 저장/관리된다. 기본설정은 5개의 프라이머리 샤드(Prmiary Shard)와 1개의 레플리카 샤드(Replica Shard)를 생성한다. 샤드 수는 인덱스 생성 시 옵션 값을 이용하여 변경 가능함.
물리적 구조
노드(Node)
노드(Node)는 Elasticsearch 클러스터에 포함된 단일 서버로서 데이터를 저장하고 클러스터의 색인화 및 검색 기능에 참여합니다. 노드는 클러스터처럼 이름으로 식별되며, 원한다면 특정 노드 이름으로 정의할 수 있으며 관리의 목적에 맞게 정의합니다.
RDBMS와는 다르게 여러개의 노드로 구성된 엘라스틱서치 클러스터는 관리하는 데이터가 커져도 노드를 추가시켜서 대용량 처리가 가능합니다.
엘라스틱 서치에서 제공해주는 노드는 다음과 같습니다.
- 마스터 노드(Master Node) : 클러스터 관리 노드. 노드 추가/제거, 인덱스 생성/삭제 등 클러스터의 전반적 관리 담당. 여러 개의 마스터 노드를 설정하면 하나의 마스터 노드로 작동됨.
- 데이터 노드(Data Node) : 데이터(Document)가 저장되는 노드. 데이터가 분산 저장되는 물리적인 공간인 샤드가 배치되는 노드. 색인/검색/통계 등 데이터 작업 수행(리소스가 많이 필요함. 모니터링 필수). 마스터와는 분리 필요.
- 코디네이팅 노드(Coordinating Node) : 사용자의 요청을 받고 라운드로빈(Round Robin)방식으로 분산시켜주는 노드. 클러스터에 관련된 것은 마스터 노드로 넘기고 데이터 관련된 것은 데이터 노드로 넘김.
- 인제스트 노드(Ingest Node) : 문서 전처리 작업 수행. 인덱스 생성 전 문서의 형식 변경을 다양하게 할 수 있음(스크립트로 전처리 파이프라인 구성).
샤드(Shard)
인덱스(index) 내부에는 색인된 데이터들이 존재하는데 이 데이터들은 하나로 뭉쳐서 존재하지 않고 물리적 공간에 여러개의 부분들로 나뉘어서 존재합니다. 이러한 부분들을 샤드(Shard)라고 합니다.
엘라스틱서치는 기본적으로 인덱스를 5개의 샤드로 나누어서 저장합니다(변경 가능). 인덱스를 여러 샤드로 나누어 저장하기 때문에 콘텐츠 볼륨의 수평 분할/확장이 가능하고, 작업을 여러 샤드에서 수행하기 때문에(병렬화) 성능/처리량을 늘릴 수 있습니다.
샤드는 프라이머리 샤드(Primary Shard)와 레플리카 샤드(Replica Shard)로 구분된다.
- 프라이머리 샤드(Primary Shard) : 데이터의 원본. 엘라스틱서치에서 데이터 업데이트 요청을 날리면 반드시 프라이머리 샤드에 요청을 하게 되고 해당 내용은 레플리카에 복제됩니다. 검색 성능 향상을 위해 클러스터의 샤드 갯수를 조정하는 튜닝을 합니다.
- 레플리카 샤드(Replica Shard) : 프라이머리 샤드의 복제본. 기존 원본 데이터가 무너졌을 때 그 대신 쓰면서 장애 극복 역할을 수행함. 기본적으로 원본인 프라이머리 샤드와 동일한 노드에 배정되지 않음.
세그먼트(Segment)
세그먼트(Segment)란 엘라스틱서치에서 문서의 빠른 검색을 위해 설계된 자료구조입니다. 각 샤드는 다수의 세그먼트로 구성되어 있습니다.
엘라스틱서치에서 데이터(Document)를 저장하면, 엘라스틱서치는 이것을 메모리에 모아두고 새로운 세그먼트를 디스크에 기록하여 검색을 리프레쉬(refresh)합니다. 이로 인해 새로운 검색 가능한 세그먼트가 만들어집니다.
Elastic Search의 특징
분산/확장성/병렬처리
Elasticsearch 구성 시 보통 3개 이상의 노드(Elasticsearch 서버)를 클러스터로 구성하며, 데이터를 샤드(shard)로 저장 시 클러스터 내 다른 호스트에 복사본(replica)을 저장해 놓기 때문에 하나의 노드가 죽거나 샤드가 깨져도 복제되어 있는 다른 샤드를 활용하기 때문에 데이터의 안정성을 보장한다.
또한 데이터의 분산과 병렬처리가 되므로 실시간 검색 및 분석을 할 수 있고, 노드(Elasticsearch 서버)를 수평적으로 늘릴 수 있게 설계되어 있기 때문에 더 많은 용량이 필요한 경우 노드를 클러스터에 추가할 수 있다.
고가용성
Elasticsearch는 동작중에 죽은 노드를 감지하고 삭제하며 사용자의 데이터를 안전하고 접근 가능하도록 유지하기 때문에, 동작중에 일부 노드에 문제가 생기더라도 문제 없이 서비스를 제공한다.
멀티 테넌시
클러스터는 여러개의 인덱스(RDBMS의 데이터베이스와 비슷)들을 저장하고 관리하며, 하나의 쿼리나 그룹 쿼리로 여러 인덱스의 데이터를 검색할 수 있다.
문서(Document) 중심 & 스키마(Schema) 미존재
복잡한 현실 세계의 요소들을 구조화된 JSON 문서 형식으로 저장한다. 모든 필드는 기본적으로 인덱싱되며, 모든 인덱스들은 단일 쿼리로 빠르게 검색 및 활용할 수 있다.
또한 NoSQL나 RDBMS와 같은 스키마 개념이 없으며, 사용자의 데이터가 어떻게 인덱싱 될 것인지를 사용자가 커스터마이징 할 수 있다.
플러그인 형태로 구현
검색엔진을 직접 수행하지 않고, 필요한 기능에 대한 플러그인을 적용하여 기능을 확장할 수 있다. 예를 들면 외부에서 제공하는 형태소 분석기나 REST API를 구현하여 적용할 수 있다.
Elastic Search의 단점
- 진입 장벽이 높은 편입니다.
- 데이터간 조인을 수행할 수 없습니다.
- 트랜잭션 및 롤백이 제공되지 않습니다.
- 실시간 처리가 힘듭니다.(색인된 데이터가 1초 뒤에나 검색이 가능합니다.)
- 데이터의 수정을 지원하지 않습니다. (수정이라기 보다는 삭제후 다시 생성하는 형태입니다.)
'DB' 카테고리의 다른 글
MySQL 8 버전 특징 (0) | 2022.02.23 |
---|---|
Dinstinct와 Group by의 차이 (0) | 2021.05.03 |
SQL 작성 7거지악 (0) | 2021.04.01 |
MySQL Storage Engine (0) | 2020.11.25 |
DB Cluster (0) | 2020.11.20 |