MongoDB in-memory engine for OLTP

Hi All,

I’m deepening my knowledge regarding the different features MongoDB provides and I’m wondering if it could be suitable for OLTP processing with an in-memory engine.

In particular, the configuration I’m looking at is based on a 3 replica set with:

  • Primary Node in-memory
  • Secondary Node in-memory
  • Hidden Node WiredTiger

Please let me know if you need any further information.

Regards,

Welcome to the MongoDB community @Giutor!

It would be helpful to have some elaboration on your specific requirements or concerns for suitability, but the general answer is yes.

There’s more detail (including links to further reading) in the “When should I use MongoDB?” entry in the MongoDB FAQ:

The MongoDB data platform can be used across a range of OLTP and analytical apps.

With the MongoDB Server and MongoDB Atlas Data Lake, you can address a wide range of application requirements.

The In-Memory Storage Engine included in MongoDB Enterprise provides more predictable latency if your data, indexes, and oplog can fit entirely in-memory. The In-Memory Storage Engine intentionally avoids disk I/O, so if you need data persistence the recommended deployment is a replica set with a hidden priority 0 member configured with the default WiredTiger storage engine as you have suggested. See In-Memory Storage Deployment Architectures for more information.

If you need stronger durability guarantees for your OLTP use case or have a working set which may exceed available RAM, a deployment with the default WiredTiger storage engine would likely be a more appropriate choice than in-memory.

Regards,
Stennie

1 Like

Hello @Stennie_X, thank you very much for your reply!

I apologize for the delayed answer, I’ve tried to retrieve some more information.

My OLTP workload consists of a Real-Time pipeline with Apache Storm as the actor in charge of the writing operations.
The Storm topology, depending on the tuple it is processing, should retrieve a previous message written on the DB through a “find” based on the index keys and, depending on the values of some fields, performes an update on the retrieved data.
We are talking about millions of operations per minute and, on the other hand, there are some analytical workloads performed using the MongoDB Aggregation framework by different instances of Microservices deployed on K8s.

The response time for both the OLTP and OLAP workloads is critical, this is the reason why I was thinking about an in-memory engine deployment.

I hope to have cleared the scenario a bit more, in order to understand if I’m missing any drawbacks that could lead the solution not to be the best in terms of feasibility.

Regards,
Giutor