1

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

  • What kind of data are yo adding to your collection – Priyanka Kariya Aug 29 '16 at 5:20
  • Sorry, forgot to mention that it contains regular bson text, not binary data. .net driver parses .net objects into bson 5kb objects (unpacked size) – YMC Aug 29 '16 at 15:07
  • insert a few thousand documents and then compare - I suspect you don't have enough data to show any meaningful effects – Adam C Aug 29 '16 at 20:43
  • That's true as @AdamC has mentioned, have a larger data and Compare – Priyanka Kariya Aug 30 '16 at 4:26
  • @AdamC, I used 1188 examples and got some encouraging results on compression for snappy over no-compression, though would still expect better compression ratio. The strange thing zlib did not show any improvements over snappy. Please see updated question for more information. Thanks – YMC Aug 30 '16 at 16:44
0

--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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.