molecular transactions g. ramalingam kapil vaswani rigorous software engineering, msri
TRANSCRIPT
Molecular Transactions
G. RamalingamKapil Vaswani
Rigorous Software Engineering, MSRI
Simple banking application
Rigorous Software EngineeringMicrosoft Research, India
let transfer from to amount =atomic {
match hasBalance from amount with
| true -> debit from amountcredit to amountSUCCESS| false ->
INSUFFICIENT_BALANCE}
Applicationserver
Database
Account#
Name Balance
XXXX0123 ABC 10000
XXXX3452 XYZ 20000
ACID Transaction
Rigorous Software EngineeringMicrosoft Research, India
?
Scalable applications
• Support lots of users– TBs of data!– Many concurrent transactions– Unpredictable workload
• Key requirements– Available– Fault tolerant– Data consistency
• Achieving all at the same time non-trivial!
Rigorous Software EngineeringMicrosoft Research, India
Applicationserver
RelationalDatabase
Rigorous Software Engineering Microsoft Research, India
Designing for scale
Rigorous Software Engineering Microsoft Research, India
Scaling application tier
Applicationserver
Database
Rigorous Software Engineering Microsoft Research, India
Replication
Applicationserver
Replica Replica Replica
Rigorous Software Engineering Microsoft Research, India
Data partitioning
Applicationserver
Datapartition
Datapartition
A first-class citizen in cloud based storage systems
Horizontal data partitioning
Rigorous Software EngineeringMicrosoft Research, India
let transfer from to amount =let status = atomic {match hasBalance from amount with| true -> debit from amountDEBIT_COMPLETE| false -> INSUFFICIENT_BALANCE}
atomic {match status with| DEBIT_COMPLETE ->
credit to amount
SUCESSS| _ ->
INSUFFICIENT_BALANCE}
Databasepartition
Databasepartition
Branch Account#
Name Balance
XXXX01 XXXX0123
ABC 10000
Branch Account#
Name Balance
XXXX34 XXXX3452
XYZ 20000
Distributed transactions do not scale
Azure tables, BigTable, Dynamo do not support distributed transactions!
Distributed vs. local transactions
Consistency
Rigorous Software EngineeringMicrosoft Research, India
let transfer from to amount =let status =
atomic {match hasBalance from amount with| true -> debit from amountDEBIT_COMPLETE| false -> INSUFFICIENT_BALANCE}
atomic {match status with| DEBIT_COMPLETE ->
credit to amount
SUCESSS| _ ->
INSUFFICIENT_BALANCE}
Databasepartition
Databasepartition
Account#
Name Balance
XXXX0123 ABC 5000
Account#
Name Balance
XXXX3452 XYZ 20000
Rigorous Software EngineeringMicrosoft Research, India
Compute failures
Rigorous Software EngineeringMicrosoft Research, India
let transfer from to amount =let status = atomic {match hasBalance from amount with| true -> debit from amountDEBIT_COMPLETE| false -> INSUFFICIENT_BALANCE}
Databasepartition
Databasepartition
Account#
Name Balance
XXXX0123 ABC 5000
Account#
Name Balance
XXXX3452 XYZ 20000
Server failures
Handling compute failures
Rigorous Software EngineeringMicrosoft Research, India
let transfer from to amount =let status = atomic {match hasBalance from amount with| true -> debit from amountDEBIT_COMPLETE| false -> INSUFFICIENT_BALANCE}
Databasepartition
Databasepartition
Account#
Name Balance
XXXX0123 ABC 5000
Account#
Name Balance
XXXX3452 XYZ 20000
atomic {match status with| DEBIT_COMPLETE ->
credit to amount
SUCESSS| _ ->
INSUFFICIENT_BALANCE}
Checkpointstorage
There’s more…logical failures
Rigorous Software EngineeringMicrosoft Research, India
let transfer from to amount =let status = atomic {match hasBalance from amount with| true -> debit from amountDEBIT_COMPLETE| false -> INSUFFICIENT_BALANCE}
Databasepartition
Databasepartition
Account#
Name Balance
XXXX0123 ABC 5000
Account#
Name Balance
XXXX3452
XYZ 20000
What if credit fails?
e.g. account closed
Handling logical failures withcompensating actions
Rigorous Software EngineeringMicrosoft Research, India
let transfer from to amount =let status = atomic {match hasBalance from amount with| true -> debit from amountDEBIT_COMPLETE| false -> INSUFFICIENT_BALANCE}
Credit fails
let compensate from amount =atomic {
credit from amount}
Molecular transactionsFault-tolerant composition of atomic
transactions with compensating actions
Rigorous Software EngineeringMicrosoft Research, India
atomic {
}
atomic {
}⇋
atomic {
}
atomic {
}⇋
⊗molecule {
}
Account transfer with MTlet transfer from to amount =
molecule {do! atomic {
match hasBalance from amount with
| true -> debit from amount| false -> abort} |> compensateWith <|atomic { credit from amount }
return! atomic {match exists to with| true -> credit to amount| false -> abort}
}
Rigorous Software EngineeringMicrosoft Research, India
First atomic step
Compensation
Second atomic step
Hides • Serialization• Messaging• Fault tolerance
No isolation• Compensating
actions must semantically undo
Implementation
Rigorous Software EngineeringMicrosoft Research, India
System model
• Compute agents–May fail at any time – System detects failure and restarts
agents– All agent-local state is lost
• Partitioned storage– Partitions are units of serializability
• Persistent queue– Communication between agents
Rigorous Software EngineeringMicrosoft Research, India
Persistent queue
• Not really a queue!– Out-of-order– At-least once
• Operations– Enqueue(m)– Get() • Gets a message, makes message invisible• Message re-appears if not dequeued
– Dequeue(m)• Permenantly deletes the message
Rigorous Software EngineeringMicrosoft Research, India
Tolerating agent failures
• Agent can fail between transactions• Check-pointing– Check-point state after every transaction
Rigorous Software EngineeringMicrosoft Research, India
Check-pointing
Rigorous Software EngineeringMicrosoft Research, India
𝑎1
Enqueue Read
Databasepartition
𝑎2
Databasepartition
𝑎3
Dequeue
Compute failures
Rigorous Software EngineeringMicrosoft Research, India
Read
𝑚𝑎❑
Databasepartition
𝑚 ′
Dequeue
Enqueue
• Transactions may be evaluated more than once!• Messages may be
sent more than once!
Idempotence
• Instrument transactions for idempotence– Assumes key-value store with a unique
key constraint– Assign each atomic step in each MT a
unique id– Add (unique id, return value) to write set– Idempotence log in transaction’s
partition
• If transaction evaluates more than once– Unique key violation causes transaction
failure– Return stored value
Rigorous Software EngineeringMicrosoft Research, India
Summary
• Molecular transactions– Language abstraction for programming weakly
consistent applications– Hides messaging, queuing, fault tolerance– Expressed using a monad, lends to declarative,
bug-free code
• Efficient implementation on cloud based storage systems– Does not require 2PC!– Built a number of applications on Azure– < 10% overheads over hand-written code
Rigorous Software EngineeringMicrosoft Research, India
Open questions
• Specifying and reasoning about correctness of molecular transactions
• Declarative ways of making consistency/performance trade-offs
• Do cloud-based systems provide right primitives?
Rigorous Software EngineeringMicrosoft Research, India
Thank you
Questions?
Rigorous Software EngineeringMicrosoft Research, India