This little guide is medium in scope, it is not exhaustive. It just gives you an idea to focus
1 Choose the right storage engine for your specific workload.
The storage engine is the component of the database that is responsible for managing how data is stored, both in memory and on disk.
Is MongoDB’s original storage engine based on memory mapped files.
Is the default storage engine in MongoDB 3.0 and all previous versions.
It was designed for heavy reads
This engine is deprecated with the MongoDB 4.0 release
Starting in MongoDB 3.0, the WiredTiger storage engine is available in the 64-bit builds
Is the default storage engine since version 3.2
Is designed for heavy reads-writes operations uses document-level concurrency control for write operations
Supports compression for journal, all collections and indexes, by default, uses snappy compression library, can be changed for zlib library
Starting in MongoDB Enterprise version 3.2
Is based upon WiredTiger, all characteristics regarding WiredTiger also apply to he Encrypted storage engine.
The encryption occurs transparently in the storage layer; i.e. all data files are fully encrypted from a filesystem perspective, and data only exists in an unencrypted state in memory and during transmission.
Starting in MongoDB Enterprise version 3.2.6
The in-memory storage engine does not maintain any on-disk data, including configuration data, indexes, user credentials, etc.
The in-memory storage engine does not persist data after process shutdown
How to change the storage engine in standalone Server.
1.- Ensure your mongod process is running
2.- Export data using mongodump
3.- Create a new directory for the new mongod running with your StorageEngine
4.- Start mongod with your Storage Engine, in my case WiredTiger
5.- Restore the dump with mongorestore
That’s it, now, we are working with a new storage engine.
You can find the other articles of this series below.