2016-11-03 4 views
1

우리는 Mongodb에서 우리 컬렉션을 대부분 사용합니다.MongoDB 집계 쿼리 실행 속도가 매우 느림

db.docs.aggregate([ 
    {"$sort":{"docId":-1,"v":-1}}, 
    {"$group":{"_id":"$docId","doc":{"$first":"$$ROOT"}}} 
    {"$match":{<query>}} 
]); 

: 그래서

{ "docId" : 174, "v" : 1, "attr1": 165 } /*version 1 */ 
{ "docId" : 174, "v" : 2, "attr1": 165, "attr2": "A-1" } 
{ "docId" : 174, "v" : 3, "attr1": 184, "attr2" : "A-1" } 

우리는 우리의 쿼리를 수행 할 때 우리는 항상 우리의 객체의 최신 버전을 얻을 수 있도록하기 위해이 방법으로 통합 프레임 워크를 사용할 필요가, 다음과 같이 선택한 버전의 메커니즘입니다 이 접근법의 문제점은 일단 그룹화를 완료하면 컬렉션에 아무런 관련이없는 메모리 세트가 생겨 인덱스를 사용할 수 없다는 것입니다.

결과적으로 컬렉션의 문서가 많을수록 쿼리 속도가 느려집니다.

속도를 향상시킬 방법이 있습니까?

하지 않은 경우, 나는이 좋은 게시물에 정의 된 방법 중 하나로 이동 고려할는 : 하나 명의 컬렉션을 최신 버전으로 유지하고 하나 http://www.askasya.com/post/trackversions/

+0

왜 처음 단계에서 $가 맞지 않았습니까? –

+0

문서의 docId 입력란에 색인을 추가하십시오. –

+0

@DanieleTassone 옵션이 아닌 것 같습니다. 설명은 내가 제공 한 링크에 있습니다. 기본적으로 필터를 처음 시작할 때 가장 최근 버전이 아닌 버전으로 끝나지 만 정렬 그룹 단계에서 해당 버전을 고려하게됩니다. 이와 같이 버전 관리를 수행하는 것은 일반적인 오류입니다. – jbernal

답변

0

그냥이 질문을 완료하기 위해, 우리는 옵션 3와 함께 갔다 역사적인 것을 지키기위한 수집. 여기에 소개되어 있습니다 : http://www.askasya.com/post/trackversions/ 및 일부 자세한 설명 (일부 멋진 코드 스 니펫 포함)은 http://www.askasya.com/post/revisitversions/에서 찾을 수 있습니다.

현재 6 개월 동안 운영되고 있습니다. 여태까지는 그런대로 잘됐다. 이전 접근 방식은 원래 스키마를 수정할 때 ($ group, $ project ...를 사용하여) 원본 컬렉션을 더 이상 일치시키지 않으면 인덱스에서 멀리 이동하는 집계 프레임 워크를 항상 사용한다는 것을 의미했습니다. 이로 인해 데이터가 커짐에 따라 실적이 저조했습니다.

새로운 접근 방식으로 문제가 해결되었지만 우리 쿼리의 90 %가 최신 데이터와 비교됩니다. 즉, ObjectId이라는 식별자를 식별자로 사용하여 컬렉션을 대상으로하므로 더 이상 집계 프레임 워크가 필요하지 않습니다. 히스토리 데이터에 대한

우리의 쿼리가 항상 (그래서 우리는 상자 밖으로 그것을 얻을 모두 _id 우리가 포함)이 색인에 의해 idversion를 포함하는 컬렉션을 동등하게 빠르다으로 읽습니다. 이것은 간과하지는 않지만 요점입니다. MongoDB에서 콜렉션/스키마가 어떻게 보이는지 디자인 할 때 응용 프로그램의 패턴을 읽는 것이 중요합니다. 따라서 이러한 결정을 내릴 때 반드시 알고 있어야합니다.

관련 문제