4 Key Considerations for Scaling Your Database
Source: Razi Sharir
The Cloud Database Company �C that provides an elastic database-as-a-service for MySQL applications.
Scalability is one of the biggest buzzwords around the cloud ecosystem. Scalability of the database tier, in particular, takes center stage these days.
The cloud promises scalability in that virtualized resources -- from a tiny application up to huge traffic volumes -- can be easily added or removed to accommodate any use case or demand. While scalability of the application tier is pretty much a no-brainer (and many solutions address that), the scalability of the sensitive database tier still remains the Achilles’ heel for many applications running in the cloud.
When evaluating a database solution, it’s important to make sure your database scales in a way that is optimal for the needs of your application. Below are four key things to consider when choosing a suitable scaling solution for your database.
1. Traffic
Database scalability should accommodate your application’s traffic at any given time. And as we know, the demand for your application varies considerably throughout the hours of the day, the months of the year and the application’s life span. Some apps are peak-driven, while others may start small and then explode (e.g. Twitter). Not all traffic is predictable, so when demand goes through the roof, you want to be able to sustain it rather than risk losing business.
Besides the occasional peaks in demand, automatic scaling assures your database will always run optimally in the cloud. You’ll want to save on costs by having the resources allocated for your database closely linked to the actual demand. That way, when your application is experiencing a more moderate load, you won’t preserve the underutilized resources or continue to pay for them. As your database scales out when the application demands it, it shrinks back down when it is underutilized. This is true elasticity. You only pay for what you use, with no need for any of the extensive management or configuration overhead on your part, allowing you to focus on what's most important: your applications.
2. Downtime
Hand-in-hand with automatic scaling, I recommend that scaling is transparent to the application, so you do not need to change your code or your configuration every time you need to scale.
Ideally, scaling should be done “online,” meaning scaling should occur without service interruption or downtime. Overall service should be maintained. Otherwise, the application might suffer some performance degradation during the scaling time. Since your database records could change during the scale event, any solution that offers online scalability needs to be able to ensure data consistency between the pre-scaling and post-scaling database.
3. Peformance
Think of how you would need to scale and which common database operations will require scaling. There are two types of scaling: scaling up and down and scaling out and in. The first is the most common and simplest way to scale: If your database needs more size or better performance, simply buy a bigger, faster, meaner machine. However, scaling up has limits. Capacity cannot extend past a single machine's size, and large machines are often too expensive or not available with many public clouds.
Unlike scaling up, scaling out means adding nodes: front end nodes will give you more throughput, and will “share” the load of the application, while backend nodes will give you more size. Scaling across multiple nodes (although more complex to achieve) has the advantage of being able to scale beyond the limits of a single machine’s size or CPU.
4. Investment
Last but not least, ask yourself how much work, maintenance and technical expertise are you willing to invest in ensuring scalability for your database. For some developers, the DIY approach may be most suitable. Others may prefer focusing on the app rather than on the IT, instead opting for a database-as-a-service solution that takes care of scalability for them.
As developers gradually migrate more of their applications to the cloud, it’s becoming abundantly clear that databases in a cloud environment are inherently different than traditional installs. Given that, at the end of the day, the availability and potential growth of the application are only as good as the scalability of the database behind it. The key is to always make sure your solution can accommodate future growth and use cases of your application.
| }
|