to a database deployment strategy. For constraints to be
applied, the tables must reside on a single database server,
precluding horizontal scaling as transaction rates grow. In
many cases, the easiest scale-out opportunity is moving
functional groups of data onto discrete database servers.
Schemas that can scale to very high transaction
volumes will place functionally distinct data on different
database servers. This requires moving data constraints
out of the database and into the application. This also
introduces several challenges that are addressed later in
Eric Brewer, a professor at the University of California,
Berkeley, and cofounder and chief scientist at Inktomi,
made the conjecture that Web services cannot ensure all
three of the following properties at once (signified by the
acronym CAP): 2
Consistency. The client perceives that a set of operations
has occurred all at once.
D ata Scaling
Availability. Every operation must terminate in an
Partition tolerance. Operations will complete, even if
individual components are unavailable.
Specifically, a Web application can support, at most,
only two of these properties with any database design.
Obviously, any horizontal scaling strategy is based on
data partitioning; therefore, designers are forced to decide
between consistency and availability.
ACID database transactions greatly simplify the job of the
application developer. As signified by the acronym, ACID
transactions provide the following guarantees:
Atomicity. All of the operations in the transaction will
complete, or none will.
Consistency. The database will be in a consistent state
when the transaction begins and ends.
Isolation. The transaction will behave as if it is the only
operation being performed upon the database.
Durability. Upon completion of the transaction, the
operation will not be reversed.
Database vendors long ago recognized the need for
partitioning databases and introduced a technique known
as 2PC (two-phase commit) for providing ACID guarantees across multiple database instances. The protocol is
broken into two phases:
• First, the transaction coordinator asks each database
involved to precommit the operation and indicate
whether commit is possible. If all databases agree the
commit can proceed, then phase 2 begins.
• The transaction coordinator asks each database to commit the data.
If any database vetoes the commit, then all databases
are asked to roll back their portions of the transaction.
Sample Schem a
F IG 2