Mongo Collection `ขนาด 'ใหญ่กว่า * พื้นที่เก็บข้อมูลขนาด'?

ฉันเพิ่งกระชับคอลเลกชันของฉันโดยใช้คำสั่ง:

 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 ไม่ได้สำรองข้อมูลไว้ตลอดเวลาหรือไม่

ใครสามารถอธิบายผลลัพธ์เหล่านี้ได้บ้าง

storageSize คือผลรวมของขอบเขตทั้งหมดสำหรับข้อมูลนั้นไม่รวมดัชนี

ดังนั้นคอลเล็กชั่นนั้นใช้เวลามากถึง 2 ขอบเขตพวกมันอยู่ที่ ~ 2GB ต่อหน่วยดังนั้นจึง ~ 4GB sizeรวมถึงดัชนีและฉันเชื่อว่ามีอีกสองอย่างที่ทำให้จำนวนเพิ่มขึ้น ไม่ได้แสดงถึงขนาดของดิสก์ที่เหมาะสม สำหรับขนาดดิสก์db.stats()มีฟิลด์ขนาดไฟล์ซึ่งใกล้เคียงกับที่คุณต้องการฉันคิดว่าคุณกำลังมองหา

คู่มือจะค่อนข้างดีกว่าเมื่อสรุปความหมายของฟิลด์ต่าง ๆ ดูที่นี่สำหรับคอลเลกชัน:

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

และที่นี่สำหรับสถิติฐานข้อมูล:

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

ข้อมูลอื่น ๆ ที่อาจเกี่ยวข้อง:

คำสั่งกระชับไม่ลดขนาดดาต้าไฟล์ใด ๆ เพียงจัดเรียงข้อมูลที่ถูกลบพื้นที่เพื่อให้วัตถุขนาดใหญ่อาจนำมาใช้ใหม่ คำสั่งขนาดกะทัดรัดจะไม่ลบหรือลดขนาดไฟล์ฐานข้อมูลและโดยทั่วไปต้องใช้พื้นที่เพิ่มเติมเพื่อทำงานของมันโดยทั่วไปแล้วจะต้องเพิ่มอย่างน้อยหนึ่งขอบเขต

หากคุณซ่อมแซมฐานข้อมูลมันจะทำการเขียนไฟล์ข้อมูลใหม่โดยเริ่มต้นจากศูนย์ซึ่งจะลบการขยายและเก็บไว้ในดิสก์อย่างมีประสิทธิภาพตามที่คุณจะได้รับ อย่างไรก็ตามคุณจะต้องมีขนาดประมาณ 2x บนดิสก์ (จริง ๆ แล้วน้อยกว่า แต่เป็นแนวทางที่ดี)

สิ่งอื่นที่ต้องคำนึงถึงที่นี่ - ซ่อมและกระชับลบการขยาย ปัจจัยการแพ็ดด์แตกต่างกันไประหว่าง 1 (ไม่มีการย้ายเอกสารที่เกิดจากการเติบโตของเอกสาร) ถึง 2 (การย้ายจำนวนมากที่เกิดจากการเติบโตของเอกสาร) ปัจจัยการขยายของคุณที่ ~ 1.67 จะบ่งบอกว่าคุณกำลังเติบโต (และทำให้เกิดการเคลื่อนไหว) เล็กน้อย

เมื่อคุณกระชับหรือซ่อมแซมฐานข้อมูลคุณลบการขยายนั้น - การเจริญเติบโตของเอกสารที่ตามมาจึงจะเรียกการเคลื่อนไหวมากขึ้นกว่าเดิม เนื่องจากการเคลื่อนไหวเป็นการดำเนินการที่มีราคาแพงอย่างไม่น่าเชื่อสิ่งนี้อาจส่งผลกระทบร้ายแรงต่อประสิทธิภาพการทำงานของคุณ ข้อมูลเพิ่มเติมที่นี่:

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

สำหรับ 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" )

หลังจากรันคำสั่ง compact หรือ repair เราจะได้ขนาดและพื้นที่เก็บข้อมูลที่แน่นอน

เทคนิคการบีบอัดใน mongodb wiredTiger:

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