programing

수백만 개의 레코드가 있을 때 몽고 카운트는 정말 느립니다.

showcode 2023. 6. 19. 21:47
반응형

수백만 개의 레코드가 있을 때 몽고 카운트는 정말 느립니다.

//FAST
db.datasources.find().count()
12036788

//SLOW    
db.datasources.find({nid:19882}).count()
10161684

nid의 인덱스

두 번째 질문을 더 빨리 할 수 있는 방법이 있습니까?(약 8초 정도 걸립니다)

MongoDB가 기준과 일치하는 문서의 적절한 수를 찾기 위해 전체 b-tree 워크를 수행해야 하기 때문에 인덱스가 있든 없든 카운트 쿼리는 느립니다.그 이유는 MongoDB b-tree 구조가 "카운트"되지 않기 때문입니다. 즉, 각 노드는 노드/하위 트리의 요소 수에 대한 정보를 저장하지 않습니다.

이 문제는 https://jira.mongodb.org/browse/SERVER-1752 에서 보고되며, 현재 몇 가지 단점이 있는 컬렉션에 대한 카운터를 수동으로 유지 관리하는 것 외에는 성능을 개선하기 위한 해결 방법이 없습니다.

또한 db.col.count() 버전(따라서 기준 없음)은 큰 바로 가기를 사용할 수 없으며 실제로 쿼리를 수행하지 않으므로 속도가 빨라집니다.즉, 모든 요소를 반환해야 하는 카운트 쿼리와 항상 동일한 값을 보고하지는 않습니다(예: 쓰기 처리량이 높은 공유 환경에서는 그렇지 않음).그것이 버그인지 아닌지에 대한 논쟁이 있습니다.그런 것 같아요.

2.3+에서는 인덱스 필드의 카운트 성능을 개선해야 하는(그리고 개선해야 하는) 상당한 최적화가 도입되었습니다.참조: https://jira.mongodb.org/browse/SERVER-7745

@Remon이 말했듯이, count()는 쿼리/필터와 일치하는 모든 문서를 스캔해야 합니다.여기서 n은 색인과 일치하는 문서의 수 또는 필드가 색인화되지 않은 경우 집합의 문서 수입니다.

이러한 경우 일반적으로 요구 사항을 다시 검토하려고 합니다.결과 10161684에 대한 정확한 번호가 꼭 필요합니까?정밀도가 중요한 경우 특정 쿼리에 대해 별도의 카운터를 유지해야 합니다.

하지만 대부분의 경우 정밀도는 중요하지 않습니다.둘 중 하나입니다.

  • 천만이든, 1,020만이든 상관없지만 규모의 순서가 중요하다, 즉 800만이든, 1,000만이든 신경을 쓰는 겁니다.
  • 정확한 숫자는 작은 숫자만 신경 쓰시면 됩니다.즉, 44개의 결과 또는 72개의 결과가 있다는 것을 알고자 합니다.그러나 예를 들어 1000개를 넘어서면 사용자에게 '1000개 이상의 개체'를 찾을 수 있습니다.

제 앱에서 두 번째 옵션은 제가 원하는 것이라는 것을 발견했습니다.따라서 제한에 도달하면 카운트가 중지되도록 count() 쿼리도 제한합니다.이와 같은 경우:

db.datasources.find({nid: 19882}).limit(1000).count(true)

카운트가 1000이면 사용자에게 '1000 이상의 결과를 찾았습니다'를 표시하고, 그렇지 않으면 정확한 숫자를 표시합니다.

첫 번째 옵션은...저는 아직 깔끔한 해결책을 생각하지 못했습니다.

그것은 모든 문서의 모든 분야를 두 번째로 살펴봐야 합니다.색인화할 수 있습니다.nid계산을 더 빠르게 하기 위해서.

언급URL : https://stackoverflow.com/questions/9778420/mongo-count-really-slow-when-there-are-millions-of-records

반응형