Elasticsearch

• 검색 엔진 (search engine) 은 웹에서 정보를 수집해 검색 결과를 제공하는 프로그램
  • 검색 엔진은 검색 결과로 제공되는 데이터의 특성에 따라 구현 형태가 각각 달라짐

• 검색 시스템 (search system) 은 대용량 데이터를 기반으로 신뢰성 있는 검색 결과를 제공하기 위해 검색 엔진을 기반으로 구축된 시스템을 통칭하는 용어
  • 수집기를 이용해 방대한 데이터를 수집하고 이를 다수의 검색 엔진을 이용해 색인하고 검색 결과를 UI로 제공
  • 시스템 내부의 정책에 따라 관련도가 높은 문서를 검색 결과의 상위에 배치할 수 있을 뿐더러 특정 필드나 문서에 가중치를 둬서 검색의 정확도를 높일 수 있음

• 검색 서비스 (search service) 는 검색 엔진을 기반으로 구축한 검색 시스템을 활용해 검색 결과를 서비스로 제공

• Elasticsearch 는 엄밀히 말하자면 검색 엔진이며 검색 서비스를 제공하기 위해 Elasticsearch 를 이용해 검색 시스템을 구축 할 수 있음

Elasticsearch 란?

• Elasticsearch 는 텍스트 ∙ 숫자 ∙ 위치 기반 정보 ∙ 정형 및 비정형 데이터 등 모든 유형의 데이터를 위한 무료 검색 및 분석 엔진

• Apache Lucene (아파치 루씬) 기반의 Java 오픈소스 분산 검색 엔진
• Elasticsearch 를 통해 Lucene 라이브러리를 단독으로 사용할 수 있게 되었으며 방대한 양의 데이터를 거의 실시간 (NRT: Near Real Time) 으로 저장 ∙ 검색 ∙ 분석할 수 있음
• Elasticsearch 는 검색을 위해 단독으로 사용되기도 하며 ELK Stack (Elasticsearch / Logstatsh / Kibana) 으로 사용되기도 함

Tip! ELK Stack이란?

• Logstash (로그스태시)
  다양한 소스 (DB ∙ CSV 파일 등) 의 로그 또는 트랜잭션 데이터를 수집 ∙ 집계 ∙ 파싱하여 Elasticsearch 로 전달
• Elasticsearch (엘라스틱서치)
  Logstash 로부터 받은 데이터를 검색 및 집계를 하여 필요한 관심 있는 정보를 획득
• Kibana (키바나)
  Elasticsearch 의 빠른 검색을 통해 데이터를 시각화 및 모니터링
  

Elasticsearch의 특징

오픈소스 (Open Source)

