[Elasticsearch] 단점

elasticsearch는 뛰어난 검색용 DB로 각광받고 있고, 실제로도 훌륭한 성능을 자랑하지만, 메인 DB로 사용하기에는 많은 결함을 갖고 있다.

딜레이

그 중 대표적인 결함 중 하나가 실시간성이다.
일반적인 DB들에서는 write를 한 이후에 read를 하면 이전 write의 결과를 가져올 수 있다.

하지만 elasticsearch에서는 이런 당연한 보장이 적용되지 않는다. 통상적으로 1초 정도의 딜레이를 두고 조회가 가능해진다.

그 이유는, 당연히 성능 때문이다.

하나하나 집어넣으면 너무 느리니까 버퍼를 두고, 적당히 쌓이면 그때 세그먼트에 flush-반영하는 구조를 갖고 있다.

https://velog.io/@taneeflow/Elasticsearch-What-is-the-FlushCommitMerge-FlushCommitMerge%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
flush를 수동으로 할 수 있긴 한데, 성능 문제 때문에 비권장되는 기능이다.

게다가 flush가 돼서 세그먼트가 만들어지더라도, 실제 디스크에 반영되는 부분에 또 딜레이가 있다.
동기적으로 동작하는 fsync syscall 대신 write syscall을 쓰기 때문이다.

트랜잭션의 부재

elasticsearch에서는 트랜잭션이나 그에 따르는 롤백 기능이 지원되지 않는다. 그렇기 때문에 데이터 손실과 정합성에 대한 보장이 불가능하다.

Update의 비효율성

elasticsearch는 최적화를 위해 잡아놓은 특유의 불변성 구조로 인해, update 연산이 굉장히 비효율적으로 동작한다.

그러니까, elasticsearch의 update는 기존 데이터를 delete한 후에 insert하는 형태다.

높은 메모리 사용량

elasticsearch의 뛰어난 성능은 공짜로 나오는게 아니다.

elasticsearch의 성능은 대부분 메모리 캐시를 잔뜩 사용하는 데서 나오고, 그렇기 때문에 메모리 요구사항도 높은 편이다.

실질적인 사용량의 50% 정도는 os 페이지 캐시를 위해 남겨둬야 하고, 사용량에 따라서 메모리 사용량도 당연히 선형적으로 증가한다.

https://m.blog.naver.com/sssang97/223664141145

참조
https://m.blog.naver.com/sssang97/223640540316