Database Reference
In-Depth Information
Dealing with success - splitting tables
over multiple databases
Now, let's roll forward in time a little and assume you have been successful enough to
attract tens of thousands of users and your single database starts creaking under the
load.
My general rule of thumb is to start planning for a bigger machine or splitting the data-
base when you are over 80 percent utilization at least for a few hours a day. It's good
to have a plan earlier, but now you have to start doing something about really carrying
out the plan.
What expansion plans work and when
There are a couple of popular ways to grow database-backed systems. Depending on
your use case, not all ways will work.
Moving to a bigger server
If you suspect that you are near your top load for the service or product, you can
simply move to a more powerful server. This may not be the best long-time scaling
solution if you are still in the middle, or even in the beginning of your growth. You will
run out of "bigger" machines to buy long before you are done. Servers also become
disproportionately more expensive as the size increases, and you will be left with at
least one "different" and thus not easily replaceable server once you implement a
proper scaling solution.
On the other hand, this will work for some time and is often the easiest way to get
some headroom while implementing real scaling solutions.
Master-slave replication - moving reads to slave
Master-slave replication, either trigger-based or WAL-based, works reasonably well
in cases where the large majority of the database accesses are reads. Some things
that fall under this case are website content managers, blogs, and other publishing
systems.
