Authors University of Texas Austin Chao Xie Chunzhi Su Manos Kapritsos Yang Wang Navid Yaghmazadeh Lorenzo Alvisi Prince Mahajan Presented By Sharanya Bathey The tale of ACID Transaction ID: 1030410
Download Presentation The PPT/PDF document "Salt: Combining ACID and BASE in a Distr..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. Salt: Combining ACID and BASE in a Distributed DatabaseAuthors (University of Texas Austin): Chao Xie, Chunzhi Su, Manos Kapritsos, Yang Wang, Navid Yaghmazadeh, Lorenzo Alvisi, Prince Mahajan Presented By:Sharanya Bathey
2. The tale of ACID…Transaction - Basic unit of work in an RDBMSACIDAtomicity: all or nothingConsistency: always leave a database in a consistent stateIsolation: every transaction is completely isolatedDurability: once committed always recordedImage Source
3. The tale of ACID…(Oh No!)What needs to be done to achieve this abstraction?2 Phase CommitLocksWhat baggage do such abstractions come with?Performance is sacrificedImage Source
4. Rise of BASE…BASEBasically Available - does guarantee availability, in terms of CAP theoremSoft State - State of the system may change over timeEventually Consistent - data will be consistent at replicas eventuallyImage Source
5. Rise of BASE… (What now?)Problem?Complexity of programmingConsistency ManagementImage Source
6. Is there no middle ground?Pareto Principle - 80-20 RuleExample:Fusion Ticket (open source ticketing application)Total of 11 different types of Transactions of which just 2 are performance critical
7. Introducing… BASE transactionsManually Identify the key transactions that cause the performance bottleneckBase-ify these transactions by breaking the transaction into alkaline sub transactions which are still contained within the same BASE transaction
8. Example of Base-iying an ACID transactionAcid TransactionBase-fied Transaction
9. But the problem being?Acid TransactionBase-fied Transactions
10. Solution being? Restrict Interaction ACID BASE Alkaline ACID No No No BASE No Yes* Yes* Alkaline No Yes* Yes*** - intermediate committed state of alkaline sub transactions** - only read alkaline sub transactions
11. Base Transactions (Contd…)Major life events of BASE transactions: Accept & CommitHow does a BASE transaction provide ACID abstraction?Atomicity - once accepted will eventually commitConsistency - Interactions keep ACID and BASE transactions isolatedIsolation - SALT Isolation coming up next..Durability - Accepted BASE transactions are guaranteed to be durable through logging
12. Uses Locks - Isolation level chosen is Read CommittedLocks:ACID Locks - write with any other operation conflictsAlkaline Locks - alkaline sub transactions isolated from ACID and other alkaline sub transactionsSaline Locks - ACID isolated from BASE, but increased concurrency by exposing intermediate state to of BASE transactions to other BASE transactionsIntroducing the MVP – Salt Isolation
13. So does it actually work?Implementation:Modified MySQL to allow BASE transactions and Alkaline Sub-transactionsAllow alkaline and saline locksOptimizations:Early commit - A client that issues a BASE transaction sees the transaction completion when when its first Alkaline sub transaction commitsFailure recovery - Logging with redo and roll forwardTransitive dependencies - Per object queueLocal TransactionsReplication of data was done across 10 partitions and each partition was three-way replicatedEvaluated: Performance Gain, Programming Effort, Contention Ratio
14. Case Study
15. Applications used for the experimentsTPC-C benchmark : database performance standard5 transactions (new-order, payment, stock-level, order-status and delivery)New-order and payment are responsible for 43.5% of total number of transactions Fusion Ticket: open source ticketing application in PHP and MySQLIncludes several transactionsCreate-order and payment most frequent and performance criticalMicro benchmark:Contention ratioContending transaction positionRead-Write ratio
16. Did Salt win the award? (Yes…)6.6x higher6.5x higherBase-ify: Create-order and paymentBase-ify: new-order and payment
17. Did Salt win the award? (Contd...)Performance gain becomes stagnant
18. Did Salt win the award? (Contd…)
19. Discussion & Q-APros:Performance gain is drasticControl in the hands of the programmerCons:Cassandra allows batching of commands into groups to form transactions called atomic batchesLeverage the power of MySQL clusters - MySQL does not allow nested transactions and MySQL now has several NoSQL/NewSQL like featuresProgramming complexity - the difficulty of identifying the transactions that need to be converted and verifying the correctness is a daunting task
20. Thank You!