[ELK Stack] 검색엔진으로서의 Elasticsearch의 특성-1

이 블로그의 제 1독자는 나 자신이기 때문에 내게 필요하지 않은 내용들은 기술되지 않을 수 있음.

 

 

내가 직/간접적으로 본 ES의 주 용도는 검색엔진보다도 로그와 같은 비정형 데이터들을 모니터링하고 분석하는 시스템이었다.

이는 크게 ES의 주요한 특징 3가지 때문이라고 본다.

 

1. 비정형 데이터를 자유롭게 색인 가능

2. 고성능의 전문검색 지원

3. 강력한 분산 관리/검색 기능 --> 이건 다음편에서 설명

1번 내용은 말 그대로 요즘 심심치않게 볼 수 있는 Non-RDBMS라는 이야기다. 로그 특성상 어느 소스에서 어떤 형태로 들어올지 모르기 때문에 RDB보다는 Non-RDB가 용이하다. ES는 Document를 JSON형태로 관리한다.

 

2번은 실상 Lucene의 특성이다. ES는 Apache Lucene기반으로 만들어졌고 Lucene이 가지는 Inverted Index 구조를 그대로 가지고 있다. Inverted Index 구조는 Document 색인시 색인할 Document를 term으로 쪼개어 색인하고 각 term은 자신이 포함된 document를 가리키는 일종의 Key가 되는 Hash라고 생각할 수 있다.

 

아래의 그림이 이를 잘 설명해준다.

Inverted Index 구조

예를들어 'car'라고 query했을 때, 모든 document를 탐색하고 각 document에서 또 car가 있는지 찾을 필요가 없이

car라는 query를 term에서 찾고 term에 매칭되는 document를 가져오기만 하면 되는 것이다. 이로 인해 기존 RDB에 비해 월등히 유리한 검색성능을 가질 수 있다.

(ES의 검색 프로세스가 단순히 Matching을 의미하는 것은 아니다. 쉽게 설명하고자 Matching으로 예를 들었으며, 이에 대해 궁금하다면 TD-IDF, Cosine Similarity 등을 찾아볼것)

 

그렇다면 ES는 어떻게 Document를 term으로 분리할 수 있을까? 

그 답은 Analyzer가 갖고있다. 

ES Indexing 과정

색인될 Document는 Index로 들어가기 위해서 Analyzer를 거쳐야한다. Analyzer는 쉽게말해 형태소 분석기라고 볼 수 있다. 이 Analyzer는 ES에서 자체적으로도 훌륭한 것들을 제공하지만 상황에 따라 외부 플러그인 등을 사용하여 굉장히 섬세하게 Customizing할 수 있다.

 

Inverted Index구조의 색인방법은 다양한 Analyzer와의 조합으로 굉장히 수준높은 성능의 검색(속도, 정확성)을 구현할 수 있다. 하지만 한가지 꼭 고려해야할 사항이 있는데, Retrieve(검색)를 수행할 때는 상수 시간에 원하는 자료를 가져올 수 있지만 Writing(쓰기/색인)시간이 상대적으로 길다는 것이다. 이것은 ES의 인덱싱과 검색 프로세스가 Real Time이 아니라 Near Real Time이 되는데 영향을 미친다. 따라서 대규모 검색 시스템을 구현한다면 필수적으로 인덱싱 프로세스를 튜닝해서 최적화 해야한다.

 

(원래 성능 최적화에 관한 내용은 기술하지 않으려고 했는데 적다보니 욕심이 생겨서

추후에 따로 파트를 두고 포스팅하려 한다.

나도 모르는 부분이 많아서 차근차근 공부하면서 정리해봐야겠다.)

 

 

-다음편에 계속-

 

사진출처

https://blog.lael.be/post/3056 - 내 글 볼필요 없을만큼 자세히 설명돼있음..^_T;;
https://medium.com/elasticsearch/what-happens-when-a-document-is-indexed-in-elasticsearch-16b7ae3415bc