Re: MongoDB: Change block_compressor for existing collection

From: Kevin Adistambha <kevinadi@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Thu, 21 Apr 2016 20:30:45 -0700 (PDT)
Why ads?


Hi Tobias,

My new plan is to add a new replica set member with enabled snappy 
compression and instead of copying the big collection, I would copy all 
other collections (which are much smaller) to new collections with disabled 
compression. Not perfect, since I have to disable compression for every new 
collection, but may be a way to handle the problem.

May I ask why you want to turn off compression for some of the collections? 
Why not just use Snappy compression (the default in WiredTiger engine 
<https://docs.mongodb.org/manual/core/wiredtiger/#compression>) for all the 
collections instead? Snappy requires relatively low CPU resources, but 
provides a reasonable level of compression. Compressed data has the 
advantage of lowering disk usage (since there’s less data to transfer) and 
more efficient memory use in general. Also, if a document cannot be 
compressed, Snappy will store it uncompressed. Please see the Snappy page 
<https://google.github.io/snappy/> for more information.

Once compression is enabled in a specific mongod (e.g. Snappy by default, 
none, or zlib using --wiredTigerCollectionBlockCompressor 
<https://docs.mongodb.org/manual/reference/configuration-options/#storage.wiredTiger.collectionConfig.blockCompressor>), 
all new collection created in that particular mongod will use that block 
compressor.

This behaviour can be changed by creating a new collection using 
db.createCollection with specific storage engine options 
<https://docs.mongodb.org/manual/reference/method/db.createCollection/#specify-storage-engine-options>. 
However please be aware that any collection-specific setting will override 
any mongod setting, and it is not possible to change those settings anymore 
unless the collection is recreated.

If your use case allows it, I would recommend to use Snappy compression for 
all collections, since the benefits (lower disk usage, more efficient 
memory usage) generally outweighs the drawbacks (sightly higher CPU 
utilization). Another benefit for your case is that you don’t need to 
micromanage collection-level specific settings.

Best regards,
Kevin


-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.org/manual/support/
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/e1f479f6-6111-4963-8ab4-d4566dca605b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?