Understanding RDS Scaling & Elasticity
The course is part of these learning paths
This course explores how to scale your RDS databases. It covers scaling based on reads or writes, and what it means to scale horizontally or vertically.
Additionally, it covers sharding databases as a way to increase write performance and when it needs to be considered as an option.
- Explain the difference between horizontal and vertical scaling of RDS databases.
- You will understand the differences between scaling for reads and scaling for writes.
- You will learn to address these scaling issues inside Amazon RDS
- You will learn when it is appropriate to shard an RDS database and understand its complexities
This course is recommended for anyone who wants to understand the basics of scaling RDS. It includes information about database sharding as a way to scale write performance.
To get the most out of this course, you should have a basic understanding of cloud computing using Amazon Web Services. You also need to know how relational databases work at a high level.
If you have any feedback relating to this course, please contact us at email@example.com.
One of the primary components of having a robust architecture is the ability for your systems to scale based on their needs. This is especially important when we are talking about your database.
Your database can scale based on two primary attributes, its read capacity needs or the write capacity needs. It may not seem very obvious at first, but in practice the ways you scale your database for these problems differ fairly heavily. Let's take a moment to go over some definitions so we are all on the same page.
Scaling from a read point of view would occur if you had an increase in traffic that primarily needed to retrieve information from the database.
For example: an online video game might have a lot of people accessing the all time high scores page, to see how their games compare to the record holders. However not many people statistically are going to be able to put up new high scores that often, making this a read heavy workload.
You might have the opposite scenario when tracking the activities of the players playing your online game.
Let say you were very interested in completion metrics and other analytical data about the progress of your players. In this scenario you would be writing to your database very frequently and only reading the information gathered every once in a while to create a report. This would be called a write heavy workload.
There are scenarios where your workload will increase proportionally - where neither the write or the read are the constraining factors themselves. This is the preferred case, because it's the most straightforward to alleviate. We will go more into that soon.
Now that we have an idea on why our database would need to scale, let's take a look at the options available to do so. There are two ways to deal with scaling your database, you can scale horizontally or you can scale vertically.
Scaling vertically is generally the easiest method of scaling. This is where you increase the size of the underlying hardware / software to help deal with the problem. Providing more raw power for transactions like reading and writing.
Vertical scaling is a very good solution if you have equal levels of reads and writes, as you get proportional increases in both when you upgrade the underlying hardware. It is also a fine strategy for dealing with reads or writes individually, but that might not be as cost effective.
Vertical scaling is all about increasing the horsepower of the database you already have, allowing you to do more work.
Some things to consider when you scale vertically:
There is time involved when changing your instance types and this can increase downtime for your applications. Something to be aware of if you have strict SLAs you need to adhere to.
There are upper limits for how many times you might be able to vertically scale. As you scale vertically and work your way up the hardware/instance ladder, you will eventually reach a ceiling. Over time this ceiling will move upwards as new technologies become available - but I wouldn't hinge my project on it.
Still requires standby databases to be available in case the primary where to go offline. Scaling vertically doesn't really help address issues with fault tolerance.
The other method we have available is to scale horizontally. This means increasing the number of underlying hardware or software entities to improve performance. Increasing the number of entities allows more surface area for your transactions to communicate with.
Scaling horizontally does come with the downside of losing finite control over your database by removing some of the intelligence you get with just having one source of truth. Managing the routing of each additional entity, updating more entity systems in general, and dealing with consistency problems across these databases can be difficult to do.
Do not let that deter you if scaling horizontally is the right answer for your architectures. Because as we will discuss in the next section, RDS has many features already built into it that can handle these problems for you.
Overall horizontal scaling works very well for dealing with read capacity issues. However there are some extra steps involved to scale write capacity when speaking about single node master systems. ( databases where there is only a single write source)
Unlike vertically scaling, horizontal scaling lends itself towards greater fault tolerance and high availability - since your data will already be split up and be in a better position to survive portions of the database failing.
William Meadows is a passionately curious human currently living in the Bay Area in California. His career has included working with lasers, teaching teenagers how to code, and creating classes about cloud technology that are taught all over the world. His dedication to completing goals and helping others is what brings meaning to his life. In his free time, he enjoys reading Reddit, playing video games, and writing books.