나는 그래도 나름 엘라스틱서치를 공부를 했다고 생각했지만
면접을 진행하면서 그림을 그리려고 사서 선만 한번 그어봤구나. 라는 생각이 들었다.

두번의 기술면접 받았던 엘라스틱 서치에 관련한 질문은 아래와 같았다.

• 엘라스틱서치의 특징을 설명해주세요.
• 어떤 토크나이저를 사용해보셨나요?
• 유사어 검색을 적용해보셨나요?

그저 엘라스틱서치의 특징을 알고 있었다, 다른 검색엔진에는 없는 그러한 것은 모르고 말이다.
토크나이저는 nGram 밖에 사용을 못해봤다, 그 외에는 모두 디폴트인 스탠다드로 사용을 했었다.
마지막은 아예 적용을 해볼 엄두가 나질 않았다(....)
Prefix 관련 질문도 해주셨는데 이것도 알고만 있고 적용은 하지 못했다.

그래서 적어본다. 내가 조금 더 자세하게 알기 위하여

해당 포스트는 모두 아래에 있는 책기반으로 작성이 이루어집니다.

Elasticsearch의 역사

엘라스틱서치가 처음 등장하였을 때 그 누구도 빅데이터 파이프라인을 구성하는 플랫폼 형태로 성장하히라 예상하기 어려웠다.
그 시기의 사용자들의 요구사항은 명확했는데 사이트 내의 전문 검색 기능을 제공하는 소프트웨어가 필요하다는 것이였다.

그러는 와중에 검색 서비스는 계속 등장을 했지만 오픈소스가 없었기에 일반 개발자들은 접근을 할 수가 없었고
기업에서 제공하는 검색기능이 포함된 라이브러리나 프레임워크는 갑비싼 솔루션에 의존할 수 밖에 없었다.
이러한 문제가 있어서 기업용 검색 기능의 발전이 빠르지 않았다.

1999년 더그 커팅은 검색엔진을 만들던 역량을 발휘하여 자신의 다섯 번째 검색 엔진 라이브러리를 만들게 되는데,
이것이 바로 엘라스틱서치의 기반이 되는 루씬의 등장이었다.

루씬은 2001년 아파치 자카르타에 합류를 하였고, 규모가 점점 커지면서 2005년 2월 독자적인 프로젝트로 분리가 된다.
이렇게 전문 인덱싱과 검색 기능을 요구하는 애플리케이션에 사용되기 시작하였고
더그 커팅은 2003년 6월 100만 페이지를 가져오는 웹 크롤러인 아파치 너치를 만들어 루씬의 위력을 증명해냈다.

하지만 루씬은 라이브러리 형태로 되어있어서 제대로 사용하기 위해서는 선행 조건이 너무 많아서 사용자 편의성을 제공하기 위한 작업이 필요했다.

이 무렵 기술 잡지를 만들던 CNET 네트워크에서 사내 검색을 위해 만든 검색엔진의 소스 코드를 2006년 아파치 재단에 기부를 하였고
이는 시간이 흘러 2021년 2월 아파치 최상위 프로젝트인 아파치 솔라가 되었다.

솔라가 개발되고 있을 2004년 무렵 자신의 부인이 레시피 검색을 할 수 있도록 루씬을 기반으로 Compass 프로젝트를 진행하던 샤이 배넌은 많은 부분을 수정하여 확장이 가능한 검색엔진 솔루션을 만들면 좋겠다는 생각을 했다.

분산 환경을 위한 솔루션, HTTP상에서 JSON이 요청되게 하는 솔루션, 자바 이외에도 다양한 프로그래밍 언어를 지원하는 솔루션을 표방하여 작업을 하였고 2010년 2월 엘라스틱서치가 공개되었다.

---

엘라스틱서치는 검색엔진에서 끝나는 것이 아닌, 다양한 사용 사례에 유연하게 대처하기 위하여 플랫폼이 필요하다고 느꼈다.
하지만 검색엔진이 그러한 유연함을 가지기 위해서는 아래와 같은 빅데이터 파이프라인이 필요했다.

