Can I use the in-memory storage engine for my MongoDB based sessions?

Question

MongoDB 3.2+ offers the option of putting some or all of the structures into an in-memory 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? Will this scale properly - e.g. will MongoDB manage redundancy itself in a multi-server/master-slave configuration?

Answer 1

Yes - there are several advanced ways this can be used - but as I see it the main drawback will be that you expose yourself to a heavy denial of service attack. The in-memory provider will block writes and therefore hinder creations of new sessions if it runs out of memory - so a session flood attack (probably the easiest attack there is) will bring your system down.

Answer 2

I think the obvious drawback will be that something will be stored in memory which you will need later on. Because you don't control sitecore, you cannot decide what will be stored in memory there. Therefor the risk will be loosing data in whatever scenario that can happen. But the oplog will keep track of these changes, if you have this configured.

We have it configured that nobody can access the mongo cluster from the outside, therefor possible attacks will not cause the cluster to crash and loose data. Also, Sitecore has jobs running to transfer data to the cluster, so there will be no realtime throughput.

But If you have a mongo cluster consisting of at least 3 servers, you will have no issues at all..

Answer 3

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.