Elasticsearch의 데이터는 어때야 하는가?

엘라스틱 서치(Elasticsearch)와 MySQL 데이터 저장 방식 비교

1. 문제 발생

기본적으로 MySQL에 데이터를 저장하는데, 동일한 데이터를 엘라스틱 서치에도 전부 저장해야 하는지에 대한 고민이 발생했다. 데이터가 중복 저장되면 시스템 부하가 증가할 수 있으며, 관리 복잡성이 높아질 수 있다는 판단과 어차피 백업의 기능으로 보면 되는거 아닌가 라는 판단 2개가 상충하는 상황이였다.

 

2. 문제 원인

• MySQL은 데이터 저장 및 관리가 주된 역할이지만, 엘라스틱 서치는 검색 최적화에 초점이 맞춰진 데이터 저장소다.
• MySQL에 저장된 데이터를 그대로 엘라스틱 서치에 저장하면 중복 저장 문제가 발생하여 저장 공간 낭비 및 데이터 동기화 비용 증가 등의 문제가 생길 수 있다.
• 엘라스틱 서치의 강점은 빠른 검색인데, 모든 데이터를 저장하는 것은 불필요한 리소스 낭비가 될 수 있다.

 

3. 문제 해결책 수립

해결 방법 비교

해결 방법	설명	장점	단점
모든 데이터 저장	MySQL과 동일한 데이터를 엘라스틱 서치에도 저장	데이터 일관성 유지	저장 공간 낭비, 동기화 부담 증가
검색에 필요한 데이터만 저장	검색이 필요한 필드만 엘라스틱 서치에 저장	빠른 검색 속도, 효율적인 리소스 활용	일부 데이터는 MySQL에서 조회해야 함
캐싱 레이어 활용	Redis 등의 캐시를 사용하여 MySQL과 엘라스틱 서치 간 부하를 줄임	데이터 접근 속도 향상	추가적인 인프라 운영 필요

 

4. 문제 해결: 검색에 필요한 데이터만 저장

엘라스틱 서치에는 검색에 필요한 정보만 저장하는 것이 가장 효율적인 해결책이다.

• 불필요한 데이터 저장을 최소화하여 시스템 리소스를 절약할 수 있음
• 검색 속도를 최적화하고, 필요한 데이터만 색인하여 검색 효율을 높일 수 있음
• 데이터 동기화 부담을 줄여 유지보수 비용을 절감할 수 있음
• MySQL과의 역할 분리를 명확하게 하여 검색 및 저장의 목적을 최적화할 수 있음
• MySQL도 자체적인 스냅샷 혹은 백업이 존재야한다.

결론: MySQL과 엘라스틱 서치는 목적이 다르다. 따라서 모든 데이터를 중복 저장하는 것이 아니라, 검색이 필요한 데이터만 엘라스틱 서치에 저장하는 것이 가장 효율적인 방식이다.