Cloud Computing

Prof Roy Campbell

Space reserved for video

University of Illinois at Urbana-Champaign (UIUC)
Do not put anything here

Fall 2015 ACID and BASE

Cloud Computing Applications - Roy Campbell 1

Consistent Transactions
in the Clouds
• What if we do need consistency?
• We will cover Consistent Transactions
today:
• Easy way: ACID  BASE
• Distributed transactions with locking
• Use locking (Zookeeper, Paxos)
• Two-phase locking
• Distributed transactions with time stamps Space reserved for video
• Time Do not put anything here
• Lamport’s logical clocks
• Real GPS-based clocks
• Distributed transactions with snapshots
The ACID Model
• A model for correct behavior of databases
• Name was coined in the 60’s
• Atomicity: Even if “transactions” have multiple
operations, does them to completion (commit) or
rolls back so that they leave no effect (abort)
• Consistency: A transaction that runs on a correct
database leaves it in a correct (“consistent”) state
• Isolation: It looks as if each transaction ran all
Space reserved for video
by itself. Basically says “we’ll hide any Do not put anything here
concurrency”
• Durability: Once a transaction commits, updates
can’t be lost or rolled back
Transactions
Are the Basis of ACID
• Applications are coded in a stylized way:
• Begin transaction
• Perform a series of read, update operations
• Terminate by commit or abort.

Begin
let employee t = Emp.Record(“Tony”);
t.status = “retired”;
 customer c: c.AccountRep==“Tony”
c.AccountRep = “Sally”
Commit; Space reserved for video
Do not put anything here

• System executes this code in an all-or-nothing way

Why is ACID Helpful

• Developer doesn’t need to worry about a

transaction leaving some sort of partial state
• For example, showing Tony as retired and yet leaving
some customer accounts with him as the account rep
• Similarly, a transaction can’t glimpse a partially
completed state of some concurrent transaction
• Eliminates worry about transient database
inconsistency that might cause a transaction to crash Space reserved for video
• Analogous situation: Thread A is updating a linked list Do not put anything here
and thread B tries to scan the list while A is running
Dangers of Replication
The Dangers of Replication and a Solution. Jim Gray, Pat Helland, Dennis Shasha.
Proc. 1996 ACM SIGMOD.

• Investigated the costs of transactional ACID model on replicated data

in “typical” settings
• Found two cases
• Embarrassingly easy ones: Transactions that don’t conflict at all (like Facebook updates
by a single owner to a page that others might read but never change)
• Conflict-prone ones: Transactions that sometimes interfere and in which replicas could
be left in conflicting states if care isn’t taken to order the updates
• Scalability for the latter case will be terrible
• Solutions they recommend involve sharding and coding transactions
to favor the first case Space reserved for video
• Show that even under very optimistic assumptions, slowdown will Do
benot put anything here
O(n2) in size of replica set (shard)
• If approach is naïve, O(n5) slowdown is possible!
This Motivates BASE
D. Pritchett. BASE: An Acid Alternative. ACM Queue, July 28,
2008.
• Proposed by eBay researchers
• Found that many eBay employees came from
transactional database backgrounds and were used to
the transactional style of “thinking”
• But the resulting applications didn’t scale well and
performed poorly on their cloud infrastructure
Space reserved for video
• Goal was to guide that kind of programmer to a Do not put anything here
cloud solution that performs much better
• BASE reflects experience with real cloud applications
• “Opposite” of ACID
BASE is a Methodology

• BASE involves step-by-step transformation

of a transactional application into one that will
be far more concurrent and less rigid
• But it doesn’t guarantee ACID properties
• Argument parallels (and actually cites) CAP: They
believe that ACID is too costly, and often, not
needed
• BASE stands for “Basically Available Soft-State Space reserved for video
Do not put anything here
Services with Eventual Consistency”
BASE Terminology
• Basically Available: Fast response even if some replicas are
slow or crashed
• BASE paper: In data centers, partitioning faults are very rare and are
mapped to crash failures by forcing the isolated machines to reboot
• Soft-State Service: No durable memory
• Can’t store any permanent data
• Restarts in a “clean” state after a crash
• To remember data, either replicate it in memory in enough copies to
never lose all in any crash, or pass it to some other service that keeps
“hard state”
• Eventual Consistency: OK to send “optimistic” answers to the
external client Space reserved for video
• Could use cached data (without checking for staleness) Do not put anything here
• Could guess at what the outcome of an update will be
• Might skip locks, hoping that no conflicts will happen
• Later, if needed, correct any inconsistencies in an offline cleanup
activity
BASE vs. ACID

• ACID code often much too slow, scales poorly,

and end-user waits a long time for responses
• With BASE
• Code itself is way more concurrent, hence faster
• Elimination of locking, early responses, all make end-
user experience snappy and positive
• But we do sometimes notice oddities when we look
hard Space reserved for video
• Slightly different bidding histories shown to different Do not put anything here
people shouldn’t hurt much, if this makes eBay 10x faster
• Upload a YouTube video, then search for it  You may not
see it immediately