The In-Memory Storage Engine is a feature of MongoDB Enterprise Server made generally available in the MongoDB 3.2.6 production release. As at MongoDB 3.6, storage engines are a per-
mongod configuration option: you can have a replica set or sharded deployment with mixed storage engines, but you cannot specify storage engines at a collection level.
The In-Memory Storage engine achieves more predictable latency for database operations by avoiding disk I/O, but is intended for use cases where indexes and uncompressed data fit entirely within the In-Memory Cache. A write operation will fail if it would cause data to exceed the configured memory size.
If your data set is potentially larger than available memory, the default persistent storage engine will be much more suitable. Persistent storage engines effectively keep your working set in RAM based on least recently used caching, with implementation details varying by storage engine.
I was thinking to try out this capability for discardable data such as Sitecore sessions - for which we have no use after the
SessionEnd event. Are there any obvious drawbacks to this approach?
In order to achieve this outcome you would either have to:
- impose the constraints of In-Memory storage on your main MongoDB deployment (all of the data and indexes in your deployment fit into available RAM)
- add a separate MongoDB deployment with In-Memory Storage Engine for your Sitecore session state store
You would also have to factor in licensing costs for using MongoDB Enterprise in production.
Will this scale properly - e.g. will MongoDB manage redundancy itself in a multi-server/master-slave configuration?
The In-Memory storage engine supports all of MongoDB's standard distributed features and can be used on members of replica sets or sharded clusters. The main scaling limit to be aware of is the In-Memory data size limit.
If members of a single MongoDB deployment have different configurations (for example storage engines or hardware resources), you will also need to put extra thought into capacity planning and failover scenarios.