Bumped by Community user
    Bumped by Community user
2 added 465 characters in body
source | link

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

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?

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

1
source | link

Compression in MongoDb 3.2 does not work

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?