들어가며
연구원들이 동물실험을 진행하며 기록한 데이터들을 실험이 속해있는 프로젝트, 실험의 종류, 실험을 진행한 날짜에 따라 테이블 형태로 보여주기 위한 조회 API가 존재하였습니다.
2주간격으로 스프린트가 진행되고 빠른 속도로 feature를 개발해야하는 환경임에 따라 일단은 최적화에 신경을 쓰지않고 feature 개발에만 focus를 맞춰 API를 진행했던 상태였습니다.
새로운 스프린트가 시작되기 전, 여유가 생겨 가볍게 index 도입을 통한 조회 Query 튜닝 작업을 진행하였습니다.
문제점 파악하기
MongoDB Compass의 explain 기능을 통해 현재 조회 쿼리를 분석해보았습니다.
문제점
해당 쿼리는 COLLSCAN을 방식으로 동작하고 있었습니다.
COLLSCAN은 인덱스를 사용하지 않고 전체 컬렉션을 스캔하여 데이터를 찾는 방식으로, 데이터가 증가할수록 성능 저하가 심해집니다.
Compound Index
😁 장점
쿼리 성능 향상: Compound Index를 사용하면 복합적인 조건으로 데이터를 조회하는 쿼리의 성능을 향상 시킬 수 있습니다. 여러 필드를 하나의 인덱스로 묶어 두 가지 이상의 조건으로 데이터를 검색할 때, 해당 인덱스를 활용하여 데이터를 빠르게 찾아올 수 있습니다.
Prefixes(접두어) 검색 지원: Compound Index를 활용하면 인덱스의 첫 번째 필드를 이용해 Prefixes 검색이 가능합니다. 첫 번째 필드로 검색하는 경우에도 인덱스가 활용되기 때문에 단일 필드 인덱스의 장점과 결합하여 사용할 수 있습니다.
😕 단점
update 연산 시 index 오버헤드: Single Field Index와 Compound Index를 비교하면, 복합 인덱스의 경우 update 연산 시 더 많은 인덱스 업데이트 작업이 발생할 수 있습니다. Single Field Index는 해당 필드만 업데이트하면 되지만, Compound Index의 경우 여러 필드를 포함하므로 여러 필드의 변경을 감안하여 인덱스를 업데이트해야 합니다. 따라서, update 연산이 빈번하게 발생하는 경우에는 Compound Index의 업데이트 오버헤드가 더 크게 느껴질 수 있습니다.
인덱스 도입
고민끝에 Compound Index를 도입하기로 하였습니다.
- 해당 필드들의 대한 update 연산이 자주 발생하는 상황이 아니다.
- 조회 시,
프로젝트Id,실험의 종류,실험을 진행한 날짜를 filter로 조회한다. 프로젝트Id가 단일로 쓰이는 경우가 있지만Prefixes특징으로 인해 Compound Index로 커버가 가능실험을 진행한 날짜,실험의 종류가 Single Field Indexes로 동작해야하는 case가 존재하지 않는다.
4가지 이유를 근거로 Compound Index를 도입하였습니다.
결과
이전의 COLLSCAN에 비해 Documents Returned : Index Keys Examined : Documents Examined의 비율이 1:1:1이 되었습니다.
Compound Index 도입으로 쿼리의 조회 대상 문서 수와 인덱스 키를 검사한 횟수가 거의 일치하게 되었습니다. 이로 인해 조회 성능이 개선되었습니다.
