Databases Reference
In-Depth Information
use other approaches, such as proxies. (ScaleBase is one that could be worth looking
into.)
The other siren call of the cloud is the dream of auto-scaling—that is, spinning up more
instances in response to increased demand, and shutting them down again when de-
mand reduces. Although this is feasible with stateless parts of the stack such as web
servers, it's very hard to do with the database server, because it is stateful. For special
cases, such as read-mostly applications, you can get a limited form of auto-scaling by
adding replicas,
4
but this is not a one-size-fits-all solution. In practice, although many
applications use auto-scaling in the web tier, MySQL isn't natively capable of running
across a shared-nothing cluster of servers that all assume peer roles. You could do it
with a sharded architecture that automatically reshards and grows or shrinks,
5
but
MySQL itself just isn't able to auto-scale.
In fact, as it's typically the main or only stateful and persistent component of an ap-
plication, it's pretty common for people to move an application into the cloud because
of the benefits it offers for everything
but
the database—web servers, job queue servers,
caches, etc.—and MySQL just has to go where everything else goes.
The database isn't the center of the world, after all. If the benefits to the rest of the
application outweigh the additional cost and effort required to make MySQL work as
needed, then it's not a question of whether it will happen, but how. To answer this,
it's helpful to understand the additional challenges you might face in the cloud. These
typically center around the resources available to the database server.
The Four Fundamental Resources
MySQL needs four fundamental resources to do its work: CPU cycles, memory, I/O,
and the network. These four resources have characteristic and important differences
in most cloud platforms. One helpful way to approach decisions about hosting MySQL
in the cloud is to examine these differences and their implications for MySQL:
• CPUs are generally fewer and slower. The largest standard EC2 instances at the
time of writing offer eight virtual CPU cores. The virtual CPUs EC2 offers are
effectively slower than top-end CPUs (see our benchmarks a bit later in the chapter
for the subtleties). This is probably fairly typical of most cloud hosting, although
there will be variations. EC2 offers instances with more CPU resources, but they
have lower maximum memory sizes. At the time of writing, commodity servers
offer dozens of CPU cores—and even more, if you count hardware threads.
6
4. A popular open source service for auto-scaling MySQL replication in the cloud is Scalr (
http://scalr.net
).
5. This is what computer scientists like to call a “non-trivial challenge.”
6. Commodity hardware still offers more power than MySQL can use effectively in terms of CPU, RAM,
and I/O, so it's not completely fair to compare the cloud with the biggest horsepower available outside
the cloud.
