NOSQL ( Elastic Search)
👀NoSQL 이란?
NoSQL은 "Not Only SQL"의 약자로, 관계형 데이터베이스 모델을 벗어나서 다양한 형태의 데이터를 저장하고 검색할 수 있는 데이터베이스를 가리킵니다.
- Key-Value Stores (키-값 저장소):
- 각 데이터 아이템은 고유한 키와 값의 쌍으로 저장됩니다.
- 예시: Redis, Amazon DynamoDB
- Document Stores (문서 저장소):
- 데이터를 문서 형식으로 저장합니다. 주로 JSON 또는 BSON 형태의 문서를 사용합니다.
- 예시: MongoDB, Couchbase, Elastic Search
- Column-Family Stores (열 패밀리 저장소):
- 키-값 저장소와 비슷하지만, 값이 여러 개의 열 패밀리로 구성됩니다. 각 열 패밀리는 열의 이름과 해당 값으로 구성됩니다.
- 예시: Apache Cassandra, HBase
- Graph Databases (그래프 데이터베이스):
- 데이터를 노드와 엣지의 그래프 형태로 저장합니다. 이러한 모델은 관계형 데이터베이스에서는 어려운 복잡한 관계를 쉽게 표현할 수 있습니다.
- 예시: Neo4j, Amazon Neptune
- Wide-Column Stores (와이드-열 저장소):
- 열 지향 데이터 모델을 기반으로 하며, 각 행은 다른 열 세트를 가질 수 있습니다.
- 예시: Apache Cassandra, ScyllaDB
해당 DB중 Elastic Search를 사용 할것임
( 기능을 이용하면 추후 시각화된 모니터링시스템을 만들수있지않을까?)
📌Elastic Search란 무엇인가
Elasticsearch는 Apache Lucene(아파치 루씬) 기반의 Java 오픈 소스 분산 검색 엔진이다. Elasticsearch를 통해 루씬 라이브러리(Java에서 개발한 정보 검색용 라이브러리)를 단독으로 사용할 수 있으며, 방대한 양의 데이터를 신속하게(거의 실시간) 저장, 검색, 분석을 수행할 수 있다.
📌Elastic Search 에서 사용하는 용어 기존 RDBMS와 비교
📌Elastic Search의 구조
⚓클러스터
클러스터란 Elasticsearch에서 가장 큰 시스템 단위를 의미하며, 최소 하나 이상의 노드로 이루어진 노드의 집합이다. 서로 다른 클러스터는 데이터의 접근, 교환을 할 수 없는 독립적인 시스템으로 유지되며, 여러 대의 서버가 하나의 클러스터를 구성할 수 있고 한 서버에 여러 개의 클러스터가 존재할 수 있다.
⚓노드
노드는 클러스터에 포함된 단일 서버로서 데이터를 저장하고 클러스터의 색인화 및 검색 기능에 참여한다. 노드는 역할에 따라 Master-eligible, Data, Ingest, Tribe 노드로 구분할 수 있다.
Master-eligible Node
클러스터를 제어하는 마스터로 선택할 수 있는 노드이다. 마스터 노드가 하는 역할을 다음과 같다.
- 인덱스 생성, 삭제
- 클러스터 노드의 추적, 관리
- 데이터 입력 시 할당할 샤드 선택
Data Node
데이터(Document)가 저장되는 노드이며, 데이터가 분산 저장되는 물리적 공간인 샤드가 배치되는 노드이다. CRUD, 색인, 검색, 통계 등의 데이터 작업을 수행하므로 많은 리소스(CPU, 메모리 등)를 필요로 한다. 따라서 모니터링 작업을 해야 하고, 마스터 노드와는 분리해야 한다.
Ingest Node
데이터를 변환하는 등 사전 처리 파이프라인을 실행하는 역할을 한다.
Coordination Only Node
사용자의 요청을 받고 라운드 로빈 방식으로 분산을 하는 노드이다. 클러스터에 관련된 것은 마스터 노드로 넘기고, 데이터와 관련된 것은 데이터 노드로 넘긴다. 로드밸런싱 역할을 하는 노드라고 생각하면 된다.
⚓인덱스
RDBMS의 데이터베이스와 대응하는 개념
⚓샤드
인덱스 내부에는 색인된 데이터들이 존재하는데 하나로 뭉쳐서 존재하는게 아닌 물리적 공간에 여러 부분으로 나뉘어 존재한다. 이런 부분을 샤드라고 한다. 스케일 아웃을 위해 하나의 인덱스를 여러 샤드로 쪼갯다고 생각하면 된다.
샤드는 프라이머리 샤드와 레플리카 샤드로 나뉜다.
- 프라이머리 샤드
- 데이터의 원본이다. Elasticsearch에서 데이터 업데이트 요청을 날리면 반드시 프라이머리 샤드에 요청하게 되고, 해당 내용은 레플리카 샤드에 복제된다. 검색 성능 향상을 위해 클러스터의 샤드 개수를 조정하기도 한다.
- 레플리카 샤드 (복제)
- 프라이머리 샤드의 복제본이다. 기존 원본 데이터가 무너졌을 때 그 대신 사용하면서 장애를 극복하는 역할을 수행한다. 기본적으로 원본인 프라이머리 샤드와 동일한 노드에 배정되지 않는다.
⚓세그먼트
세그먼트란 Elasticsearch에서 문서의 빠른 검색을 위해 설계된 자료 구조이며, 샤드의 데이터를 가지고 있는 물리적인 파일이다. 각 샤드는 다수의 세그먼트로 구성되어 있으므로 검색 요청을 분산 처리하여 훨씬 효율적인 검색이 가능하다.
샤드에서 검색 시, 먼저 각 세그먼트를 검색하여 결과를 조합한 후 최종 결과를 해당 샤드의 결과로 반환하게 된다. 이때 세그먼트는 내부에 색인된 데이터가 역색인 구조로 저장되어 있으므로 검색 속도가 매우 빠르다.
그런데, 매 요청마다 새로운 세그먼트를 만들어 주면 엄청나게 많은 세그먼트가 생성될 것이고, 이로 인해 다른 요청에 지장이 생길 수 있다. 이를 방지하기 위해 인메모리 버퍼를 사용한다. 인메모리 버퍼에 쌓인 내용을 일정 시간이 지나거나 버퍼가 가득차면 flush를 취하고, flush 작업이 수행되면 시스템 캐시에 세그먼트가 생성된다. 이 시점부터 데이터가 비로소 검색이 가능해진다. 하지만 이 상태는 세그먼트가 시스템 캐시에 저장된 상태이지, 디스크에 저장된 상태는 아니다.
디스크에 쓰여지는 작업 역시 일정 시간이 지나면 commit을 통해서 물리적인 디스크에 세그먼트를 저장해 주고, 저장된 세그먼트는 시간이 지날수록 하나로 병합하는 과정을 수행한다. 병합을 통해 세그먼트를 하나로 줄여 주면, 검색할 세그먼트의 개수가 줄어들기 때문에 검색 성능이 향상된다.
📌Elastic Search는 언제 사용하나?
Elasticsearch는 검색을 위해 단독으로 사용되기도 하며, ELK(Elasticsearch / Logstash / Kibana) 스택으로 사용되기도 한다.
- Logstash
- 다양한 소스(DB, csv 파일 등)의 로그 또는 트랜잭션 데이터를 수집, 집계, 파싱하여 Elasticsearch로 전달
- Elasticsearch
- Logstash로부터 받은 데이터를 검색 및 집계하여 필요한 정보를 획득
- Kibana
- Elasticsearch의 빠른 검색을 통해 데이터를 시각화 및 모니터링
📌ELK는 왜씀?
주로 ELK는 로드밸런싱되어 있는 WAS의 흩어져 있는 로그를 한 곳으로 모으고, 원하는 데이터를 빠르게 검색한 뒤 시각화하여 모니터링하기 위해 사용한다
📌무슨 장점이 있나?
- Scale out
- 샤드를 통해 규모가 수평적으로 늘어 날 수 있다.
- 고가용성
- Replica를 통해 데이터의 안정성 보장.
- Schema Free
- Json 문서를 통해 데이터 검색을 수행해서 스키마 개념이 없음.
- Restful
- 데이터 CRUD 작업은 Restful API를 통해 수행한다 ( 다양한 플랫폼에서 응용가능)
📌무슨 단점이 있나
- 실시간 처리 불가능
- 인메모리 버퍼를 사용하기 때문에 데이터가 생성된후 조회가능하게 될때까지 약1초정도 소요된다 ( 현프로젝트에 적용하기에는 문제가되지않을듯)
- 트랜잭션을 지원하지 않음
- 분산 시스템 구성 특징때문에 비용소모가 큰 트랙잭션 및 롤백을 지원하지않음
- 진정한 의미의 업데이트를 지원하지 않음
- 세그먼트에서 데이터가 삭제될 경우 Soft-Delete를 함 ( 삭제Flag = true )
- 세그먼트에서 데이터가 수정될 경우 Soft-Delete를 하고 수정된 데이터를 새로운 세그먼트로 생성함
