I installed MongoDb 3.2, and configured snappy compression in mongodb configuration file:
engine: wiredTiger
wiredTiger:
engineConfig:
cacheSizeGB: 99
journalCompressor: none
collectionConfig:
blockCompressor: snappy
indexConfig:
prefixCompression: true
However I do not think compression actually work as I could see average object size in the collection is about the same (I filled collection created from scratch by the same objects right after configuration change and service restart):
MMAPv1 no-compression avgObjSize: 5kb
WiredTiger snappy avgObjSize: 4kb
WiredTiger zlib avgObjSize: 4kb
when I run stats on collection here is what I see for "snappy":
"compression" : {
"compressed pages read" : NumberInt(0),
"compressed pages written" : NumberInt(5),
"page written failed to compress" : NumberInt(0),
"page written was too small to compress" : NumberInt(4),
"raw compression call failed, additional data available" : NumberInt(0),
"raw compression call failed, no additional data available" : NumberInt(0),
"raw compression call succeeded" : NumberInt(0)
},
for zlib:
{
"compressed pages read" : NumberInt(0),
"compressed pages written" : NumberInt(1),
"page written failed to compress" : NumberInt(0),
"page written was too small to compress" : NumberInt(3),
"raw compression call failed, additional data available" : NumberInt(0),
"raw compression call failed, no additional data available" : NumberInt(1),
"raw compression call succeeded" : NumberInt(2)
}
Not sure how to read this info, and not sure how can I detect what's wrong with compression.
I should also say I had only few (like 10) objects in each scenario. Would it be enough to accurately measure average object compression ratio?
UPDATE: with 1188 documents mongodb ver3 shown around 50% better compression ratio comparing to mongodb ver2.6 (MMAPv1), however got no difference between snappy and zlib: dataSize and avgObjSize are the same for some reason. When I request statistics it shown WiredTiger:creationString:…block_compressor=zlib.. for the first database and block_compressor=snappy for the second one, so databases and collections seemed to be created with right compression algorithms
Best Answer
--version 3.4.10 Enterprise
compression will not change the avgObjSize. It will just improve the compression ratio saving disk space; I tested it for a collection (documents: 11553423 and avgObjSize= 6182) worth 21GB with snappy, when same created with zlib, size of collection reduced to 12GB (avgObjSize= 6182).