Databases Reference
In-Depth Information
system's maximum throughput, but you can't push real systems that hard. If you do,
performance will degrade and response times will become unacceptably large and vari-
able. We define the system's actual capacity as the throughput it can achieve while still
delivering acceptable performance. This is why benchmark results usually shouldn't
be reduced to a single number.
Capacity and scalability are independent of performance. To make an analogy with
cars on a highway:
• Performance is how fast the car is.
• Capacity is the number of lanes times the maximum safe speed.
• Scalability is the degree to which you can add more cars and more lanes without
slowing traffic.
In this analogy, scalability depends on factors such as how well the interchanges are
designed, how many cars have accidents or break down, and whether the cars drive at
different speeds or change lanes a lot—but generally
not
on how powerful the cars'
engines are. This is not to say that performance doesn't matter, because it does. We're
just pointing out that systems can be scalable even if they aren't high-performance.
From the 50,000-foot view,
scalability is the ability to add capacity by adding resources
.
Even if your MySQL architecture is scalable, your application might not be. If it's hard
to increase capacity for any reason, your application isn't scalable overall. We defined
capacity in terms of throughput a moment ago, but it's worth looking at capacity from
the same 50,000-foot view. From this vantage point, capacity simply means the ability
to handle load, and it's useful to think of load from several different angles:
Quantity of data
The sheer volume of data your application can accumulate is one of the most com-
mon scaling challenges. This is particularly an issue for many of today's web ap-
plications, which never delete any data. Social networking sites, for example,
typically never delete old messages or comments.
Number of users
Even if each user has only a small amount of data, if you have a lot of users it adds
up—and the data size can grow disproportionately faster than the number of users.
Many users generally means more transactions too, and the number of transactions
might not be proportional to the number of users. Finally, many users (and more
data) can mean increasingly complex queries, especially if queries depend on the
number of relationships among users. (The number of relationships is bounded by
(
N *
(
N
-1) ) / 2, where
N
is the number of users.)
User activity
Not all user activity is equal, and user activity is not constant. If your users suddenly
become more active, for example because of a new feature they like, your load can
increase significantly. User activity isn't just a matter of the number of page views,
either—the same number of page views can cause more work if part of the site that
