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 this article.
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.
functional scaling
users0
products
trans0
users1
trans1
sharding
Availability. Every operation must terminate in an intended response.
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.
user
id name amt_sold amt_bought
transaction xid seller_id buyer_id amount
References:
Archives