Bộ sưu tập Mongo `Size` lớn hơn * so với` StorageSize`?

Gần đây tôi đã thu gọn bộ sưu tập của mình bằng lệnh:

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

Và bây giờ kích thước bộ sưu tập của tôi dường như lớn hơn kích thước trên đĩa!

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

}

Tôi không hiểu làm thế nào điều này là có thể. Không phải tất cả các bộ sưu tập mongodb được sao lưu bởi đĩa mọi lúc?

Bất cứ ai có thể giải thích những kết quả này?

storageSize là tổng của tất cả các phạm vi cho dữ liệu đó, ngoại trừ các chỉ mục.

Vì vậy, bộ sưu tập đó chiếm tới 2 phạm vi, mỗi bộ có ~ 2GB, do đó ~ 4GB. sizebao gồm các chỉ số và tôi tin rằng một vài thứ khác làm tăng số lượng. Không thực sự đại diện cho kích thước trên đĩa thích hợp. Đối với kích thước đĩa, db.stats()có trường kích thước tệp gần với những gì bạn muốn tôi nghĩ bạn đang tìm kiếm.

Hướng dẫn có phần tốt hơn trong việc phác thảo ý nghĩa của các lĩnh vực khác nhau, xem tại đây để biết các bộ sưu tập:

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

Và ở đây để thống kê cơ sở dữ liệu:

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

Một số thông tin có khả năng liên quan khác:

Lệnh rút gọn không thu nhỏ bất kỳ tệp dữ liệu nào; nó chỉ chống phân mảnh không gian bị xóa để các đối tượng lớn hơn có thể sử dụng lại nó. Lệnh rút gọn sẽ không bao giờ xóa hoặc thu hẹp các tệp cơ sở dữ liệu và nói chung cần thêm không gian để thực hiện công việc của nó, thường là tối thiểu một phạm vi bổ sung.

Nếu bạn sửa chữa cơ sở dữ liệu, về cơ bản nó sẽ ghi lại các tệp dữ liệu từ đầu, việc này sẽ loại bỏ phần đệm và lưu trữ chúng trên đĩa hiệu quả như bạn sẽ nhận được. Tuy nhiên, bạn sẽ cần phải có ~ gấp đôi kích thước trên đĩa để làm như vậy (thực tế ít hơn, nhưng đó là một hướng dẫn tốt).

Một điều khác cần lưu ý ở đây - sửa chữa và nhỏ gọn đệm. Hệ số đệm khác nhau giữa 1 (không di chuyển tài liệu do tài liệu phát triển), thành 2 (rất nhiều di chuyển do tài liệu phát triển). Hệ số đệm của bạn là ~ 1,67 sẽ cho thấy bạn đang phát triển (và do đó gây ra các bước di chuyển) khá nhiều.

Khi bạn thu gọn hoặc sửa chữa một cơ sở dữ liệu, bạn sẽ loại bỏ phần đệm đó - do đó sự tăng trưởng tài liệu tiếp theo sẽ kích hoạt nhiều chuyển động hơn trước. Bởi vì di chuyển là hoạt động đắt tiền, điều này có thể ảnh hưởng nghiêm trọng đến hiệu suất của bạn. Thêm thông tin ở đây:

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

Đối với 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)

Đối với 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)

Đối với db.stats ()

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

Chúng ta có thể xóa không gian hoặc lỗ không sử dụng bằng cách này

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

Sau khi chạy lệnh compact hoặc sửa chữa, chúng ta có thể nhận được kích thước lưu trữ chính xác và chênh lệch kích thước dữ liệu.

Kỹ thuật nén trong mongodb WiredTiger:

- snappy : good compression, low overhead
- zlib: better compression, more CPU
- none (we can disable compression, by default its enable in WT)