Elasticsearch 도입의 배경
진행하고 있는 팀프로젝트에서 모임 도메인을 맡아 기능을 구현하고 있던 도중, 이전 글에서 작성한 적이 있는데 Index를 통해서 조회 성능을 개선한 경험이 있습니다.
복합 인덱스로 is_deleted, category_id, status, meeting_date 를 걸어서 조회 성능을 개선했었는데 ( 초당 1000번의 요청 30초간 테스트 ), 실제 조회로직을 생각해보면 검색어 또한 중요한 필터가 될 것입니다.
하지만 이런 경우는 인덱스만을 통해서 성능 개선을 할 수 없습니다. 그 이유는 RDB 사용시 Title 조회 같은 경우 Like 문법을 사용하여 데이터를 조회해야하는데, Like사용시 인덱스를 무시하기 때문입니다.
또한 데이터가 많아지는 경우를 생각해보면 Elasticsearch의 특성 (역색인)을 통해 더욱 빠른 성능을 만들어낼 수 있기 때문에 도입하기로 결정하였습니다.
Elasticsearch 란 무엇인가?
위 배경 설명에서 간단히 적었지만 그래서 Elasticsearch란 무엇이길래 조회 성능 개선 시 사용한다고 할까요?
Elasticsearch란 오픈소스 분산 검색엔진이며, 대용량 데이터를 빠르게 검색하고 분석할 수 있습니다. Elasticsearch는 Lucene을 기반으로 만들어졌으며, Lucene은 역색인을 제공하기 때문입니다.
역색인이 정확히 어떤 기능일까 ?
기존에 주로 사용하던 관계형 데이터베이스는 단방향 색인 방식을 사용합니다. 특정 검색어가 있고 이를 찾기 위해서는 모든 문서(칼럼이라고 생각하면 될 것 같습니다)를 확인하여 존재하는지 검색을 해야합니다. 한마디로 전체 검색을 해야 한다는 의미가 됩니다.
그러나 역색인은 value-key 방식으로 데이터 별로 어떤 곳에 존재하는지를 바로 파악할 수 있게 됩니다.
위와 같은 이미지를 통해 쉽게 이해가 될 수 있을 것 같습니다.
자 그럼 내부적으로 역색인 방식을 사용하여 데이터 조회 시 이점을 가져갈 수 있다!라고 이해하고 바로 도입하기 보다는 어떤 서비스든 장점이 명확하다면 단점도 분명 존재하기 마련이라고 생각하기에 단점 또한 확인해보겠습니다.
Elasticsearch의 단점
1. Lucene 쓰기 성능 나쁨
2. 주로 조회 보조 장치로 사용하기 때문에 데이터 정합성 문제가 발생할 수 있음
- 위 문제를 해결하기 위해서 저장 데이터베이스에서 업데이트가 되었을 때 어떤식으로 es와 정합성을 맞출지 추가적인 처리 필요
- 업데이트시 내부적으로 전체 삭제 후 추가 하는 방식
3. Elasticsearch 서버 자체의 리소스 사용량이 많음. 만든 색인과, 역색인 구조를 디스크에 저장하기 때문
실제 현재 개발중인 SpringBoot 기반의 프로젝트와 Es를 도입하여 사용하는 것은 실제 진행한 후 다음글에서 이어서 작성해보도록 하고 마지막으로 Es의 용어를 알아보고 마무리하겠습니다.
Elasticsearch 용어
| Elasticsearch | RDB (Mysql) |
| Index | Database or Table |
| Field | Column |
| Document | Row |
| Shard | Partition |
| Node | Server |
애초에 구조가 다르기 때문에 명확하게 이거다! 라고 말할 수는 없지만 비교를 하자면 위와 같이 구분할 수 있을 것 같습니다.
그중 Shard를 부가설명하자면 Index 내부에 엄청나게 많은 데이터가 문서가 존재한다면 이를 한 곳에 저장하는 것이 아닌 분산하여 저장하는 것을 말합니다. 처리속도를 위해서라고 말할 수 있을 것 같습니다.
아마 Spring Data Elasticsearch를 사용하여 ES를 사용할 것 같습니다. 기능 구현 후 작성해보도록 하겠습니다.