Part 2: Your App is Taking Off, Now What? It’s Time to Scale Out MongoDB.
October 27, 2014 | Updated: March 7, 2016
In our first post on scaling, we discussed fundamentals of designing a performant and scalable application on MongoDB. Once you’re confident that your application is healthy and ready to grow, it’s time to think about scaling. Before jumping into it, make sure you consider the different ways to scale, and beware of the potential pitfalls:
1. Understand Why You’re Scaling, and What Issues Are Down the Road
There are a lot of ways in which an application could be experiencing growth – or constraints to growth! Your workload could be predominantly reads or predominantly writes. Maybe your access operations are under control, but your data volume isn’t. As you grow, you could hit bottlenecks caused by bad schema decisions, inefficient indexing, insufficient RAM, disk speed, network latency, poor planning of transactional vs. analytical queries, or any of dozens of other factors. All of these root causes have different potential solutions. Choosing the right strategy requires understanding your dataset, your users, how you expect to grow, and more.
2. Understand the Trade-Offs: Horizontal vs. Vertical Scaling
While MongoDB makes it easy to horizontally scale out with built-in automatic sharding, sharding – or adding more shards – isn't always the only answer. In some cases, making improvements to your hardware can remove constraints that you might be encountering. For example, if your dataset grows and your working set no longer fits in RAM, you might invest in more RAM before deciding to scale out to more machines. Similarly, in some instances, it might make sense to add more or faster disks, or upgrade to SSDs.
3. Choose Your Shard Key Wisely
MongoDB supports multiple shard key policies to match your needs. Your shard key selection will impact performance of your cluster. It’s critical that you pick the right key based on your application requirements and expected usage patterns. You want to ensure both even distribution of writes and query isolation – i.e., that queries are targeted to a single shard as much as possible, rather than broadcast (scatter/gather) to all shards. By thinking about these issues before choosing a shard key, you can ensure scalable growth and avoid common sharding pitfalls.
So how do I make these decisions about scaling?
Take advantage of the many resources we provide. You can start by talking with an expert about scaling strategies for free. When you’re ready to take the next step, our Deployment Topology consulting package is a great way to evaluate your scaling options. And you can always check out our documentation and white papers for more tips.