What is the shortcoming? We are getting consistency
across partitions. If Brewer is correct, then we must be
impacting availability, but how can that be?
The availability of any system is the product of the
availability of the components required for operation.
The last part of that statement is the most important.
Components that may be used by the system but are not
required do not reduce system availability. A transaction
involving two databases in a 2PC commit will have the
availability of the product of the availability of each database. For example, if we assume each database has 99.9
percent availability, then the availability of the transaction becomes 99.8 percent, or an additional downtime of
43 minutes per month.
availability in a partitioned database, then opportunities
to relax consistency have to be identified. This is often
difficult because the tendency of both business stakeholders and developers is to assert that consistency is
paramount to the success of the application. Temporal
inconsistency cannot be hidden from the end user, so
both engineering and product owners must be involved
in picking the opportunities for relaxing consistency.
Figure 2 is a simple schema that illustrates consis-
The tendency of both business
tency considerations for BASE. The user table holds user
stakeholders and developers is
to assert that consistency is paramount
to the success of the application.
AN ACID ALTERNATIVE
If ACID provides the consistency choice for partitioned
databases, then how do you achieve availability instead?
One answer is BASE (basically available, soft state, eventually consistent).
BASE is diametrically opposed to ACID. Where ACID
is pessimistic and forces consistency at the end of every
operation, BASE is optimistic and accepts that the
database consistency will be in a state of flux. Although
this sounds impossible to cope with, in reality it is quite
manageable and leads to levels of scalability that cannot
be obtained with ACID.
The availability of BASE is achieved through supporting partial failures without total system failure. Here
is a simple example: if users are partitioned across five
database servers, BASE design encourages crafting operations in such a way that a user database failure impacts
only the 20 percent of the users on that particular host.
There is no magic involved, but this does lead to higher
perceived availability of the system.
So, now that you have decomposed your data into
functional groups and partitioned the busiest groups
across multiple databases, how do you incorporate BASE
into your application? BASE requires a more in-depth
analysis of the operations
within a logical transaction
than is typically applied to
ACID. What should you be
looking for? The following sections provide some
direction. B e gin transaction
Insert into transaction(xid, seller_id, buyer_id, amount);
Update user set amt_sold=amt_sold+$amount where id=$seller_id;
Update user set amt_bought=amount_bought+$amount where id=$buyer_id;
E nd transaction
information including the total amount sold and bought.
These are running totals. The transaction table holds each
transaction, relating the seller and buyer and the amount
of the transaction. These are gross oversimplifications of
real tables but contain the necessary elements for illustrating several aspects of consistency.
In general, consistency across functional groups is
easier to relax than within functional groups. The example
schema has two functional groups: users and transactions. Each time an item is sold, a row is added to the
transaction table and the counters for the buyer and seller
Following Brewer’s conjecture, if BASE allows for