I am using mongo v3.4.10 with WiredTiger. I run the following command:
db.runCommand({ compact: "my_collection" });
the response is:
/* 1 */
{
"ok" : 1.0
}
and the mongo log shows:
2017-10-31T00:12:20.282+0000 I COMMAND [conn23] compact mydb.my_collection begin, options: paddingMode: NONE validateDocuments: 1
2017-10-31T00:12:21.662+0000 I COMMAND [conn23] compact mydb.my_collection end
2017-10-31T00:12:21.663+0000 I COMMAND [conn23] command mydb.my_collection appName: "MongoDB Shell" command: compact { compact: "my_collection" } numYields:0 reslen:22 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { W: 1 } } } protocol:op_command 1381ms
In short, everything looks fine, but the storageSize is exactly the same :/
I deleted lots of fields with a value of null
, so I would expect a significant drop in disk usage.
I read online that early v3 had issues with this, but I'm on the latest version right now. The database is quite large so if I can avoid repairDatabase
that would be good.
Any help is appreciated, thx.
UPDATE: I performed a mongodump / mongorestore, and it resulted in a 9% disk use reduction (admittedly I was expecting more). Nonetheless, it seems like compact should have had an impact.
UPDATE 2: I performed a repairDatabase and it had no effect. This is explicitly stated in mongo docs (https://docs.mongodb.com/manual/reference/command/repairDatabase):
For WiredTiger, the operation rebuilds the database but does not result in the compaction of the collections in the database
but i thought i'd give it a crack. Still not sure why compact did nothing though.
{ "name": null }
the keyname
will take space when stored in a bson document.