Mongo Koleksiyon "Boyut", "storageSize" 'dan * daha büyük mü?

Son zamanlarda koleksiyonumu şu komutu kullanarak sıkıştırdım:

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

Ve şimdi koleksiyon boyutum diskteki boyuttan daha büyük görünüyor!

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

}

Bunun nasıl mümkün olduğunu anlamıyorum. Tüm mongodb koleksiyonları her zaman disk tarafından desteklenmiyor mu?

Herkes bu sonuçları açıklayabilir mi?

mongodb

— Chris W.
kaynak

Daha önce böyle istatistikler gördüm, ancak bir açıklamam yok. Bir validate?

— Eve Freeman

Yanıtlar:

storageSize dizinler hariç, bu veriler için tüm uzantıların toplamıdır.

Böylece toplama 2 uzantı alır, her biri ~ 2GB, dolayısıyla ~ 4GB. sizedizinleri içerir ve ben sayıyı şişiren birkaç şey inanıyorum. Her ikisi de gerçekten uygun disk üstü boyutunu temsil etmez. Disk boyutu için, db.stats()aradığınızı düşündüğünüze daha yakın bir dosya boyutu alanı var.

Kılavuz, çeşitli alanların ne anlama geldiğini özetlemekte biraz daha iyidir, koleksiyonlar için buraya bakın:

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

Ve burada veritabanı istatistikleri için:

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

Potansiyel olarak alakalı diğer bazı bilgiler:

Kompakt komut herhangi bir veri dosyasını küçültmez; yalnızca silinen alanı birleştirerek daha büyük nesnelerin yeniden kullanabilmesini sağlar. Kompakt komut hiçbir zaman veritabanı dosyalarını silmez veya küçültmez ve genel olarak işini yapmak için genellikle en az bir fazladan daha fazla alan gerektirir.

Eğer varsa tamir veritabanını aslında sen alacaksın verimli olarak diskte onları dolgu kaldırmak ve depolayacak sıfırdan veri dosyalarını yeniden. Ancak bunu yapmak için diskte ~ 2x boyutuna sahip olmanız gerekir (aslında daha az, ancak iyi bir kılavuzdur).

Burada akılda tutulması gereken başka bir şey - onarım ve kompakt kaldırmayı kaldırın. Doldurma faktörü 1 (büyüyen belgelerden kaynaklanan belgelerin taşınmaması) ile 2 (büyüyen belgelerden kaynaklanan birçok hamle) arasında değişir. ~ 1.67'lik doldurma faktörünüz biraz büyüyeceğinizi (ve dolayısıyla hareketlere neden olduğunuzu) gösterir.

Bir veritabanını sıkıştırdığınızda veya onardığınızda, bu dolguyu kaldırırsınız - bu nedenle sonraki belge büyümesi öncekinden daha fazla hamleyi tetikleyecektir. Hareketler nispeten pahalı işlemler olduğu için, bunun performansınız üzerinde ciddi bir etkisi olabilir. Daha fazla bilgi burada:

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

— Adam C
kaynak

@Adam yanıtınız için teşekkürler, dolgu faktörlerine ve sıkıştırmaya biraz aşinayım, bu durumda beni şaşırtan şey, ne kadar etkili bir sıkıştırma olursa olsun, veritabanında sakladığımızdan daha fazla veri depolayamamamız gerektiğidir hard disk! yani, 5.6GB mongo verisini 4.2GB diske nasıl sığdırırsınız?

— Chris W.

4.2GB disk sadece veri, 5.6GB veri artı dizinler ve daha sonra gerçek disk boyutu için muhtemelen veritabanı seviyesi istatistiklerine bakmanız gerekecek

— Adam C

Aynı şeyle karşılaştım! Garip olan şey, belgelerinde boyutun dizinleri hesaba katmadığıdır: "Ayrıca boyut, totalIndexSize alanının bildirdiği koleksiyonla ilişkili herhangi bir dizinin boyutunu içermez."

— MatijaSh

Bunun nedeni, boyutun sıkıştırılmamış veri boyutunu görüntülemesi olabilirken, depolama boyutu hesaba sıkıştırılır. Burada db düzeyinde açıklanmıştır, ancak koleksiyon için de geçerli gibi görünüyor: docs.mongodb.com/manual/reference/command/dbStats/…

— MatijaSh

Mongodb için> 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 ('ad') istatistikleri için ()

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 () için

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

Kullanılmayan alanı veya deliği bu şekilde silebiliriz

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

Kompakt veya onarım komutunu çalıştırdıktan sonra tam depolama boyutu ve veri boyutu farkı elde edebiliriz.

Mongodb kabloluda Sıkıştırma Tekniği

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

— Kamal Kumar
kaynak