검색 성능 개선 #15 Full-text index VS ElasticSearch

ElasticSearch 기술적 선택 이유

mySQL의 Index 방식으로는 특정 키워드에서 검색 성능을 개선하기에 어려움이 있었던 것으로 확인을 했고

그에 따라 좀 더 강력한 검색 엔진이 필요했다.

따라서 기존의 index처럼 트리구조(Log(N))의 자료구조가 아닌

해시테이블 방식의 Log(1)구조인 Elastic Search를 적용하고자 했다.

---

적용이유

첫번째 시간복잡도

Full-text index O(LogN) > ElasticSearch O(1)

full-text index가 더 오래 걸린다.

 

Full-text index

Full-text index는 MYSQL에서 제공하는 index 방식 중 하나로

DB에서 제공하는 모든 인덱스는 B-TREE 구조로 정렬 및 저장된다.

색인하는 과정으로 해당 연산의 시간복잡도는 O(LogN)이다.

ElasticSearch

ElasticSearch는 기본적으로 inverted index 방식으로

B-TREE 구조가 색인 방식이라면은 ElasticSearch 즉 inverted index는 역색인이다.

RDBMS에서의 index 방식대로라면 Europe를 검색한다고 가정했을때 모든 docID를 조회해야하지만

inverted index처럼 역 인덱스가 있다면 Europe을 포함하고 있는 docID를 바로 가져올 수 있다.

이는 hashtable 구조를 가지고 있다고 볼 수 있는데 해당 연산의 시간복잡도는 O(1)을 가진다.

---

두번째 parser

MYSQL에서 기본적으로 제공되는 built-in parser를 모두 가지고 있고 (stop-word, N-gram)

성능 역시 훨씬 더 다양하고 강력하다.

N-gram, Egde NGram, Shingle 예시

출처 : https://esbook.kimjmin.net/

Elastic 가이드 북 - Elastic 가이드북

---

세번째 형태소 분석기

Full-text index에는 한글 문자와 ngram parser와 호환성이 좋지 않다.

특히 한글에 대해서는 업데이트가 되었다고 하지만 ngram때문에 최소 문자를 2글자로

줄인다면 영어의 성능이 떨어지고 그렇다고 최소 문자를 올리게되면은 한글의 성능이

좋지 못하다.

실제로 많은 DB에서 영어와 한글의 형태소 분석기 성능에 대한 이슈는 끊임없이 나온다.

ElasticSearch에는 각각 Snowball과 nori라는 영어 한글 형태소 분석기가 존재하는데

이 형태소 분석기는 DB보다 좋은 성능을 발휘한다. 심지어 무료다.

ElasticSearch는 검색엔진이기 때문에 이 부분에서 최적화가 잘 되어 있을 수밖에 없다.

---

네번째 Kibana와 logstash의 존재

logstash는 데이터 수집엔진으로 다른 소스의 데이터를 탄력적으로 통합하고 정규화할 수 있는 툴이고

Kibana는 이를 view로 보여주는 역할을 한다.

이 둘은 ElasticSearch와 함께 ElasticStack으로 묶여서 사용 될 수 있고

이 둘을 사용하게 된다한다면 선택의 여지가 없다.

---

다섯번째 pintable 프로젝트의 특징

우리가 실전 프로젝트 초기에 공부했던 내용들을 살펴보면 우리 모두는 하나 같이 아래와 같이 얘기했었다.

수정이나 삭제의 경우에 RDBMS보다 낮은 성능을 보여준다고 배웠다.

하지만 우리 프로젝트 특성상 우리는 천만건의 데이터를 쌓고 난 이후에 더 이상의 추가적인

데이터 작업이 없을 것이기 때문에 ElasticSearch를 적용하는 것이 유리하다.