• Elasticsearch 의 핵심 기능들은 Apache 2.0 라이센스로 배포되고 있고 Elastic Stack 의 모든 제품들은 ( https://github.com/elastic ) 레포지토리에서 소스를 찾을 수 있음
• 6.3 버전 부터는 Elastic 라이센스와 Apache 라이센스가 섞여 있지만 각각의 버전에 대해 별도 배포판이 존재하고 라이센스 파일에서 어떤 경로의 파일들이 어떤 라이센스로 되어 있는지 확인이 가능
• 현재는 x-pack 디렉토리 아래 있는 파일들만이 Elastic 라이센스를 따르고 그 외의 파일들은 Apache 라이센스를 따름

• Lucene 이 Java 로 만들어졌기 때문에 Elasticsearch 도 마찬가지로 Java 로 코딩이 되어 있음
• Lucene 은 Hadoop (하둡) 을 개발한 Doug Cutting (더그 커팅) 에 의해 처음 만들어졌지만 Elasticsearch 엔지니어들 중에는 Lucene 커미터들이 다수 있어서 Lucene 을 매우 깊은 레벨에서 다루고 있음
  • Elastic 사의 Lucene 커미터인 개발자들이 실제로 Lucene 프로젝트의 절반 이상의 기능을 개발에 기여하고 있음

실시간 분석 (Real-Time)

• Elasticsearch 의 가장 큰 특징 중 하나는 실시간 (real-time) 분석 시스템
• 현재 대용량 데이터 분석에 가장 널리 사용되고 있는 것은 Hadoop 플랫폼 위에서 실행되는 Pig ∙ Hive와 같은 다양한 Map Reducer (맵 리듀서)
• Hadoop 은 기본적으로 배치 기반의 분석 시스템으로 분석에 사용될 소스 데이터 ∙ 분석을 수행 할 프로그램을 올려 놓고 분석을 실행하여 결과 셋이 나오도록 하는 하나의 루틴으로 실행

• Elasticsearch 는 Hadoop 시스템과 달리 Elasticsearch 클러스터가 실행되고 있는 동안에는 계속해서 데이터가 입력 (검색 엔진에서는 색인: 인덱싱 indexing 이라고 표현) 되고 그와 동시에 실시간에 가까운 (NRT: Near Real Time) 속도로 색인된 데이터의 검색 ∙ 집계가 가능

Tip! 맵 리듀서 (Map reducer) 란?
거대한 인풋 데이터를 쪼개어 수많은 머신들에게 분산시켜서 로직을 수행한 다음 결과를 하나로 합치자는 것이 핵심 아이디어

• Map Reduce 진행 순서
  • 쪼개기 (Split): 크기가 큰 인풋 파일을 작은 단위의 청크들로 나누어 분산 파일 시스템 (예시: HDFS) 에 저장
  • 데이터 처리하기 (Map): 잘게 쪼개어진 파일을 인풋으로 받아서 데이터를 분석하는 로직을 수행
  • 처리된 데이터 합치기 (Reduce): 처리된 데이터를 다시 합침

전문 (Full Text) 검색 엔진

• Lucene 은 기본적으로 Inverted File Index (역파일 색인) 라는 구조로 데이터를 저장
• Lucene 을 사용하고 있는 Elasticsearch 도 마찬가지로 색인된 모든 데이터를 역파일 색인 구조로 저장하여 가공된 텍스트를 검색
  • 이런 특성을 전문 (full text) 검색이라고 함

• JSON 문서 기반 Elasticsearch 는 내부적으로는 역파일 색인 구조로 데이터를 저장하고 있으나 사용자의 관점에서는 JSON 형식으로 데이터를 전달
• JSON 형식은 간결하고 개발자들이 다루기 편한 구조로 되어 있어 색인 할 대상 문서를 가공 하거나 다른 클라이언트 프로그램과 연동하기에 용이

• 또한 key-value 형식이 아닌 문서 기반으로 되어 있기에 복합적인 정보를 포함하는 형식의 문서를 있는 그대로 저장이 가능하며 사용자가 직관적으로 이해하고 사용할 수 있음
• Elasticsearch 에서 질의에 사용되는 쿼리문이나 쿼리에 대한 결과도 모두 JSON 형식으로 전달되고 반환

• 다만 JSON이 Elasticsearch 가 지원하는 유일한 형식이기 때문에 사전에 입력할 데이터를 JSON 형식으로 가공하는 것이 필요
• CSV ∙ Apache log ∙ Syslog 등과 같이 널리 사용되는 형식들은 Logstash 에서 변환을 지원하고 있음

RESTFul API

• 현재 대규모 시스템들은 대부분 MSA (마이크로 서비스 아키텍처) 를 기본으로 설계
  • 이러한 구조에 빠질 수 없는 것이 REST API 와 같은 표준 인터페이스
• Elasticsearch 는 Rest API 를 기본으로 지원하며 모든 데이터 조회 ∙ 입력 ∙ 삭제를 HTTP 프로토콜을 통해 Rest API 로 처리

Tip!

• Elasticsearch 는 기본적으로 HTTP 를 통해 JSON 형식의 RESTful API 를 이용
  • Elasticsearch 는 Java 로 개발됐지만 여러 가지 프로그래밍 언어를 통해 활용할 수도 있음

• Elasticsearch 를 사용하기 위한 API 요청 구조
  • curl -X(메서드) http://host:port/(인덱스)/(타입)/(문서 id) -d '{json 데이터}'

• Elasticsearch 는 관계형 데이터베이스 검색보다 훨씬 유연
  • 역색인되는 문자열 전체를 정책에 따라 소문자 혹은 대문자로 생성하고 쿼리가 들어오는 필터를 색인 시간과 검색 시간에 동일하게 지정한다면 해당 쿼리는 어떠한 문자열 (대소문자 구분 없음) 이 들어와도 검색이 가능
  • 또한 Elasticsearch 는 구조화되지 않은 비정형 데이터도 검색이 가능
  • 데이터베이스는 스키마를 미리 정의해야만 데이터 저장과 조회가 가능한 반면 Elasticsearch 는 구조화되지 않은 데이터까지 스스로 분석해 자동으로 필드를 생성하고 저장

• Elasticsearch 는 NoSQL의 일종으로서 분류가 가능하고 분산 처리를 통해 실시간에 준하는 빠른 검색이 가능
  • 기존 데이터베이스로는 처리하기 어려운 대량의 비정형 데이터도 검색할 수 있으며 전문 검색 (Full Text) 과 구조 검색 모두를 지원

멀티테넌시 (Multitenancy)

• Elasticsearch 의 데이터들은 인덱스 (Index) 라는 논리적인 집합 단위로 구성되며 서로 다른 저장소에 분산되어 저장
• 서로 다른 인덱스들을 별도의 커넥션 없이 하나의 질의로 묶어서 검색하고 검색 결과들을 하나의 출력으로 도출할 수 있는데 Elasticsearch 의 이러한 특징을 멀티테넌시 라고 함

Tip! 추가 내용

검색 시스템의 구성요소

• 검색 시스템의 기본 구조는 일반적으로 정보를 수집하는 수집기 ∙ 수집한 데이터를 저장하는 스토리지 ∙ 수집한 데이터를 검색에 적절한 형태로 변환하는 색인기 ∙ 색인된 데이터에서 일치하는 문서를 찾는 검색기로 구성

수집기

• 수집기는 웹사이트 ∙ 블로그 ∙ 카페 등 웹에서 필요한 정보를 수집하는 프로그램
  • 크롤러 (Crawler) ∙ 스파이더 (Spider) ∙ 웜 (Worms) ∙ 웹로봇 (Web Robot) 등으로 불림
  • 파일 ∙ 데이터베이스 ∙ 웹페이지 등 웹 상의 대부분의 정보가 수집 대상

스토리지

• 데이터베이스에서 데이터를 저장하는 물리적인 저장소
  • 검색 엔진은 색인한 데이터를 스토리지에 보관

색인기

• 검색 엔진이 수집한 정보에서 사용자 질의와 일치하는 정보를 찾으려면 수집된 데이터를 검색 가능한 구조로 가공하고 저장해야 함
  • 그 역할을 하는 것이 색인기
  • 색인기는 다양한 형태소 분석기를 조합해 정보에서 의미가 있는 용어를 추출하고 검색에 유리한 역색인 구조로 데이터를 저장

검색기

• 검색기는 사용자 질의를 입력받아 색인기에서 저장한 역색인 구조에서 일치하는 문서를 찾아 결과로 반환
  • 질의와 문서가 일치하는지는 유사도 기반의 검색 순위 알고리즘으로 판단하는데 검색기 또한 색인기와 마찬가지로 형태소 분석기를 이용해 사용자 질의에서 유의미한 용어를 추출해 검색
  • 따라서 사용하는 형태소 분석기에 따라 검색 품질이 달라짐

• 관계형 데이터베이스는 SQL 문을 이용해 원하는 정보의 검색이 가능한데 텍스트 매칭을 통한 단순한 검색만 가능
  • 텍스트를 여러 단어로 변형하거나 여러 개의 동의어나 유의어를 활용한 검색은 불가능

• 반면 검색 엔진은 데이터베이스에서는 불가능한 비정형 데이터를 색인하고 검색할 수 있음
  • 형태소 분석을 통해 사람이 구사하는 자연어의 처리가 가능해지고 역색인 구조를 바탕으로 빠른 검색 속도를 보장

기본 용어

• Elasticsearch 의 데이터는 다음과 같이 인덱스 ∙ 타입 ∙ 문서 ∙ 필드 구조로 구성

인덱스 (Index)

• 인덱스 (Index) 는 데이터 저장 공간
  • 하나의 인덱스는 하나의 타입만 가지며 하나의 물리적인 노드에 여러 개의 논리적인 인덱스를 생성할 수 있음
  • 검색 시 인덱스 이름으로 문서 데이터를 검색하며 여러 개의 인덱스를 동시에 검색하는 것도 가능

• Elasticsearch 를 분산 환경으로 구성하면 하나의 인덱스가 여러 노드에 분산 저장되어 관리됨에 따라 분산 처리에 따른 여러 이점을 누릴 수 있음
  • Elasticsearch 는 인덱스 생성시 기본적으로 5개의 프라이머리 (Primary) 샤드와 1개의 레플리카 (Replica) 샤드 세트를 생성
  • 각각의 샤드 수는 인덱스를 생성할 때 옵션을 이용해 변경할 수 있음

• 인덱스의 이름은 모두 소문자여야 하며 추가 ∙ 수정 ∙ 삭제 ∙ 검색은 RESTful API 로 수행할 수 있음
  • 만약 인덱스가 없는 상태에서 데이터가 추가된다면 데이터를 이용해 인덱스가 자동으로 생성됨

샤드 (Shard)

• 색인된 문서는 하나의 인덱스에 담김
  • 인덱스 내부에 색인된 데이터는 물리적인 공간에 여러 개의 파티션으로 나뉘어 구성되는데 이 파티션을 Elasticsearch 에서는 샤드 (Shard) 라고 부름
  • Elasticsearch 는 다수의 샤드로 문서를 분산 저장하고 있어 데이터 손실 위험을 최소화할 수 있음

타입 (Type)

• 타입 (Type) 은 인덱스의 논리적 구조를 의미하며 인덱스 속성에 따라 분류하기도 함
  • Elasticsearch 6.0 버전 이하에서는 하나의 인덱스에 여러 타입 설정이 가능했지만 6.1 버전부터는 인덱스당 하나의 타입만 사용할 수 있음

• Elasticsearch 6.0 이하 버전에서는 특정 카테고리를 분류하는 목적으로 타입이 많이 사용되었음
  • 예를 들어 music 이라는 인덱스가 존재한다면 장르별 (Rock ∙ K-pop ∙ Classic) 로 분리해 사용했으나 현재는 타입을 사용하는 것을 권장하지 않기 때문에 장르 별로 별도의 인덱스를 각각 생성해서 사용해야 함

문서 (Document)

• 문서 (Document) 는 Elasticsearch 에서 데이터가 저장되는 최소 단위
  • 기본적으로 JSON 포맷으로 데이터가 저장
  • 데이터베이스와 비교하자면 테이블의 행이 Elasticsearch 의 문서에 해당한다고 볼 수 있음
  • 하나의 문서는 다수의 필드로 구성돼 있는데 각 필드는 데이터의 형태에 따라 용도에 맞는 데이터 타입 (Data Type) 을 정의해야 하며 문서는 중첩 구조를 지원하기 때문에 이를 이용해 문서 안에 문서를 지정하는 것도 가능

필드 (Field)

• 필드 (Field) 는 문서를 구성하기 위한 속성이라고 할 수 있음
  • 일반적으로 데이터베이스의 칼럼 (Column) 과 비교할 수 있으나 컬럼이 정적 (static) 인 데이터 타입인 데 반해 필드는 좀 더 동적 (dynamic) 인 데이터 타입이라고 할 수 있음

• 하나의 필드는 목적에 따라 다수의 데이터 타입을 가질 수 있음
  • 영화 정보를 담아둔 문서에 제목 필드가 있다고 가정했을 때 영화 제목을 검색할때 매칭 검색을 하거나 초성을 이용한 검색이 모두 지원되도록 제목 필드는 2개의 데이터 타입을 가져야 함

매핑 (Mapping)

• 매핑 (Mapping) 은 문서의 필드와 필드의 속성을 정의하고 그에 따른 색인 방법을 정의하는 프로세스
  • 인덱스의 매핑 정보에는 여러 가지 데이터 타입을 지정할 수 있지만 필드명은 중복해서 사용할 수 없음

기본 구성

• 클러스터는 물리적인 노드 인스턴스들의 모임
  • 클러스터는 모든 노드의 검색과 색인 작업을 관장하는 논리적인 개념이라 할 수 있음
  • 관계형 데이터베이스의 경우 모든 요청을 서버 하나에서 처리해서 결과를 제공하지만 Elasticsearch 의 경우에는 다수의 서버로 분산해서 처리하는 것이 가능하기 때문에 대용량 데이터를 처리할 수 있음

• 분산 처리를 위해서는 다양한 형태의 노드들을 조합해서 클러스터를 구성해야 함
  • 기본적으로 마스터 노드가 전체적인 클러스터를 관리하고 데이터 노드가 실제 데이터를 관리
  • Elasticsearch 는 각 설정에 따라 4가지 유형의 노드를 제공하는데 설정에 따라 각 노드는 한가지 유형으로 동작할 수도 있고 여러 개의 유형을 겸해서 동작할 수도 있음

마스터 노드 (Master Node)

• 마스터 노드는 인덱스를 생성 ∙ 삭제하는 등 클러스터와 관련된 전반적인 작업을 담당
  • 따라서 네트워크 속도가 빠르고 지연이 없는 노드를 마스터 노드로 선정해야 함
  • 다수의 노드를 마스터 노드로 설정할 수 있지만 결과적으로 하나의 노드만이 마스터 노드로 선출되어 동작함

• 만약 노드를 마스터 노드 전용으로 설정하고자 한다면 Elasticsearch 서버의 conf 폴더 안의 elasticsearch.yml 파일을 열고 다음과 같이 설정하면 됨

node.master: true
node.data: false
node.ingest: false
search.remote.connect: false

데이터 노드 (Data Node)

• 데이터 노드는 문서가 실제로 저장되는 노드
  • 데이터가 실제로 분산 저장되는 물리적 공간인 샤드가 배치되는 노드이기도 함
  • 색인 작업은 CPU ∙ 메모리 ∙ 스토리지 같은 컴퓨팅 리소스를 많이 소모하기 때문에 리소스 모니터링이 필요

• 데이터 노드는 가능한 한 마스터 노드와 분리해서 구성하는게 좋음
  • 단, 색인할 문서의 수가 적으면 함께 구성해도 상관은 없음
  • elasticsearch.yml 파일을 다음과 같이 수정하면 데이터 노드 전용으로 설정할 수 있음

node.mster: false
node.data: true
node.ingest: false
search.remote.connect: false

코디네이팅 노드 (Coordinating Node)

• 데이터 노드 ∙ 마스터 노드 ∙ 인제스트 노드의 역할을 하지 않고 들어온 요청을 단순히 라운드로빈 방식으로 분산시켜주는 노드
  • 구성 방법은 아래와 같음

node.master: false
node.data: false
node.ingest: false
search.remote.connect: false

인제스트 노드 (Ingest Node)

• 색인에 앞서 데이터를 전처리하기 위한 노드
  • 데이터의 포맷을 변경하기 위해 스크립트로 전처리 파이프라인을 구성하고 실행할 수 있음
  • 구성 방법은 다음과 같음

node.master: false
node.data: false
node.ingest: true
search.remote.connect: false

클러스터 ∙ 노드 ∙ 샤드

• Elasticsearch 클러스터는 인덱스의 문서를 조회할 때 마스터 노드를 통해 2개의 노드를 모두 조회해서 각 데이터를 취합한 후 결과를 하나로 합쳐서 제공

• 여러 개의 클러스터를 연결해서 구성할 수도 있으며 이때는 클러스터의 이름으로 각각을 구분
  • 만약 클러스터의 이름이 명시적으로 설정되지 않았다면 Elasticsearch 는 클러스터의 이름을 임의의 문자열로 지정
  • 또한 클러스터에 있는 노드는 실시간으로 추가 ∙ 제거가 가능하기 때문에 가용성이나 확장성 측면에서 매우 유연

• Elasticsearch 는 장애시 레플리카 샤드를 이용해 샤드를 복구
  • 장애가 발생하면 마스터 노드는 데이터를 재분배하거나 레플리카 샤드를 프라이머리 샤드로 승격시켜 서비스 중단 없는 복구가 가능
  • 따라서 장애극복 (Failover) 상황을 염두에 두고 노드와 샤드의 수를 적절히 구성해야 함

Elasticsearch 에서 제공하는 주요 API

• Elasticsearch 는 RESTful 방식의 API를 제공하며 이를 통해 JSON 기반으로 통신
  • Elasticsearch 는 기본적으로 HTTP 통신을 위해 9200번 포트를 사용
    • 인덱스 관리 API (Indices API): 인덱스 관리
    • 문서 관리 API (Document API): 문서의 추가 ∙ 수정 ∙ 삭제
    • 검색 API (Search API): 문서 조회
    • 집계 API (Aggregation API): 문서 통계

• 문서를 색인하기 위해서는 기본적으로 인덱스를 생성해야 함
  • 인덱스를 통해 입력되는 문서의 필드를 정의하고 각 필드에 알맞은 데이터 타입을 지정할 수 있음
  • 이러한 과정을 통해 좀더 효율적인 색인이 가능해짐

Index vs Indices

• 색인은 데이터가 토큰화되어 저장되는 자료 구조를 의미하며 Index 라는 단어를 번역한 것
  • 하지만 Elasticsearch 에서는 인덱스라는 용어를 색인과는 다른 의미로 사용
  • Elasticsearch 에서는 용어에 따른 혼란을 방지하기 위해 색인을 의미할 경우 Index 라는 단어를 사용하고 매핑 정의 공간을 의미할 경우 Indices 라는 단어로 표현
    • Index: 색인 데이터
    • Indexing: 색인하는 과정
    • Indices: 매핑 정보를 저장하는 논리적인 데이터 공간

• Elasticsearch 는 사용 편의성을 위해 스키마리스 (Schemaless) 라는 기능을 제공
  • 문서를 색인하기 위해서는 기본적으로 인덱스를 생성하는 과정이 필요한데 인덱스를 생성하는 과정 없이 문서를 추가하더라도 문서가 색인되도록 지원하는 일종의 편의 기능
  • Elasticsearch 는 최초 문서가 색인될때 인덱스의 존재 여부를 확인하고 만약 인덱스가 존재하지 않는다면 문서를 분석해서 문서가 색인될 수 있게 인덱스를 자동으로 생성

스키마리스 기능은 가급적이면 사용하지 않는다

• 스키마리스 기능을 이용하면 다양한 형태의 비정형 데이터를 하나의 인덱스로 구성할 수 있지만 이는 성능과 밀접한 연관이 있기 때문에 특수한 상황에서만 사용해야 함
  • 만약 스키마리스를 사용해야 한다면 데이터 구조 및 검색 방식을 확실히 이해해야 함

• 인덱스가 자동으로 생성되면 세부적인 필드 정보가 매핑되지 않음
  • 이런 식으로 인덱스를 자동 생성할 경우 특정 단어를 검색할 때 검색 결과에서 누락되는 등 문제가 발생할 가능성이 높아짐

• 기본적으로 모든 필드가 text 타입과 keyword 타입을 동시에 제공하는 멀티필드 기능으로 구성됨
  • 하지만 특정 필드는 text 타입만 필요할 수도 있고 keyword 타입만 필요할 수도 있는데 이러한 경우 데이터 공간의 낭비를 초래함

• Elasticsearch 는 스키마리스라는 특성에 따라 데이터에 대한 매핑을 자동으로 생성하는 편리한 기능을 제공하지만 이 기능은 특수한 상황에서만 제한적으로 사용해야 함
  • 사실상 실무에서는 대부분 사용하지 않음
  • 실무에서는 데이터가 대부분 복잡한 구조를 갖기 때문에 자칫 검색 품질이 떨어지거나 성능상 문제가 발생할 가능성이 커지기 때문

• 예를 들어 "아버지가 방에 들어 가신다" 와 같은 문장을 색인한다고 가정했을 때
  • 스키마리스를 이용해 색인한다면 기본적으로 text 타입의 Standard Analyzer 를 사용하는 데이터 타입이 정의될 것
  • 이러한 경우 해당 분석기는 "아버지가" ∙ "방에" ∙ "들어" ∙ "가신다"라는 토큰으로 분리되어 텀 (Term) 이 생성되고 검색 시 "아버지"라는 키워드가 입력되더라도 해당 문서는 검색되지 않을 것
  • 검색을 위해서는 Standard Analyzer 가 분리한 토큰 그대로 "아버지가"라는 키워드를 입력해야만 함

• 원하는 결과를 얻기 위해서는 한글 형태소를 분석하는 분석기를 사용하도록 데이터 타입을 직접 정의해야 함
  • 원하는 결과를 얻기 위해서라도 스키마리스 방식의 사용을 지양하고 반드시 인덱스를 직접 정의해서 사용하는 습관을 들이는 것이 좋음

• 스키마리스 기능을 사용하고 싶지 않더라도 인덱스를 설정하지 않고 실수로 데이터를 색인하면 Elasticsearch 는 인덱스를 자동으로 생성
  • 이는 자칫 시스템의 안정성을 해칠 수도 있음
  • 이러한 실수를 방지하기 위해 스키마리스 기능을 명시적으로 사용하지 않도록 설정하는 것이 가능

• 노드 설정 파일에서 action.auto_create_index 를 false 로 설정할 경우 자동으로 인덱스가 생성되지 않음
  • 또는 인덱스 별로 제공되는 index.maapper.dynamic 설정을 false 로 설정하면 특정 칼럼의 자동 매핑 생성을 비활성화할 수 있음

인덱스 관리 API

• 인덱스 관리 API 는 인덱스를 관리하기 위한 API
  • 이를 이용해 인덱스를 추가하거나 삭제할 수 있는데 인덱스 관리 API 는 HTTP 메서드를 지정하는 방식을 통해 사용할 수 있음
  • 인덱스를 생성할때는 매핑이라는 세부 설정을 이용할 수 있는데 매핑은 문서와 문서에 포함된 필드 ∙ 필드 타입 등을 세세하게 지정하는 것이 가능한 설정 방식
  • 인덱스 생성 시 이러한 매핑 정보를 추가할 수 있는데 한가지 주의할 점은 한번 생성된 매핑 정보는 변경할 수 없다는 점
  • 만약 잘못 생성했거나 변경해야 하는 경우에는 데이터를 삭제하고 다시 색인하는 수 밖에 없음

• Elasticsearch 에서는 다양한 형태의 데이터 타입을 제공
  • 단순히 문자열로 저장하고 싶을 경우 keyword 타입을 사용하면 되고 형태소 분석을 원할 경우 text 타입을 사용
  • 예를 들어 매핑 설정으로 정의된 필드 중 한글 영화 이름 (movieNm) 과 영문 영화 이름 (moviceNmEn) 은 검색에 사용되기 때문에 형태소 분석이 가능하도록 text 로 타입을 지정
  • 영화 코드 (movieCd) 와 제작연도 (prdtYear) 는 숫자 데이터 타입으로 지정하고 개봉일 (openDt) 은 날짜 타입으로 지정
  • 그 밖의 필드 타입은 모두 keyword 타입

• 인덱스를 한번 삭제하면 다시는 복구할 수 없기 때문에 인덱스 삭제는 신중하게해야 함

문서 관리 API

• 문서 관리 API 는 실제 문서를 색인 ∙ 조회 ∙ 수정 ∙ 삭제를 지원하는 API
  • Elasticsearch 는 기본적으로 검색 엔진이기 때문에 검색을 위해 다양한 검색 패턴을 지원하는 Search API 를 별도로 제공
  • 하지만 색인된 문서의 ID를 기준으로 한 건의 문서를 다뤄야 하는 경우 문서 관리 API 를 사용

• 문서 관리 API는 다음과 같은 세부 기능을 제공
  • Index API: 한 건의 문서를 색인
  • Get API: 한 건의 문서를 조회
  • Delete API: 한 건의 문서를 삭제
  • Update API: 한 건의 문서를 업데이트

• 문서 관리 API 는 기본적으로 한 건의 문서를 처리하기 위한 기능을 제공하며 Single document API 라고도 부름
  • 하지만 클러스터를 운영하다 보면 다수의 문서를 처리해야 하는 경우도 종종 발생하는데 이러한 경우에 대비해 Multi-document API 도 제공
  • Multi Get API: 다수의 문서를 조회
  • Bulk API: 대량의 문서를 색인
  • Delete By Query API: 다수의 문서를 삭제
  • Update By Query API: 다수의 문서를 업데이트
  • Reindex API: 인덱스의 문서를 다시 색인

ID를 지정하지 않고 문서를 생성

• _id 값을 직접 지정하지 않고 URI에 인덱스명과 타입만 지정한다면 Elasticsearch 가 자동으로 _id 값을 생성하게 됨
  • 이때 _id 값은 UUID 를 통해 무작위로 생성됨

• 이러한 방식이 자칫 편리해 보일 수도 있지만 무작위로 생성된 Id 값 때문에 해당 문서를 업데이트 할 때 문제 사항이 생길 수 있음
  • 예를 들어 Elasticsearch 와 동기화된 데이터베이스의 데이터가 변경됐다고 가정했을 때
    • 검색 엔진은 해당 데이터베이스와 주기적으로 동기화해야 하기 때문에 변경된 내용을 따라 동기화돼야 할 것
  • 이를 위해서는 Elasticsearch 에 색인된 _id 값을 데이터베이스의 PK (Primary Key) 혹은 식별이 되는 키 값과 매칭한 정보가 어딘가에는 저장되어 관리돼야 함
  • 하지만 1천만 건이나 1억건 정도 되는 데이터에 해당 식별 값을 어딘가에 별도로 저장한다는 것은 거의 불가능
  • 그래서 색인된 문서의 _id 값은 업데이트를 고려해서 데이터베이스 테이블의 식별 값과 맞춰 주는 것이 중요

검색 API

• Elasticsearch 검색 API 의 사용 방식은 다음과 같이 크게 두 가지로 나뉨
  • HTTP URI (Uniform Resource Identifier) 형태의 파라미터를 URI 에 추가해 검색하는 방법
  • RESTful API 방식인 QueryDSL 을 사용해 요청 본문 (Request Body) 에 질의 내용을 추가해 검색하는 방법

• Request Body 방식은 URI 방식보다 제약사항이 적기 때문에 현업에서는 Request Body 방식을 선호
  • URI 방식은 간단한 쿼리 검색을 하거나 디버깅할 때 간편하게 사용하는 경우에 종종 이용

• 간단한 표현식이라면 두가지 형식을 섞어서 사용하는 것도 가능
  • 예를 들어 Query 를 URI 방식으로 사용하고 나머지 기능을 JSON 형태로 사용해도 됨

GET /movice/_doc/_search?q=prdtYear:2017&pretty=true
{
    "sort": {
        "movieCd": {
            "order" : "asc"
        }
    }
}

• QueryDSL 을 사용하면 가독성이 높고 JSON 형식으로 다양한 표현이 가능
  • Query 의 조건을 여러 개 만들거나 통계를 위한 집계 (Aggregation) 쿼리 등 복잡한 쿼리를 작성하려면 QueryDSL 을 사용하는 것이 좋음
  • URI로 여러 단계의 구조를 가지는 중첩된 형태 표현하는 것은 불가능하기 때문

URI 방식의 검색 질의

• 먼저 살펴볼 URI 방식의 검색 질의는 문서 ID인 _id 값을 사용해 문서를 조회하는 방식
  • 결국 URL에 파라미터를 붙여 조회하는 식
  • 다음은 q 파라미터를 사용해 해당 용어와 일치하는 문서만 조회함

POST /movie/_search?q=장편

• 응답 결과를 확인하면 JSON 포맷 헤더에는 쿼리가 실행된 총 시간 (took) 과 결과를 보여줌
  • _shards 에서는 성공적으로 반환한 샤드의 수와 실패한 샤드의 수를 알 수 있음
  • hits 에서는 일치하는 문서의 수와 함께 점수 (_score) 가 가장 높은 상위 10개의 문서를 보여줌
  • 검색에 실패한 샤드의 수는 검색시 설정된 time_out 에 따라 결정됨
  • time_out 시간이 초과되면 그때까지 검색된 내용까지만 검색 결과로 반환되기 때문에 실패한 샤드의 수가 지나치게 많다면 time_out 시간을 적절히 조정해야 함

• q 파라미터를 사용할때 별도의 필드명을 지정하지 않으면 존재하는 모든 필드를 대상으로 검색을 수행함
  • 특정 필드만 조회하고 싶다면 다음 코드와 같이 필드명을 포함해서 요청하면 됨
  • 다음은 typeNm 필드의 값이 "장편"인 문자열만 검색한 예

POST /movie/_search?q=typeNm:장편

Request Body 방식의 검색 질의

• URI 검색 질의는 여러 필드를 각기 다른 검색어로 질의하는 것이 어려움
  • 쿼리의 조건이 복잡하고 길어지기 때문인데 이럴 때는 JSON 방식으로 질의하는게 좋음
  • JSON 포맷을 이용해 RESTful 방식으로 질의하면 매우 복잡한 쿼리도 쉽게 표현할 수 있고 여러 조건을 한번에 처리할 수 있음

POST /{index명}/_search
{
  JSON 쿼리 구문
}

• movie 인덱스의 typeNm 필드를 검색하는 예는 다음과 같음

POST movie/_search
{
  "query": {
    "term": {"typeNm": "장편"}
  }
}

• 쿼리 구문은 다음과 같이 여러 개의 키를 조합해 객체의 키 값으로 사용할 수 있음

{
   size: 
     # 몇개의 결과를 반환할지 결정한다(기본값은 10)
   
   from: 
     # 어느 위치부터 반환할지를 결정한다
     # 0부터 시작하면 상위 0~10건의 데이터를 반환한다(기본값은 0)
   
   _source: 
     # 특정 필드만 결과로 반환하고 싶을때 사용한다.
   
   sort: 
     # 특정 필드를 기준으로 정렬한다.
     # asc, desc의 오름차순, 내림차순 정렬을 지정할 수도 있다.
   
   query: {
     # 검색될 조건을 정의한다. 
   }
   
   filter: {
     # 검색 결과 중 특정한 값을 다시 보여준다.
     # 결과 내에서 재검색할 때 사용하는 기능 중 하나이다.
     # 다만 필터를 사용하게 되면 자동으로 score 값이 정렬되지 않는다.
   }
}

집계 API

• 과거에는 통계 작업을 위해 Lucene 이 제공하는 패싯 (Facets) 기능을 많이 활용했음
  • 패싯 기능은 기본적으로 디스크 기반으로 동작했고 분산 환경에는 최적화되지 않았기 때문에 대용량 데이터의 통계 작업에는 적합하지 않음
  • 이로 인해 많은 장애가 발생했기 때문

• Elasticsearch 에서는 5.0 이후에 패싯 방식의 통계 기능을 제거하고 독자적인 집계 (Aggregation) API를 내놓았음
  • 집계 API는 기본적으로 메모리 기반으로 동작하기 때문에 대용량의 데이터 통계 작업이 가능해졌음

• Elasticsearch 는 집계 API를 통해 기존의 패싯 API로는 하기 어려운 작업을 처리하는 것이 가능해졌음
  • 쿼리에 사용되는 집계에 따라 수치를 계산하고 동적으로 카운팅하거나 히스토그램 같은 작업 등도 할수 있음
  • Elasticsearch 의 집계 API는 각종 통계 데이터를 실시간으로 제공할 수 있는 강력한 기능

데이터 집계

• 예를 들어 movie 인덱스의 문서를 장르별로 집계할 때
  • _search API 를 사용해 집계 쿼리를 만들고 terms 키워드를 이용해 genreAlt 라는 필드의 데이터를 그룹화

POST /movie/_search?size=0
{
  "aggs": {
    "genre": {
      "terms": {
        "field": "genreAlt"
      }
    }
  }
}

• 집계 결과를 살펴보면 버킷 (Buckets) 이라는 구조 안에 그룹화된 데이터가 포함돼 있음
  • Elasticsearch 의 집계가 강력한 이유 중 하나는 버킷 안에 다른 버킷의 결과를 추가할 수 있다는 점인데 이러한 특성을 이용해 다양한 집계 유형을 결합하거나 중첩 ∙ 조합하는 것이 가능해짐

• 다음은 장르별 국가 형태를 중첩해서 보여주는 집계의 예

POST movie/_search?size=0
{
   "aggs": {
      "genre": {"terms": {"field": "genreAlt"}},
      "aggs": {
         "nation": {"terms": {"field": "nationAlt"}}
      }
   }
}

Tip! 추가 내용

검색 속도 빠른 이유

• MySQL과 같은 관계형 데이터베이스에서 테이블이 인덱싱 (색인 작업) 되면 복잡한 쿼리에서 훨씬 더 나은 성능을 보여줌
  • 인덱싱은 빠른 검색을 위해 필드 값을 열이나 Document에 매핑 하는 것을 의미

• 주어진 검색어에 대해서 모든 열을 찾아보는 대신에 인덱스 (색인) 를 이용해서 어떤 문서나 열에 해당되는지 찾을 수 있음
  • 이것이 인덱스가 쿼리 속도를 엄청나게 빠르게 만드는 이유

• Elasticsearch 는 (검색어가 될 수 있는) 문자들을 유연하게 토큰화하고 인덱싱하는데 특화되어 있음
  • 예를 들어 "Hello to the world" 라는 하나의 문자열을 다양한 방법으로 인덱싱을 진행 할 수 있음
    • 문장 전체
      • 예시: ["Hello to the world"]
    • 단어
      • 예시: ["hello", "to", "the", "world"]
    • 전치사나 관사 등을 제외한 의미 있는 단어
      • 예시: ["hello", "world"]
    • 사용자가 원하는 규칙
      • "to" 라는 전치사를 중요하게 생각한다면 추가 가능
      • 예시: ["hello", "to", "world"]
  • 이렇게 토큰화된 단어들이 인덱스 키가 되어 훨씬 빠르고 효율적인 문서 검색을 진행

• 위의 사진을 보면 어떤 방식으로 문자열 또는 Document 가 단어 별로 인덱싱되어 저장되는지 알 수 있음
  • 관사나 전치사 등을 제외한 유의미한 키워드들을 추려내고 각 키워드가 어떤 Document 에 저장되어 있는지 저장
  • 인덱싱 이후 "best" 라는 키워드로 검색을 진행하면 Document 2에서 best 라는 키워드가 사용되었음을 바로 찾을 수 있음
    • 만약 이를 선형 검색으로 진행한다면 Document 1, Document 2, Document 3에 모든 단어들을 하나씩 비교 대조하여 찾아봐야 함
  • 이런 구조라면 하나의 키워드를 찾을 때 마치 해쉬 (hash) 테이블을 이용하는 것처럼 시간복잡도는 O(1)에 수렴
    • 실시간 검색이 가능한 이유

• SQL 데이터베이스들은 많은 인덱스를 다룰 때 성능이 저하되는 반면 Elasticsearch 는 복잡하고 상당한 양의 인덱스를 다루더라도 성능에 저하가 거의 없음
  • 그리고 찾은 데이터를 효과적으로 다루는 능력도 가지고 있음

단점

• Elasticsearch 는 SQL 데이터베이스보다 개별 레코드 검색을 수행하는 능력이 떨어짐
  • 특히 데이터를 업데이트 할 때는 성능이 크게 떨어짐
  • 그러므로 만약 자주 정보를 업데이트 해야하는 애플리케이션이라면 Elasticsearch 는 적절한 기술이 아님

• SQL 데이터베이스에서 테이블 간의 조인을 수행하는 것처럼 Document 간의 조인을 수행할 수 없음
  • 대신 조인을 수행하는 것처럼 2번의 별개로 수행해야 함
  • 2번의 쿼리를 수행하는 것이 SQL 조인 보다 빠를 순 있지만 이런 행위를 누적해서 시행한다면 크게 느껴 질 수 있음