Mongo Collection`Size`가`storageSize`보다 * 더 큽니까?


9

최근에 다음 명령을 사용하여 컬렉션을 압축했습니다.

 db.<collectionName>.runCommand( "compact" )

이제 내 컬렉션 크기가 디스크의 크기보다 큰 것 같습니다!

SECONDARY> db.<collectionName>.stats()
{
"ns" : "<databaseName>.<collectionName>",
"count" : 2937359,
"size" : 5681676492,                   # 5.6 GB
"avgObjSize" : 1934.2805874256433,
"storageSize" : 4292853728,            # 4.2 GB
"numExtents" : 2,
"nindexes" : 2,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1.669999999836597,
"flags" : 1,
"totalIndexSize" : 220735648,
"indexSizes" : {
    "_id_" : 162326304,
    "e_1_" : 58409344
},
"ok" : 1

}

이것이 어떻게 가능한지 이해하지 못합니다. 모든 mongodb 모음이 항상 디스크별로 백업되지 않습니까?

누구든지이 결과를 설명 할 수 있습니까?


이전과 같은 통계를 보았지만 설명이 없습니다. validate?를 실행 해보십시오 .
— Eve Freeman

답변:


6

storageSize 인덱스를 제외한 해당 데이터에 대한 모든 범위의 합계입니다.

따라서 컬렉션은 2 개의 익스텐트를 차지하므로 각각 ~ 2GB, 따라서 ~ 4GB입니다. size색인을 포함하고 숫자를 부 풀리는 다른 두 가지가 있다고 생각합니다. 실제로 적절한 온 디스크 크기를 나타내는 것은 아닙니다. 디스크 크기의 경우 db.stats()원하는 크기에 가까운 파일 크기 필드가 있습니다.

매뉴얼은 다양한 필드의 의미를 요약하는 데 다소 우수합니다. 콜렉션은 여기를 참조하십시오.

http://docs.mongodb.org/manual/reference/collection-statistics/

데이터베이스 통계는 다음과 같습니다.

http://docs.mongodb.org/manual/reference/database-statistics/


잠재적으로 관련된 기타 정보 :

compact 명령은 데이터 파일을 축소하지 않습니다. 더 큰 객체가 재사용 할 수 있도록 삭제 된 공간 만 조각 모음합니다. compact 명령은 데이터베이스 파일을 삭제하거나 축소하지 않으며 일반적으로 작업을 수행하는 데 추가 공간이 필요하며 일반적으로 최소 1 개의 추가 범위입니다.

데이터베이스 를 복구 하면 기본적으로 데이터 파일을 처음부터 다시 작성하여 패딩을 제거하고 원하는만큼 효율적으로 디스크에 저장합니다. 그러나 그렇게하려면 디스크의 크기가 ~ 2 배가되어야합니다 (실제로는 적지 만 괜찮은 가이드입니다).

여기서 염두에 두어야 할 또 다른 사항은 패딩을 수리하고 컴팩트하게 제거하는 것입니다. 패딩 계수는 1 (문서 증가로 인한 문서 이동 없음)에서 2 (문서 증가로 인한 많은 이동) 사이에서 다양합니다. 패딩 팩터 ~ 1.67은 상당히 커지고 있음을 나타냅니다.

데이터베이스를 압축하거나 복구 할 때 해당 패딩을 제거하면 후속 문서 증가로 인해 이전보다 훨씬 많은 이동이 발생합니다. 이동은 비용이 많이 드는 작업이므로 성능에 심각한 영향을 줄 수 있습니다. 여기에 더 많은 정보가 있습니다 :

http://www.mongodb.org/display/DOCS/Padding+Factor


@Adam의 답변에 감사드립니다. 패딩 요소와 압축에 어느 정도 익숙합니다.이 인스턴스에서 나를 혼동하는 것은 아무리 효과적인 압축이더라도 데이터베이스에 저장하는 것보다 더 많은 데이터를 저장할 수 없어야한다는 것입니다 하드 디스크! 즉, 5.6GB의 몽고 데이터를 4.2GB의 디스크에 어떻게 맞습니까?
— Chris W.

4.2GB의 디스크는 단지 데이터이고, 5.6GB는 데이터와 색인이며, 실제 디스크 크기의 경우 데이터베이스 수준 통계를 살펴 봐야합니다.
— Adam C

나는 같은 것을 만났다! 이상한 점은 그들의 문서에서 size는 인덱스를 설명하지 않는다고 말합니다. "Additional size는 컬렉션과 관련된 인덱스의 크기를 포함하지 않으며 totalIndexSize 필드가보고합니다."
— MatijaSh

크기는 압축되지 않은 데이터 크기를 표시하고 스토리지 크기는 압축을 고려하기 때문일 수 있습니다. 여기에 db 레벨에 설명되어 있지만 콜렉션에도 적용 가능한 것 같습니다. docs.mongodb.com/manual/reference/command/dbStats/…
— MatijaSh

1

mongodb> 3.x의 경우

For MMAPv1: 
datasize < storageSize

but For wiredTiger
datasize > storageSize (most cases due to compression but may be
                        storageSize greater, it varies on condition like
                        compression technique, whether compact/repair 
                        command run or not)

db.getCollection ( 'name'). stats ()의 경우

size = total size in memory of all records in a collection + padding (excluded index size + record header which is 16 byte per header, header means  = field name)        
avgObjSize = avg size of obj + padding
storageSize =  total amount of storage allocated to this collection for document storage. (totalIndex size excluded)
totalIndexSize : totalIndexSize (compressed in case of wiredTiger)

db.stats ()의 경우

dataSize = document + padding
storageSize = document + padding + deleted space
fileSize = document + padding extents +  index extents + yet-unused space

이것에 의해 미사용의 공간이나 구멍을 삭제할 수 있습니다

db.getCollection('name').runCommand( "compact" )

압축 또는 복구 명령을 실행 한 후 정확한 스토리지 크기와 데이터 크기 차이를 얻을 수 있습니다.

mongodb 유선의 압축 기술

- snappy : good compression, low overhead
- zlib: better compression, more CPU
- none (we can disable compression, by default its enable in WT)
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.