MongoDB에서 실행 계획 확인하는 방법

MongoDB에서 실행계획을 선택하는 방법

주요 로직

  • RDBMS 와 비교했을 때 MongoDB는 각 컬렉션에 대한 통계 정보가 거의 없다.

  • MongoDB는 규칙 기반의 옵티마이저 (rule-based optimizer)

  • 규칙기반 옵티마이저는 RDBMS에서 허점이 많아서 거의 사용하지 않는 최적화 방법

  • MongoDB는 실행 계획 후보를 모두 동시에 실행(쿼리의 일부분만)해보는 형태로 단점을 보완

  예시

     1) 한 쿼리에 대해 실행계획 후보가 3개

     2) 3개를 동시에 쿼리 실행

     3) 3개 중에서 어느 하나라도 먼저 실행이 완료되거나 101건의 도큐먼트를 먼저 검색하는 경우 멈추게 된다.

        • 101건이 많다고 생각되면 기본값을 변경할 수 있다. 하지만 바꾸려면 collFration과 works 옵션도 같이 조정하는 것이 좋다.

        • 이때 선택된 플랜을 winning plan이라고 한다.

 

 

플랜 캐시

  • 플랜 캐시란?

      • 최적의 쿼리 실행계획이 수립되기 위해서 실행 계획을 직접 실행한다.

      • 이런 이유로 실행 계획을 수립하는 과정 자체도 많은 시간이 걸릴 수 있어서 캐시를 이용한다.

 

• 캐시 사이즈

      • 최대 5000개(MongoDB 3.6 기준)

      • 5000개가 넘으면 사용되지 않는 실행계획이 캐시에서 삭제

      • 해당 컬렌션의 인덱스가 추가 또는 삭제되는 경우에도 캐시 삭제

      • 5000이라는 숫자는 db.runCommand( {setParameter:1, internalQueryCacheSize: 6000 }) 변경 가능

 

  • 같은 패턴의 쿼리인지 확인하는 방법

      • 같은 패턴의 쿼리라면 플랜캐시 활용한다.

        • Query Shape

        • 쿼리 조건(query predicate)

        • 정렬조건(sort)

        • 조회필드(projection)

 

  • 플랜캐시의 성능이 아직도 유효한지 체크하는 방법

      • 플랜캐시에서 꺼내기 → 성능 재평가

      • 지정된만큼의 도큐먼트만 읽어서 internalQueryPlanEvalueionMaxResults 에 정의한 수만큼 도큐먼트를 가져올 수 있는지 판단하는 형태

      • 최초 실행계획을 수립할 때 work() 함수의 호출 횟수 x internalQueryCaheEvictionRatio

      • 쿼리 재평가 과정도 결국 쿼리의 일부를 실행해보는 과정이다. 만약 실행 계획 수립과정이 커리 처리 성능에 미치는 영향이 큰 서비스라면 이 옵션을 좀 더 낮은 수치로 조정해서 성능 테스트를 해봐도 좋을 듯하다.. 라고 권유하고 있다.

 

실행 계획 확인

QueryPlanner

: 디폴트이며, 가장 단순한 실행계획 출력한다.

: 어떤 인덱스를 사용했는가 정도를 나타낸다.

- 실행 쿼리

 

 

ExecutionStats

: 선택한 실행계획의 상세한 내용까지 출력한다.

- 실행 쿼리

  • 주요 확인 요소

     • nReturned : 실제 클라이언트로 반환된 도큐먼트의 건수

     • executionTimeMillis : 각 스테이지의 실행 시간

     • totalKeyExamined : 쿼리를 처리하기 위해서 인덱스에서 읽은 인덱스 키의 개수

     • totalDocsExamined : 쿼리를 처리하기 위해서 컬렉션의 데이터 파일에서 읽은 도큐먼트의 개수

 

 

+) works?

• 각 스테이지들이 자식 스테이지의 work()를 호출한 횟수

• work() 호출은 도큐먼트 단위로 호출

• work()함수 호출은 대표적으로 다음 3종류의 리턴 값을 반환

    • ADVANCE

       : 스테이지의 처리 결과 한건의 도큐먼트 또는 ID(프라이머리 키) 값을 반환

    • NEED_TIME

       : 스테이지 처리는 완료되었지만, 결과 도큐먼트나 ID 값은 반환되지 않음.

       : 주로, 블로킹 스테이지일때 발생

       : 대표적인 블로킹 스테이지는 인덱스를 사용하지 못하는 정렬이나 그룹핑 스테이지, 인덱스를 사용하지 못하는 필터링 스테이지
      ex) 인덱스를 이용해서 도큐먼트 한건을 읽었는데, 이 도큐먼트가 다른 조건(인덱스를 사용하지 못하는 경우)에 의해서 버려지는 경우다.

      : 얼마나 도큐먼트를 읽고 버렸는지, 얼마나 정렬 수행을 했는지를 확인할 수 있다.

    • IS_EOF

      : 스테이지 처리를 완료했으며, 더 이상 읽을 도큐먼트나 ID가 없다.

 

AllPlansExecution

: 모든 실행 계획 후보들까지 실행한다.

- 실행 쿼리

Explain Results

• 루트 스테이지에서 하위 스테이지를 콜한다.

• 실제로 수행되는 것은 루트 스테이지에서 부터이다.

 

• stage 예시

    • COLLSCAN : 컬렉션 풀 스캔

    • IXSCAN : 인덱스 레인지 스캔

    • FETCH : 인덱스 레인지 스캔으로 읽은 인덱스키와 recordId를 이용해서 컬렉션의 도큐먼트를 읽기

    • SORT

    • COUNT

    • LIMIT

    • GROUP

 

MongoDB Compass에서 실행시

 

Ref.

대용량 데이터 처리를 위한 Real MongoDB : 이성욱, 2018, 위키북스