[MongoDB] 실행 계획 및 쿼리 최적화(2)

 

쿼리 최적화

MongoDB 의 쿼리 튜닝에서 주의 깊게 살펴봐야 할 부분과 성능 튜닝이 필요한 쿼리를 수집하는 방법을 알아본다.

 

실행 계획의 쿼리 튜닝 포인트

- 쿼리가 인덱스를 사용하는가 ?

- 도큐먼트 정렬이 인덱스를 사용하는가 ?

- 필드 프로젝션이 인덱스를 사용하는가 ?

- 인덱스 키 엔트리와 도큐먼트를 얼마나 읽었는가 ?

- 인덱스의 선택도는 얼마나 좋은가 ?

- 어떤 스테이지가 가장 많은 시간을 소모하는가 ?

 

슬로우 쿼리 로그 분석 및 튜닝

MongoDB 서버에서 실행된 쿼리 중 100 밀리초가 넘게 걸린 쿼리는 MongoDB 서버의 로그 파일에 모두 로깅된다.

100 밀리초는 기본값으로 slowMs 옵션을 조정하면 로깅 시간을 조정할 수 있다.

 

MongoDB 서버의 로그 파일에 기록된 슬로우 쿼리 로그에서 주로 성능과 관련해 살펴봐야 할 부분은 planSummary, keysExamined, docsExamined, numYields 정도이다.

옵션	설명
planSummary	인덱스 레인지 스캔을 실행했는지 또는 컬렉션 풀 스캔을 사용하는지 보여줌
keysExamined docExamined	쿼리를 처리하기 위해 읽은 인덱스 키의 개수와 도큐먼트 건수를 보여줌 이 두 값의 차이를 비교해 사용한 인덱스가 얼마나 효율적인지 실제 랜덤 액세스 방식으로 도큐먼트를 얼마나 읽었는지 확인할 수 있음
numYields	쿼리가 장시간 실행되면서 다른 커넥션들이 쿼리를 실행할 수 있도록 잠금을 해제했다가 다시 잠금을 획득하는 과정을 얼마나 자주 반복했는지 알 수 있음

 

만약 로그 레벨을 디폴트 값보다 더 자세히 또는 더 다순한게 변경하고자 한다면 setLogLevel 명령을 이용해 서브 모듈별로 로그 레벨을 조정할 수 있다.

 

쿼리 프로파일링

로그 파일에는 매우 많은 정보가 기록되며, 때로는 MongoDB 서버의 로그 파일로 슬로우 쿼리 로그 정보를 수집하는 것이 어려울 수도 있다.

이런 경우 데이터베이스별로 저장되는 쿼리 프로파일링 정보를 확인하는 것이 좋다.

 

MongoDB 는 데이터베이스별로 50~100밀리초 이상 수행된 쿼리들에 대해 슬로우 쿼리 정보와 함께 쿼리의 프로파일링 정보를 동시에 저장한다.

 

system.profile 컬렉션은 Cap 컬렉션으로 1MB 정도의 슬로우 쿼리만 저장할 수 있다.

그리고 1MB 를 넘어서면 오래된 로그는 삭제하고 새로 발생한 슬로우 쿼리 로그를 저장한다.

그래서 system.profile 컬렉션의 슬로우 쿼리 로그를 확인할 때는 다음과 같이 역순으로 정렬해야 시간순으로 볼 수 있다.

또한 system.profile 은 컬렉션이나 커맨드의 종류별로 필터링해서 슬로우 쿼리 로그를 확인할 수 있는 장점도 제공한다.

 

인덱스 힌트

대부분 경우 옵티마이저가 최적의 인덱스를 이용해서 쿼리를 처리하지만 항상 그런 것은 아니다.

가끔씩 쿼리의 검색 조건이나 정렬 조건을 만족할 수 있는 다양한 인덱스의 컬렉션에서는 옵티마이저가 좋지 않은 인덱스를 사용해서 쿼리를 실행하는 경우도 있다. 이런경우 인덱스 힌트를 이용해 쿼리의 실행 계획을 다른 방향으로 유도할 수 있다.

 

MongoDB 의 인덱스 힌트는 인덱스의 이름을 직접 사용할 수도 있고 인덱스의 형태를 명시할 수도 있다.

쿼리 힌트에 인덱스의 구조를 사용하는 방법은 인덱스가 변경되면 응용 프로그램에서 사용되는 쿼리문장의 인덱스 힌트도 항상 같이 변경되어서 배포되어야 한다.

 

인덱스를 통해 많은 도큐먼트를 랜덤 액세스 방식으로 찾는 것은 상당히 고비용의 작업이기 때문에 때로는 인덱스를 사용하지 않고 컬렉션을 풀 스캔하는 것이 더 빠른 방법이 될 수 있다.

이런 현상은 주로 배치 작업이나 통계성 작업의 무거운 쿼리에서 자주 발생하는데, 이런 경우 다음과 같이 $natural 힌트를 명시한다.