이러한 과정을 위해서는 다양한 오픈소스 소프트웨어를 조합해서 사용해야 하는 불편함이 있었는데
엘라스틱은 이러한 부분을 속 시원하게 해결해주는 해법을 제시해주고, 필요한 스택을 쌓아 올리기 시작했다.

엘라스틱서치가 개발이 될 무렵 두 가지 오픈소스 프로젝트가 진행이 되고 있었는데

요르단 시셀은 사용자가 선택한 보관함(Stash)에 로그를 보내주는 오픈소스 데이터 수집 도구 Logstash가 개발되고 있었고
라시드 칸은 오픈소스 시각화 UI인 Kibana가 개발이 되고 있었다.

엘라스틱서치의 개발자였던 샤이배넌은 두 사람과 친분이 있었고, 각자의 프로젝트도 알고 있어서 2012년 모여서 팀을 결성하였고 이것이 엘라스틱서치, 로그스태시, 키바나를 합친 ELK Stack의 시작이였다.

초창기에는 엘라스틱 스택이 느슨한 형태로 개발이 되어 각자 버전이 맘대로 출시가 되고 있었다.
하지만 사용자에 요구에 따라서 개선과 다양한 플러그인이 확장되었는데
버전이 서로 달라 호환성의 문제가 발생하였다.

이를 해소하기 위해 2015년 10월 버전을 동일하게 맞춘 제품이 출시되어 안정적인 기반이 확보가 됐다.

2015년 베를린의 패킷비트라는 회사가 네트워크 데이터를 엘라스틱 서치로 보내는 방법을 연구하고 있다는 사실을 엘라스틱 개발팀이 알게 되었고
엣지 장비(사물인터넷, 핸드폰 같은 데이터를 제공하는 스마트기기)에서 데이터를 수집하는 가능성을 고려하여 패킷비트와 연합해 비츠가 탄생됐다.

그 후 4개를 통합하여 Elastic Stack이 탄생하였다.

공식 홈페이지 사진 https://www.elastic.co/kr/what-is/elk-stack

엘라스틱서치의 특징

전세계에서 사용하는 데이터베이스 사용률 8위, 검색엔진 1위인 엘라스틱 서치의 모습

검색엔진 분야에서는 독보적인 사용률 1등을 자랑한다.

---

기나긴 역사가 끝났고 오늘의 메인 주제였던 엘라스틱서치에 대한 설명이 시작된다.

흔히 엘라스틱서치를 검색엔진이라 부르지만, 어느때는 NoSQL DB처럼 사용하기도 한다.

어떠한 이유때문에 이렇게 사용을 할 수 있는 이유가 무엇인지?
독보적으로 엘라스틱서치가 검색엔진으로 강점을 가질 수 있는 이유는 무엇인지 알아갈 예정이다.

특징을 설명하면서 이 특징때문에 어떤 것이 가능했다. 라는 식으로 설명이 이루어진다.

왜냐하면 모든 데이터를 JSON의 도큐먼트 형식으로 입력 및 관리가 되고 있고, 쿼리한 결과에 일치하는 원본을 반환하며
문자, 숫자, 날짜, IP주소 등 다양한 타입을 사용할 수 있기 때문이다.

그리고 관계형 데이터베이스, NoSQL과는 비교도 안될만큼 빠른 속도로 데이터를 조회할 수 있고 복잡한 검색이 가능한데
이것이 제일 큰 특징이다.

검색엔진으로 인기가 많은 이유 (역인덱스&분석기)

여기서 말하는 역인덱스란 흔히 책장 맨 뒤쪽에 단어단위로 나눠져서 어떤 페이지에 나와있는지 적혀있는 것을 말한다.

