
기존의 회사 솔루션에 golang으로 만들어진 검색엔진이 처리하는 데이터가 많으면 느리다 라는 사용자의 요구사항으로 인해 ElasticSearch를 도입해보려고 함
1. 오픈소스 기반의 분산형 검색 및 분석 엔진
2. 텍스트 기반의 데이터를 빠르게 검색, 필터, 집계
3. 기본적으로 JSON 기반의 RESTful API로 동작
4. 내부적으로는 Apache Lucene을 사용
- Apache Lucene이란?
자바(Java)로 작성된 풀텍스트 검색 엔진 라이브러리
역색인(inverted index) 이라는 구조로 검색어 위치를 기억해서 매우 빠름
1. 검색창 자동완성
2. 로그 분석
3. 추천 시스템
1. Index (인덱스):
데이터가 저장되는 공간. RDBMS의 데이터베이스에 해당
2. Document (문서):
실제로 저장되는 JSON 형태의 단일 데이터 (RDB의 row)
3. Field (필드):
Document 안의 key (RDB의 column)
4. Mapping:
필드에 대한 스키마 정의
5. Inverted Index:
검색을 빠르게 하기 위한 구조. 단어 -> 문서 ID 매핑 구조
6. Cluster:
Elasticsearch 전체 시스템 단위. 하나 이상의 노드로 구성
7. Node:
Elasticsearch 인스턴스 1개 (보통 컨테이너 1개)
8. Shard:
인덱스를 물리적으로 분할한 단위. 실제 데이터를 저장
9. Primary Shard:
실제 데이터를 저장하는 주 샤드
10. Replica Shard:
Primary의 복제본. 장애 대비 및 읽기 처리
11. Routing:
어떤 문서를 어떤 샤드에 넣을지 결정하는 해싱 로직
12. text:
분석기를 거쳐 토큰화되어 저장됨. 자연어 검색에 적합
13. keyword:
전체 문자열을 그대로 저장. 정렬/집계/필터에 적합
14. fields:
한 필드를 text + keyword 같이 여러 타입으로 저장할 때 사용
15. doc_values:
keyword 등 집계/정렬용 필드의 내부 디스크 구조
[Cluster]
└─ [Node]
└─ [Shard] -> Primary / Replica
└─ [Index Data (partial)]
└─ [Document]
1. JSON 데이터를 Elasticsearch에 보내면 분석 -> 역색인 생성 -> 저장
-> Indexing
* 역색인(Inverted Index): "단어->문서 번호 목록" 으로 연결된 자료구조
2. 검색 요청 시 단어 분석 -> 색인에서 문서 찾기 -> 점수 계산 -> 결과 반환
-> Search
ex)
"삼성전자는 반도체를 개발한다."
1. 분석기(analyzer)가 단어 추출: -> ["삼성전자", "반도체", "개발"]
2. 역색인에 저장:
{
"삼성전자": [문서1],
"반도체": [문서1],
"개발": [문서1]
}
3. 사용자가 "반도체 개발" 검색
4. 검색어 분석 -> ["반도체", "개발"]
5. 기존에 만들어진 역색인에서 찾음:
반도체 -> 문서1, 문서5
개발 -> 문서1, 문서2
6. 공통 문서인 문서1을 우선적으로 반환
1. Elastic Search 는 RDBMS의 테이블 개념이 없는가?
- Elasticsearch는 스키마가 없는 문서 기반 저장소이기 때문에
RDB의 Table처럼 명확히 정의된 구조가 없고, Index 안에 바로 Document들이 있음.
ex)
PUT /blog_posts
{
"mappings": {
"properties": {
"title": { "type": "text" },
"content": { "type": "text" },
"author": { "type": "keyword" }
}
}
}
-> 이런식으로 각각의 JSON 문서가 RDB의 한 "row"에 해당