MongoDB 120M 문서의 집합

조치로 항목을 기록한 시스템이 있습니다. 120M 이상이 있으며 id_entry로 집계하여 그룹화하려고합니다.MongoDB 120M 문서의 집합

entry 
{ 
    id_entry: ObjectId(...), 
    created_at: Date(...), 
    action: {object}, 
}

내가 id_entry로하고 작업을 그룹화 완료 될 때까지 3 시간 이상 소요 집계를 수행하려고 :

db.entry.aggregate([ 
{ '$match': {'created_at': { $gte:ISODate("2016-02-02"), $lt:ISODate("2016-02-03")}}}, 
{ '$group': { 
    '_id' :{'id_entry': '$id_entry'}, 
    actions: { 
     $push: '$action' 
    } 
}}])

을하지만 일의 범위는 거기 구조는 다음과 같다 약 4 백만 건의 문서. (id_entry 및 created_at에는 색인이 있습니다.)

총계에서 내가 뭘 잘못하고 있니? 3M 미만의 문서를 id_entry로 그룹화하려면 어떻게해야합니까? 감사합니다.

출처

2016-08-07 Amarant

'created_at'에 대한 색인이 있습니까? 'db.entry.find ({'created_at ': {$ gte : ISDate ("2016-02-02"), $ lt : ISODate ("2016-02-03")}}) ? – DmitryZyr

안녕하세요 @ DmitryZyr, 답변 해 주셔서 감사합니다. 이 쿼리는 0.057 초가 걸리고 2.703.103 개의 문서를 검색합니다. 큰 문제는 2,700 만 문서를 그룹화하는 것입니다 ... – Amarant

특정 쿼리의 속도를 높이려면 created_at 필드에 인덱스가 필요합니다.

그러나 집계의 전반적인 성능은 하드웨어 사양에 따라 달라집니다.

당신은 당신이 무엇을 필요 이하로 쿼리의 성능을 발견하면, 당신도 할 수 있습니다

당신이 필요로 집계 된 데이터가 포함 된 pre-aggregated report (기본적으로 문서, 업데이트 된 새로운 데이터가 모든 시간을 만들기 삽입 됨) 또는
sharding을 사용하여 더 많은 서버로 데이터를 확산시킬 수 있습니다. 이 집계 쿼리 모든 시간을 실행해야하는 경우

은 사전 집계 보고서는 간단한 find() 쿼리를 사용하여 액세스 할 수있는 데이터의 매우 최신 집계 보고서를 가질 수 있습니다.

삽입 할 때마다 데이터의 현재 상태를 반영하여 사전 집계 된 문서를 업데이트해야한다는 단점이 있습니다. 그러나 이것은 일상적인 작업을 방해 할 수있는 길고 복잡한 집계 쿼리를 실행해야하는 것과 비교할 때 상대적으로 작은 트레이드 오프입니다.

집계 프레임 워크가있는 한 가지주의 사항은 집계 파이프 라인이 $group 또는 $project 단계를 만나면 색인을 사용할 수 없습니다. 이것은 MongoDB 인덱스가 문서가 물리적으로 저장되는 방법과 관련되어 있기 때문입니다. 문서를 그룹화하고 투영하면 문서가 더 이상 디스크에 물리적 표현이없는 상태로 변환됩니다.

출처

2016-08-07 23:53:03

MongoDB 120M 문서의 집합

답변

관련 문제