엘라스틱서치에 인덱싱이 이루어지는 경우 분석기 라는 것을 통하여 용어(Term)가 분해되어 역인덱스 사전이 구축된다.

이것을 통하여 관계형 데이터베이스, NoSQL에서는 볼 수 없었던 엄청나게 빠른 속도의 전문 검색을 지원하게 된다.

SQL의 Like 구문이 전문검색이라고 이야기를 하지만 완벽한 전문 검색은 지원하지 않는다.
하지만 엘라스틱서치 는 분석기를 통한 역인덱싱 으로 이것을 완벽하게 지원한다.

그렇다면 분석기에는 어떤 것이 있는지 확인을 해보고 넘어가자.

여기서 이야기하는 전문(Fulltext) 검색이란 긴 장문의 문자열 속에서 일부를 검색해도 나오는 것을 이야기한다.

분석기

엘라스틱서치는 전문 검색을 위하여 3가지로 구성되어있는 분석기 모듈이 존재한다.

여기서 주의를 해야할 점은, 토큰과 용어의 차이가 존재한다는 것이다.

토큰은 분석기에서 토크나이저를 통해 필터링 된 문자열이 잘리는데, 이때 잘린 단위를 토큰이라고 지칭하며
토큰 필터를 거쳐서 최종적으로 정제가 되어 인덱스에 저장되는 토큰들을 용어라고 부른다.

이렇게 문자를 잘라서 인덱스하는 것을 역인덱스(역색인)이라고 부른다.

즉, 토큰은 잠시동안 유지되는 상태라는 것이고 실질적으로 검색에 사용되는 것은 용어라고 부르면 된다.

각각의 특징은 아래와 같고, 중요한 점은 반드시 한개의 토크나이저가 포함되어야한다.

• 캐릭터 필터
  • 입력받은 문자열을 변경하거나, 불필요한 문자를 제거한다.
  • HTML의 태그같은 것을 처리하거나, 특정 단어를 다른 단어로 변경할 수 있다.
• 토크나이저
  • 문자열을 토큰으로 분리한다.
  • 기본값의 경우에는 공백을 기준으로 토큰화가 이루어진다.
• 토큰 필터
  • 분리된 토큰의 필터 작업을 한다.
  • 소문자, 대문자로 변경하거나 형태소 분석같은 작업이 이루어진다.

이와같이 3개의 모듈을 통해서 역인덱싱이 적용되는데, 분석기 자체의 옵션을 지정하는 방법과
각각 모듈에 옵션을 지정하는 방법, 원하는 옵션이 없을 경우 직접 지정하는 커스텀 분석기가 존재한다.

자주 사용되는 분석기

