MongoDB Charts on Atlas now supports Workload Isolation, ensuring the queries used to generate visualisations do not interfere with transactional workloads.
MongoDB replica sets will be familiar to anyone who has taken MongoDB into production. A replica set is a group of MongoDB processes or servers that work together and access the same data. A key reason to use replica sets is availability—if one of the servers in your replica set goes down for any reason, the others will continue to operate and your database will remain online. This is one of the reasons why MongoDB Atlas always uses replica sets for every cluster you deploy and why we recommend that anyone using MongoDB in production do the same.
But there’s another great advantage of using replica sets which we call workload isolation. In a replica set, only one node can be the “primary” at any given time, and only the primary node can accept database writes. The other nodes, the “secondaries”, can become the primary if the original primary node goes down. The secondaries can also be safely used for database reads at any time. This is important, because a typical system may have several very different workloads which don’t want to interfere with one another. Imagine a MongoDB replica set that supports an e-commerce application. That system will have several workloads, such as:
- Processing orders for customers accessing the website
- Training Machine Learning algorithms to make product recommendations
- Visualising sales data and trends on a MongoDB Charts dashboard.
These workloads are all different but all are important for the overall system. We definitely don’t want order placements to be slow while we are training our Machine Learning algorithms, but nor do we want our dashboard refreshes to be slow because it’s a busy day for orders. Looking at that list of workloads again, you may notice that only the first requires write access to the database. The other two can safely be run against secondary nodes, giving us the workload isolation we’re after.
There’s one potential issue though - if the primary goes down, one of the secondaries will become the new primary, and there may not be enough nodes left to guarantee workload isolation. Fortunately there is a solution to this too. You can add one (or more) analytics nodes to your Atlas cluster. An analytics node is an additional secondary node that cannot be elected as a primary, and uses replica set tags to allow clients to direct traffic to them. As an analytics node can never be elected as primary, it is guaranteed to be isolated from the workload.
Charts and Workload Isolation
Now let’s look at how MongoDB Charts works with workload isolation in Atlas. Up until recently, the Charts beta had no support for workload isolation, with all requests going to the primary node. However in the latest update, that all changes. By default, any data source you add to Charts on Atlas is configured to read from secondary nodes, ensuring the queries generated by Charts are isolated from your transactional traffic, provided you have at least one secondary node. Existing Charts users will find that we’ve automatically updated any existing data sources to use the secondary read preference.To provide the highest isolation and resilience, you can deploy one or more Analytics Nodes to your cluster, and configure the Charts data source to use the Analytics Node read preference.
Note that this post focuses on MongoDB Atlas, our fully managed database in the cloud, which takes most of the work out of configuring and managing replica sets. But if you’re running your own replica sets on-premises, the same concepts still apply. You can deploy additional secondary nodes to a replica set, and use replica set tags to further isolate certain nodes. With Charts on-premises, you can target specific node types by setting the appropriate readPreference parameters in the URI you use when connecting to the database.
In summary, replica sets provide both high availability and the opportunity to isolate workloads. Data analysis and visualisation is a perfect use case for reading from secondaries or dedicated analytics nodes, and MongoDB Charts now fully supports this scenario.