Elasticsearch 간단 개념 + 장/단

Elasticsearch 장점

1. 오픈소스 검색 엔진이기 때문에 무료로 사용 가능하다.

2. 오픈소스의 장점처럼 많은 전문가들이 버그에 빠르게 대응합니다.

3. 방대한 양의 데이터를 신속하게 처리가 가능하다.

 

엘라스틱 서치의 단점

1. 진입장벽이 있다. 

2. Document간의 조인을 수행할 수 없습니다. (두 번 쿼리로 해결은 가능)

3. 트렌젝션이 제공되지 않는다.

 

프로젝트를 진행 하다보면 DB 설계를 하고 개발에 들어가며 처음에는 큰 문제없이 잘 작동하다 많은 사람들이 사용하게 됨에 따라 서버 성능 , DB 설계의 문제나 혹은 DB 최적화가 되어있지 않아 서비스가 느려지는 현상을 경험하게 되고 그 결과 관계형 데이터 베이스에 최적화를 위해 인덱싱을 하게 되고 이 점은 굉장히 중요한 작업이며 어떻게 인덱싱을 하냐에 따라 퍼포먼스가 다른 것을 경험한 적이 있을 것이다. 

 

엘라스틱 서치 역시 데이터에 다양한 규칙으로 최적화된 인덱싱을 처리 할 수 있어서 검색에 빠른 성능을 보이는 것이다.

또한 관계형데이터 베이스와 엘라스틱서치의 데이터 저장되는 구조 자체가 다르다. [아래 그림 참초]

 

 

 

관계형 데이터 베이스는 document 중심이라면 elastic search는 텍스트 중심이라고 보면 된다.

유저가 영화감독 봉준호를 검색하는 순간 관계형 데이터는 doc1~ doc3을 하나하나 확인하며 봉준호의 영화 데이터 위치를 찾지만.

Elastic search 는 검색하는 순간 데이터를 찾을 수 있기 때문이다.

 

그렇다면 이렇게 생각할 수 있다.

"그럼 왜 관계형 DB를 쓰지? 그냥 엘라스틱 서치로 처음부터 하면 되지 않을까?"

답은 No이다.

데이터를 저장하고 필요에 따라 사용자들에게 제공하는 점은 같지만 사용 용도가 다르기 때문이다.

 

관계형 데이터는 말 그대로 관계된 데이터(테이블)를 조합하여 볼 수 있으며 , 데이터의 ACID 원칙에 의해 관리되는 목적이 있는 반면

엘라스틱서치는 데이터를 다른 table과 조합할 수 없으며 (가능은 하나두 번 질의를 해야 하는 문제가 있을 수 있다.)

그리고 데이터 트렌젝션을 지원하지 않는다. 이러한 점에서 볼 때 엘라스틱서치만으로 서비스를 개발하기에는 무리가 있어 보인다.

 

가장 좋은 것은 관계형 DB를 베이스로 하고 검색에 필요한 부분만을 엘라스틱서치로 진행하는 것이 보통이다.

 

 

 

위의 아키텍처 이미지처럼 사용자의 요청에 따라 디비에 저장되고(RDBMS or NON-RDBMS) 검색 혹은 분석이 필요한 부분만을

데이터를 추출하여 엘라스틱 서치에 자동 저장시켜서 방대한 양의 데이터를 빠르고 다양하게 검색될 수 있도록 처리하게 된다.

 

그렇다면 이제 디비에서 필요한 데이터를 추출하여 자동적으로 엘라스틱에 데이터를 넣는 부분을 담당하는 것에는 무엇이 있을까?

가장 대표적인 것으로는 Logstash 가 있다.

 

 

 logstash로 mysql , mongodb 모두 지원하는 것으로 나와 있지만.

찾아본 결과 mongodb 는 많은 자료가 있지 않았다 결국 mongodb로 elasticsearch에 데이터를 넣기 위해 최적의 서비스로는 monstache 가 있다는 것을 알게 되었다.

 

monstache를 통한 elastic search data 주입은 이전에 작성한

[ MongoDB + ElasticSearch + Monstache ] 도커 기본 셋팅을 해보자

https://sudarlife.tistory.com/entry/MongoDB-ElasticSearch-Monstache-%EB%8F%84%EC%BB%A4-%EA%B8%B0%EB%B3%B8-%EC%85%8B%ED%8C%85%EC%9D%84-%ED%95%B4%EB%B3%B4%EC%9E%90

를 통해 확인해볼수 있다.