Databases Reference
In-Depth Information
I/O-bound, contention among concurrent queries, and increasing latency. Common
culprits are increased query complexity, or a portion of the data or index that used to
fit into memory but no longer does. You might see a change in certain types of queries
and not others. For example, long or complex queries often show the strain before
smaller queries.
If your application is highly scalable, you can simply plug in more servers to handle the
load, and the performance problems will disappear. If it's not scalable, you might find
yourself fighting fires endlessly. You can avoid this by planning for scalability.
The hardest part of scalability planning is estimating how much load you'll need to
handle. You don't need to get it exactly right, but you need to be within an order of
magnitude. If you overestimate, you'll waste resources on development, but if you
underestimate, you'll be unprepared for the load.
You also need to estimate your schedule approximately right—that is, you need to
know where the “horizon” is. For some applications, a simple prototype could work
fine for a few months, giving you a chance to raise capital and build a more scalable
architecture. For other applications, you might need your current architecture to pro-
vide enough capacity for two years.
Here are some questions you can ask yourself to help plan for scalability:
• How complete is your application's functionality? A lot of the scaling solutions we
suggest can make it harder to implement certain features. If you haven't yet im-
plemented some of your application's core features, it might be hard to see how
you can build them in a scaled application. Likewise, it could be hard to decide on
a scaling solution before you've seen how these features will really work.
• What is your expected peak load? Your application should work even at this load.
What would happen if your site made the front page of Yahoo! News or Slashdot?
Even if your application isn't a popular website, you can still have peak loads. For
example, if you're an online retailer, the holiday season—especially the infamous
online shopping days in the few weeks before Christmas—is often a time of peak
load. In the US, Valentine's Day and the weekend before Mother's Day are also a
peak times for online florists.
• If you rely on every part of your system to handle the load, what will happen if part
of it fails? For example, if you rely on replicas to distribute the read load, can you
still keep up if one of them fails? Will you need to disable some functionality to do
so? You can build in some spare capacity to help alleviate these concerns.
Buying Time Before Scaling
In a perfect world, you would be able to plan ahead for any eventuality, would always
have enough developers, would never run into budget limitations, and so on. In the
real world, things are usually more complicated, and you'll need to make some com-
promises as you scale your application. In particular, you might need to put off big
