one register is open, that is serialization. Suddenly a huge line forms and
snakes around the store, frustrating
not only the customers checking out,
but also those still shopping. It happens at bridge tollbooths when not
enough are open, or in sports arenas
when everyone leaves at the same time.
Web applications should definitely
avoid serialization. Do you see a backup waiting for API calls to return, or
are all your Web nodes working off one
search server? Anywhere your application forms a line, that is serialization
and should be avoided at all costs.
5. Missing Feature Flags.
Developers normally build in features and
functionality for business units and
customers. Feature flags are operational necessities that allow those features to be turned on or off in either
back-end config files or administration UI pages.
Why are they so important? If you
have ever had to put out a fire at 4 a.m.,
then you understand the need for contingency plans. You must be able to
disable ratings, comments, and other
auxiliary features of an application,
just so the whole thing does not fall
over. What’s more, as new features are
rolled out, sometimes the kinks do
not show up until a horde of Internet
users hit the site. Feature flags allow
you to disable a few features, without
taking the whole site offline.
6. Single Copy of the Database. You
should always have at least one read
replica or MySQL slave online. This
allows for faster recovery in the event
that the master fails, even if you are not
using the slave for browsing—but you
should do that, too, since you are going
to build a browse-only mode, right?
Having multiple copies of a database suggests horizontal scale. Once
you have two, you will see how three or
four could benefit your infrastructure.
7. Using your Database for Queuing. A MySQL database server is great
at storage tables or data, and relationships between them. Unfortunately, it
is not great at serving as a queue for
an application. Despite this, a lot of
developers fall into the habit of using
a table for this purpose. For example,
does your app have some sort of jobs
table, or perhaps a status column,
with values such as “in-process,” “
in-queue,” and “finished”? If so, you are
inadvertently using tables as queues.
Such solutions run into scalability hang-ups because of locking challenges and the scan and poll process
to find more work. They will typically
slow down a database. Fortunately,
some good open source solutions are
available such as RabbitMQ (http://
www.rabbitmq.com/) or Amazon’s
SQS (Simple Queue Service; http://
8. Using a Database for Full-Text
Searching. Page searching is another
area where applications get caught.
Although MySQL has had full-text indexes for some time, they have worked
only with MyISAM tables, the legacy
table type that is not crash proof, not
transactional, and just an all-around
headache for developers.
One solution is to go with a dedicated
search server such as Solr (http://lucene.
apache.org/solr/). These servers have
good libraries for whatever language
you are using and high-speed access to
search. These nodes also scale well and
will not bog down your database.
Alternatively, Sphinx SE, a storage engine for MySQL, integrates
the Sphinx server right into the database. If you are looking on the horizon, Fulltext is coming to InnoDB,
MySQL’s default storage engine, in
version 5. 6 of MySQL.
9. Object Relational Models. The
ORM, the bane of every Web company
that has ever used it, is like cooking
with MSG. Once you start using it, it is
hard to wean yourself off.
The plus side is that ORMs help
with rapid prototyping and allow developers who are not SQL masters to
read and write to the database as objects or memory structures. They are
faster, cleaner, and offer quicker delivery of functionality—until you roll
out on servers and want to scale.
Then your database administrator