␡
- What Is Scalability?
- Detecting Performance Bottlenecks
- When to Begin Scaling
- Okay, You Need to Scale. Now What?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When to Begin Scaling
You’ve identified the problem area. Should you start scaling immediately? Not necessarily. The question of when to start scaling your database can be answered in two ways:
- Don’t scale until it’s absolutely necessary. Yes, we’ve just spent time outlining problems that databases encounter and touting scaling as a solution. But many of those problems can be solved with simple tuning, query optimization techniques, or cost-effective hardware upgrades.
- Scale your database after you’ve exhausted all other options. This approach provides a more complete answer to the question of when to start scaling. You need to address the performance issues in your monolithic single-server database environment. In other words, tackle all of the obvious performance-optimization steps in your current environment before you make the jump to a scalable database cluster.
If a fast-growing application is taxing your database tier, and you anticipate that growth continuing at a high rate, this is an opportune moment to think about scalability. Developing a scalable database is a large undertaking in terms of finances, system resources, and time. However, it’s better to plan for a database cluster now, rather than getting caught in an emergency situation down the line.
A handful of common indicators point to the need for scaling:
- User complaints. If user experience is already adversely affected by slow performance or service outages, you need to scale. A better solution is avoiding this problem by anticipating issues before the situation becomes dire, but that’s not always possible.
- Increased application latency. Slow read queries are a common cause of high-latency operations. This problem often is due to normal table or volume growth, but it also can point to inefficiencies (such as table scans) in database access code. Are the slow reads in routine, well-indexed queries? If so, you likely have genuine growth in application volume and database size—a blessing for a well-prepared company, and a curse for those who didn’t anticipate such growth.
- Slow database writes. This is a huge red flag for a database infrastructure. Database writes are one of the most important factors to monitor. Increased latency in database writes almost always is a dead-on indicator that you must scale to a full Big Data cluster implementation. Slow writes are commonly caused by index updates on a large table or object store, and developers may be tempted to try workarounds or temporary fixes such as hardware upgrades. Ultimately, these efforts are futile, because storage infrastructures typically can perform only up to a certain maximum speed, even with the best hardware available.