MongoDB를 로그 디비로 운용하며 생긴 이슈 및 쿼리 튜닝에 대한 내용을 간략하게 정리해보았습니다. 운용을 검토중이시거나 운용 중이신 분들, NoSQL로 선정 고려중이신 분께 도움이 되면 좋겠네요.
- 인덱스 작성시 쿼리와 1:1 대응 시켜라.
- 적합 인덱스를 못찾았을 경우 rejectPlan을 타게 되는데 이 때, 매우 비효율적인 연산이 일어날 확률이 컸다.
- 쿼리에 index가 의도대로 동작하지 않으면 hint를 줘라.
- 그럼에도 느리다면 대게는 hint를 잘못 준 것.
- group 연산시 인덱스에 없는 값을 필요로 할 경우, 해당 값에 대해 찾느라 디스크까지 내려갔다 오는 비용과 인덱스 못찾는 비용으로 소요 시간이 급격히 커질 수 있음에 유의하라.
- 즉 group 연산 내에 들어가는 컬럼이 모두 index에 존재해야 성능상 이득이 크다.
- group, match, project등의 연산도 모두 index에 존재해야 한다는 점에 유의하라.
- 즉 group 연산 내에 들어가는 컬럼이 모두 index에 존재해야 성능상 이득이 크다.
- 메모리를 확보하라. 인덱스가 메모리 영역에 올라와서 연산하기 때문에, VM이던 리얼 머신이건 램이 중요하다.
- explain을 통해서 인덱스를 어떻게 타는지 확인하라.
- winningPlan, rejectPlan을 참고하라.
- winningPlan을 탈 것인지, rejectPlan을 탈 것인지를 알려주지 않지만, winningPlan을 탈 가능성이 있는 쿼리라는 것은 확실히 알려준다.
- 메모리에 올라와있는 데이터냐 아니냐에 따라서 성능이 급격히 차이난다.
- 인덱스 크기를 메모리 용량보다 작게 사용할 수 있도록 하는 것을 권장한다.
- memory mapped file 기반이라는 것을 항상 유념해야 한다.
- 참고 자료
- 쿼리 튜닝
- 성능 개선 팁