분석기 이름	설명
standard	옵션을 적용하지 않을 경우 엘라스틱서치가 기본적으로 사용하는 분석기다. 영어를 기준으로 스탠다드 토크나이저와 소문자 변경 필터, 스톱 필터가 포함되어있다.
simple	문자만 토큰화를 한다. 공백, 숫자, 하이픈(-) 따옴표(')같은 문자는 토큰화하지 않는다.
stop	simple 분석기와 비슷하지만 스톱 필터가 포함되어있다.

존재하는 캐릭터 필터

필터 이름	설명
html_strip	HTML 태그를 제거하여 일반 텍스트로 만든다.
mapping	지정한 단어를 다른 단어로 변경한다. 특수문자를 포함한 검색에서 보통 사용한다.
pattern_replace	정규식을 사용하여 더욱 더 복잡한 패턴을 변경할 수 있도록 만든다.

대표적인 토크나이저

토크나이저 이름	설명
standard	스탠다드 분석기가 사용하는 토크나이저다. 쉼표, 점, 특수문자 같은 것을 제거하여 토큰화를 시키며 특징은 문자열 중간에 있는 것은 지우지 않는다.
Leetter	알파벳을 제외한 모든 것을 제거한 후 토큰화를 시킨다.
whitespace	공백을 기준으로 구분하여 토큰화를 한다.
ngram	원문으로부터 N개의 연속된 글자 단위를 모두 토큰화시킨다. 예시로 2gram으로 양념치킨을 토큰화 시킬 경우 [양념,념치,치킨] 이런식으로 분리가 된다. 이것으로 전문검색이 가능하긴 하지만 ngram의 수보다 적은 글자일 경우 검색이 불가능하고, 문장이 길 경우에는 모든 조합을 추출하여 저장공간을 많이 차지하는 문제가 존재한다.
uax_url_email	스탠다드 분석기와 비슷하지만, URL과 이메일을 토큰화를 시켜준다.

자주 사용하는 토큰 필터

토큰 필터 이름	설명
lowercase	모든 문자를 소문자로 변환한 후 term으로 만든다.
uppercase	모든 문자를 대문자로 변환한 후 term으로 만든다.
stop	모든 불용어를 제거한다. 불용어란 한국어에는 존재하지 않는 영어의 'a' 'the' 같은 것이다.
stemmer	문자의 형태를 분석해 어간으로 변환시킨다. 기본적으로 영어를 지원한다

---

이렇게 다양한 것이 존재하지만, 기본적으로 영어를 베이스로 제작이 되었기때문에
한글 형태소 분석기 를 활용하고 싶은 경우에는 직접 구현 을 해야한다.

하지만 이것도 어느정도 제작되어서 이것을 활용하여 추가적으로 제작을 하고 있다.

엘라스틱서치에서 제공하는 한글 형태소 분석기, 노리(Nori)

다나와같은 이커머스 홈페이지에서 이러한 한글 형태소 분석기를 제작할 수 있는 사람을 구인하고 있기도 하다.

또한 자신이 직접 제작을 하는 방법도 있는데, 이것을 Custom Analyzer라고 부른다.

Custom Analyzer에 대한 공식 홈페이지 가이드 7.17버전

이러한 다양한 분석기를 사용하여 역인덱싱을 구현하는 엘라스틱서치는 전문검색임에도 불구하고
빠른 속도로 결과를 도출해낼 수 있다는 큰 특징이 있다.

NoSQL DB로 사용할 수 있는 이유 (구조 & JSON & 타입지정)

엘라스틱서치를 NoSQL DB처럼 사용하는 경우도 상당히 많다.

왜냐하면 모든 기능이 Rest API의 형태로 되어있어서 응답과 요청도 Rest API를 활용하여 사용할 수 있다.
또 모든 데이터를 JSON의 도큐먼트 형식으로 입력 및 관리가 되고 있으며
쿼리한 결과에 일치하는 원본을 반환하며 문자, 숫자, 날짜, IP주소 등 다양한 타입을 사용할 수 있기 때문이다.

이러한 속성때문에 NoSQL DB로 사용이 가능한 것인데, 구조가 어떻게 되어있는지 한번 확인을 해보자.

많이 익숙한 구조라는 것을 확인할 수 있는데.
관계형 데이터베이스인 MySQL과 비교하자면 아래 표처럼 나눌 수 있다.

MySQL	엘라스틱서치
데이터베이스	클러스터
테이블	인덱스
레코드	도큐먼트
컬럼	필드
스키마	매핑

이 표를 가지고 한개한개씩 설명을 해보려고 한다.
클러스터는 설명하려면 한 페이지를 할당해야 할 것이기에 제외하고 인덱스부터 시작된다.

인덱스

인덱스는 도큐먼트를 저장하는 논리적 단위로, 관계형 데이터베이스의 테이블과 비슷한 개념이다.

게시판의 index가 board로 지정되어있는 모습이다.

한개의 인덱스에는 다수의 도큐먼트가 포함되어있는 구조로 되어있고
인덱스의 이름에는 사용할 수 있는 것이 제한되어있다.

엘라스틱서치 공식문서 Create index API

도큐먼트

도큐먼트는 관계형 DB의 레코드, NoSQL은 동일한 도큐먼트라고 생각할 수 있다.

모든 도큐먼트는 1개의 인덱스를 가지고 있어야하는 것이 규칙이며
인덱스에서 정한 스키마가 모든 도큐먼트의 스키마를 결정한다.

그렇기에 한개의 인덱스에 모든 자료를 다 넣는 것도 방법이겠지만
효율이 좋지 않기 때문에 관리형 데이터베이스처럼 형식에 따라서 분리를 하는 것이 일반적이다.

필드 & 매핑

필드는 일반적으로 관계형 DB의 컬럼, NoSQL은 동일한 필드라고 생각할 수 있다.

여기서 중요한 것은 바로 매핑 인데 해당하는 필드의 타입을 지정해주는 것을 이야기한다.

관계형 DB에서는 테이블을 만들 때, 반드시 스키마 설계가 우선적으로 필요하다.
NoSQL에서는 타입 구분없이 넣을 순 있지만, 문제가 발생할 수 있기에 스키마 설계를 권장한다.

엘라스틱서치에서는 들어오는 타입에 따라서 자체적으로 스키마를 매핑해주는 다이나믹 매핑라는 것이 존재하지만,
자신이 직접 설정하는 명시적 매핑을 권장하고 있는데 그 이유를 알아보려고 한다.

더불어서 엘라스틱서치가 검색 엔진으로 전문 검색과 대용량의 데이터를 빠르게 검색할 수 있는 이유는 매핑이 존재하기 때문이다.

다이나믹 매핑

엘라스틱서치의 모든 인덱스는 매핑 정보를 갖고 있지만, 유연한 활용을 위해 매핑 정의를 강제하지 않는다.
하지만 분석기를 설정하지 않을 경우 자체적으로 스탠다드 분석기가 적용이 되는 것처럼
아무런 설정을 하지 않을 경우 들어온 값에 따라서 자체적으로 매핑이 적용되는 것을 다이나믹 매핑이라 부른다.

기본적인 형태는 JSON 도큐먼트의 데이터 타입에 맞춰서 인덱스 매핑을 해주기 때문에 데이터의 형태만 고민하면 되서 상대적으로 편리하지만, 특정 타입에 대해서는 메모리낭비 혹은 검색이 불가능할 수도 있기에 매핑이 필요하다.

원본 소스 데이터 타입	다이나믹 매핑으로 변환된 데이터 타입
null	필드에 추가하지 않음
boolean	boolean
float	float
integer	long
object	object
string	string 데이터형태에 따라서 date, text/keyword 필드

여기서 모르는게 보이는 것 같지만, 아래 명시적 매핑에서 함께 설명을 진행한다.

명시적 매핑

인덱스 매핑을 직접 정의하는 것을 명시적 매핑이라고 부른다.
인덱스가 생성되기 전에 매핑 설정을 하거나 API를 통하여 지정할 수 있다.

분량이 무지막지하게 많아서 이 부분은 데이터 타입에 관한 것은 링크로 대신한다.

엘라스틱서치 공식문서 Field data types

여기서 명시적 매핑을 해야하는 이유는 몇가지가 존재한다.

• 정수가 입력될 경우 모든 데이터 타입이 long으로 지정된다.
  • long같은 경우는 -2^63 ~ 2^63-1같이 엄청 큰 수가 지정이 되는데
    사람의 나이라거나, 게시글의 좋아요 개수같은 경우에는 이렇게 큰 수가 필요가 없다.
    이것은 메모리의 낭비로 이어지므로 short같은 것을 사용하는 것이 좋다.
• 전문검색이 필요한 경우와 필요하지 않는 경우를 나눠야한다.
  • 텍스트를 지정하는 타입중에는 text와 keyword라는 두개의 타입이 존재한다.
  • text : 전문 검색이 필요할 때 사용하는 타입, 분석기가 텍스트를 분리한다.
  • keyword : 전문 검색이 필요 없을 때 사용하는 타입, 원문 그대로 인덱싱한다.
  • 왜 지정을 해야하냐면 keyword에는 최대 저장할 수 있는 길이가 존재한다.
    그래서 이 점을 고려하지 않고 저장을 할 경우에는 데이터가 정상적으로 인덱싱되지 않을 수 있다.
• 다양한 타입이 한번에 필요한 경우 지정할 수 있다.
  • 엘라스틱서치는 데이터 형식에 따라서 전문 검색도 해야하지만 정렬 옵션이 필요한 경우도 있다.
  • 이러한 상황을 대비하여 엘라스틱서치는 한개의 필드에 다양한 타입을 지정할 수 있는 멀티필드를 지원한다.

---

이렇게 자체적으로 지원하는 다이나믹 매핑과 명시적 매핑을 활용할 수 있는 것이 엘라스틱의 특징 중 하나다.

흐름상으로는 검색을 하는 방법에 대해서 설명이 나와야하지만 이것을 다 적기 시작하면 끝이 나질 않기 때문에
작성하지 않으며, 추후 또 다른 포스트로 작성이 이루어질 수도 있다.

완벽한 파이프라인을 구축할 수 있는 로그스태시

로그스태시는 특정한 데이터를 입력받아, 데이터를 가공한 후 엘라스틱서치에 데이터를 집어넣어줄 수 있는 파이프라인이다.

로그스태시는 플러그인 기반의 오픈소스 데이터 처리 파이프라인 도구로,
다소 복잡하고 귀찮은 데이터 전처리 과정을 간단한 설정으로 수행할 수 있게 만들어준다.

그래서 일반적으로 엘라스틱서치를 사용할 때 별도의 프로그램을 사용하는 것보다 로그스태시를 사용하는 것을 추천하고 있다.

로그스태시의 특징

• 플러그인 기반 시스템
  • 파이프라인을 구성하는 모든 요소가 전부 플러그인의 형태로 만들어져있다.
  • 기본적으로 제공하는 것 외에도 수많은 커뮤니티에 플러그인이 존재한다.
  • 필요한 경우에는 간단한 코드로 직접 구현도 가능하다.
• 모든 형태의 데이터 처리
  • 기본적으로 제공되는 플러그인을 사용하는 것 만으로도 대부분의 데이터를 사용할 수 있다.
  • JSON XML은 물론이고 관계형 데이터베이스나 NoSQL의 데이터를 받아서 마이그레이션 하는 것도 가능하다.
  • 또한 스케쥴러인 크론탭을 사용하여 시간에 따라 발생하는 데이터를 처리하는 것이 최적화되어있다.
• 성능
  • 자체적으로 내장되어있는 메모리와 파일 기반의 큐를 사용하여 처리속도와 안전성이 높다.
  • 인덱싱할 도큐먼트의 수와 용량을 종합적으로 고려하여 벌크 인덱싱을 수행한다.
  • 자체적으로 파이프라인의 배치 크기를 조정하여 병목현상을 방지하여 성능을 최적화시킨다.
• 안정성
  • 엘라스틱서치의 장애상황을 대응하기 위하여 재시도 로직이나 오류가 발생한 도큐먼트를 따로 보관하는 공간이 존재한다.
• 멀티 파이프라인 지원
  • 여러가지 데이터를 받아야하는 경우가 필연적으로 발생을 한다.
  • 이것을 위하여 여러개의 파이프라인을 연결할 수 있는 시스템이 존재한다.

사실 맨처음 써보면 상당히 복잡하다고 느끼는데, 사용하다보면 이게 정말 편리하다고 느꼈다.

총 3가지의 파이프라인으로 구성이 되어있는데

입력(input)
필터(filter)
출력(output)

필터에서는 루비를 사용할 수 있기 때문에, 반복문이나 조건문같은 처리도 가능하다.

루비를 사용하여 말머리가 VISITED일 경우 REVIEW로 바꾸는 코드를 볼 수 있다.

같이보면 좋은 글 : Logstash 멀티 파이프라인 구성하기

---

로그스태시도 정말 찾아보면 수많은 기능이 있어서 이정도로 마무리를 해야할 것 같다.
아마 현재 작성되고 있던 글이 있는데, 완성하면 같이 붙여놓을 것 같다.

분석 및 통계를 확인할 수 있는 키바나

키바나는 엘라스틱서치에 가공된 데이터를 직관적으로 시각화시켜주는 시각화 툴이다.

키바나 또한 상대적으로 사용 경험이 적기 때문에, 소개를 하는 것으로 정리를 해야할 것 같다.

키바나는 총 3가지 기능을 가지고 있다.

1. 데이터 분석 및 시각화
2. 엘라스틱 관리
3. 엘라스틱 중앙 허브

메인이라고 생각하는 기능은 바로 첫번째인 분석 및 시각화다.

이 위의 사진은 엘라스틱 키바나의 공식 사이트에 나오는 것으로, 다양한 방식으로 데이터를 표현하고 있는 모습을 볼 수 있다.

---

키바나는 사용 경험이 적어서 설명을 하는 것이 힘들 것이라 생각하여 이렇게 마무리를 하고
엘라스틱서치의 단점을 이야기하면서 글을 마무리지어야 할 것 같다.

엘라스틱서치의 단점

사실 단점보다는 장점이 더욱 많이 때문에 사용하는 것이긴 하지만 완벽하지 않다는 것은 알고 있어야한다.

• 관계형 데이터베이스에서 데이터를 받아올 경우 비정규화 과정이 필요하다.
  • 엘라스틱서치는 조인을 허용하지 않기 때문에 Concat같은 것을 사용하여 비정규화를 해야한다.
• 데이터를 저장하는 것이 실시간이 아니다.
  • 사용을 해보면 느낄 수 있는데 대략 1~2초 가량의 딜레이가 필요하다.
  • 일반적인 경우에서는 실시간처럼 보이는 편이긴 하다.
• 데이터의 업데이트를 제공하지 않는다.
  • 업데이트가 되는 것처럼 보이지만 실제로 작동하는 것은 기존의 도큐먼트를 삭제한 후 변경된 것을 생성하는 방식을 사용한다.
  • 이러한 문제때문에 수정이 많이 필요한 데이터의 경우는 엘라스틱서치를 권하지 않는다고 한다.
• 트랜잭션 / 롤백 기능이 제공되지 않는다.
  • 검색엔진의 성능을 위하여 사용하는 것인데, 결국은 메인 데이터베이스로 사용하는 것은 위험하다는 의미와 같다.

자바로 만들어졌기 때문에 C언어로 만든 것보다 느리다. 라는 글을 보긴 하였지만
C언어에서 I/O 과정이 많을 경우엔 또 속도가 느리다는 이야기를 확인해서 이 부분은 검증이 필요할 것 같다.

---

엘라스틱서치를 많이 쓰는 이유가 무엇인지 조금은 더 명확하게 알 것 같고

나는 스코어검색을 통한 정밀 검색이 엘라스틱서치만의 특징이라고 생각했는데, 그것도 아니였다(....)

분석소를 통하여 밀도높은 전문 검색이 가능하고, 그러한 특징을 살려서 정밀 검색에도 디테일이 존재한다 라고 생각할 수도 있을 것 같긴 한데... 이 부분은 알아봐야할 것 같다.

여기서 조금 더 깊숙하게 갈 경우에는 클러스터와 노드같은 구현체 그 자체까지 들어가야한다고 생각하는데
이부분은 잠시 미뤄놨다가 진행을 해야할 것 같다.

끝

---

참고한 자료 & 같이보면 좋을 자료

검색엔진 솔라와 엘라스틱서치의 차이
엘라스틱서치 공식문서
엘라스틱서치 비공식 한글 문서