Navigating Transactions: ACID Complexity in Modern Databases- Mydbops Open Source Database Meetup 15
0 likes41 views
The document discusses the complexities of implementing transactions in modern databases while considering ACID properties, scalability, and performance trade-offs. It explores historical perspectives on transaction systems, details on distributed transactions, and various implementation challenges, including two-phase commit and its alternatives. Additionally, it highlights specific database solutions such as Amazon Aurora, DynamoDB, and Google Spanner, focusing on their transaction handling and coordination methods.
Navigating Transactions: ACID Complexity in Modern Databases- Mydbops Open Source Database Meetup 15
- 1. Shivji Kumar Jha Navigating Transactions ACID Complexity in Modern Databases 1
- 2. Data Platforms & OSS • Databases, streams, app architecture • Loves open source software (OSS) • And communities (meetups) • Regular speaker ( talk # 23) • Sta ff Engineer at Nutanix Shivji Kumar Jha https://www.linkedin.com/in/shivjijha https://youtube.com/@ShivjiKumarJha https://t.me/theDbShots 2
- 3. • Transactions & ACID • Implementing Transactions • Distributed transactions • Cloud scale databases Contents 3
- 5. Transactions Historical Perspective Almost all relational and even some non relational databases Most of them follow system R - first SQL DB by IBM in 1975. General ideas has remained same over 45+ years MySQL, Postgres, Oracle, SQL server have similar transactions 5
- 6. Transactions Historical Perspective Transactions are antithesis of scalability Large scale systems have to abandon transaction Go for good performance and high availability 6 Transactions are essential requirements for serious applications with valuable data NoSQL Camp SQL Camp
- 7. Transactions Historical Perspective Transactions are antithesis of scalability Large scale systems have to abandon transaction Go for good performance and high availability 7 Transactions are essential requirements for serious applications with valuable data NoSQL Camp SQL Camp Both are exaggerated! Trade-offs!
- 8. 8 Coined in 1983 by Theo Harder and Andreas Reuter
- 9. Atomicity Consistency Isolation Durability 9 Coined in 1983 by Theo Harder and Andreas Reuter
- 10. The slippery slope! In practice, one database’s implementation of ACID does not equal another’s implementation For example, a lot of ambiguity in meaning of “isolation” Devil is in details! When a system claims ACID, unclear what guarantees it provides ACID has unfortunately become a marketing term Transactions 10
- 11. How about 11
- 12. • ALL OR NOTHING! • Ability to undo (abort) • Easy to RETRY transactions 12 Atomicity ACID
- 13. Are retries really safe with transactions? 13
- 14. Are retries really safe with transactions? • Network failed while server tried to acknowledge commit to client. Retrying means executing twice. Idempotency or de-duplication required in app! • What if the error is due to overload? • Transient or permanent error? • What if transaction had side e ff ects? Send email again? • What if client fails while retrying? Data lost? 14
- 15. • Certain statements about data (invariants) always true • Database can’t promise • Application speci fi c guarantees • Most weakly de fi ned property in ACID 15 Consistency ACID
- 16. Isolation ACID • Many clients access data at the same time • Accessing same records you can run into concurrency problems (race) • Database guarantees concurrently executing transactions are isolated • Textbook de fi nitions- serializability - same result as running serially • In practice, serializability rarely used because of performance penalty • Actually snapshot isolation. Much weaker guarantee! 16
- 17. • Once committed, data written will not be forgotten • Even if there is a hardware fault or database crashes • Single node - write to HDD or SDD • Databases usually uses a write ahead log & dirty cached pages • Replicated databases - written to multiple nodes, wait until that happens! • No such thing as perfect durability ACID Durability 17 Picture: https://www.alphr.com/tell-regular-or-ssd-hard-drive/
- 19. Implementing Transactions Balance between two problems Improve E ffi ciency Preserve Correctness Allow transactions to execute concurrently Ensure concurrently executing transactions preserve ACID properties 19
- 20. Implementing Transactions Balance between two problems Improve E ffi ciency Preserve Correctness Allow transactions to execute concurrently Ensure concurrently executing transactions preserve ACID properties Concurrently executing transactions can cause read & write anomalies Isolation levels Concurrency Control Presence or absence of read & write anomalies How transactions are scheduled & executed 20
- 21. 21 Single Node Transactions Storage Engine’s responsibility
- 23. What if multiple nodes are involved in a Transaction? 23
- 24. Send a commit request to each node & independently commit? 24
- 25. 25 Send a commit request to each node & independently commit? • Some SUCCESS, some FAILURES! • Inconsistency between nodes • Abort if some FAILURES? • But you can’t go back on a committed promise! • How about a compensating transaction to o ff set changes? • Where does this responsibility sit? DB or App? • OR commit only if everyone promises to commit?
- 27. Atomic Commitment • A transaction will not commit even if one of the participating votes against it. • Failed processes have to reach the same conclusion as the rest of the cohort. • Does not work in the case of Byzantine failures- process can’t lie! • Cohorts can not choose, in fl uence or change proposed transaction, they can only vote on whether or not they are willing to execute it. • Executed by transaction manager or coordinator • Example: MySQL , Postgres, dynamoDB, spanner, Kafka for producer and consumer interactions. 27
- 29. Two Phase Commit • Coordinator (or transaction manager) a library within database server • When database is ready to commit, coordinator starts phase 1 • Coordinate sends prepare request to each node. Are you able to commit? • Coordinator tracks response from each participant • If all participants vote YES , coordinator sends COMMIT request in phase 2 • If any participant says NO, coordinator sends ABORT to all nodes in phase 2 • Coordinator must write decision in its log on disk to handle crashes 29
- 30. Two Phase Commit , Crash ( fi re) 30
- 31. Coordinator Failures Two Phase Commit • Two points of no return • 1. If Participant says YES, it has to commit if coordinator asks to. • 2. If coordinator decides once, decision is irrevocable • If participant said yes and didn’t hear back from coordinator, wait forever! • Coordinator must persist decision before it sends participants • If no COMMIT record persisted in coordinator, abort on recovery 31
- 32. Three Phase Commit? • 2PC is a blocking protocol • 3PC is non blocking • Di ffi cult to implement in practice. Not well adopted! • 2 PC quite well adopted in spite of known problems. 32
- 33. Distributed Transactions in Practice • Carries a heavy performance penalty • Additional fsync required for crash recovery • Addition network round trips • Distributed Transactions in MySQL are reported to be over 10 times slower than single node transactions. 33
- 34. Other Choices? • Single leader? Everyone else executes same transactions in same order! • Manually selected leader? • Automatic selection of leader? • O ffl oaded same problem to di ff erent time. Well less frequently! • Use Consensus Algorithms: Zookeeper (ZAB), etcd (Raft) , Paxos? • Global transaction order by reaching consensus on sequencer? Calvin(FaunaDB) • 2PC over consensus groups per shard? Enter Google’s Spanner! 34
- 35. Transactions in Modern Databases 35
- 36. Amazon Aurora 36
- 37. Quick Overview • Fully managed relational RDS • Service Oriented Design • Separation of Compute, storage • multi-tenant scale out storage • Segmented redo log • Throughput 5x MySQL, 3x Postgres Amazon Aurora 37
- 38. Aurora Functional Separation DB instance Query Processing Access Methods Transactions Locking Page Cache Undo Management Storage fl eet Redo logging Materialisation of data blocks Garbage collection Backup / Restore 38
- 39. Aurora: Quorum Style distributed coordination Not 2PC, to avoid network chatter! Read set & write set must overlap on at least one copy Write set must overlap with previous write sets 39
- 41. Dynamo DB Highly available, weaker consistency • Always “on” Key Value store, single key operations • Sacri fi ce consistency under failure scenarios. Eventually consistent! • Extensive use of object versioning, branching OK, resolve on read • Example: shopping cart; merges carts. Can’t loose write, deleted can appear • Consistency among replicas using quorum like technique (sloppy quorum) • Gossip based distributed failure detection (hinted hando ff s) 41
- 42. Dynamo DB Sloppy Quorum & hinted hando f • Each data item is replicated at N hosts. N distinct physical nodes • List of nodes storing a key is called it’s preference list • R : minimum no of nodes in successful read operation • W: minimum no of nodes in successful write operation 42
- 43. Dynamo DB Sloppy Quorum & hinted hando f • Each data item is replicated at N hosts. N distinct physical nodes • List of nodes storing a key is called it’s preference list • R : minimum no of nodes in successful read operation • W: minimum no of nodes in successful write operation 43
- 46. Transaction coordinator failure/recovery DynamoDB 46 https://www.infoq.com/articles/amazon-dynamodb-transactions/
- 48. Spanner Google’s globally distributed SQL* database • Also inspiration for cockroachDB and yugabyteDB • Tables with rows, columns and versioned values • Supports transactions and SQL based query language • Replication con fi gs dynamically controlled at fi ne grain by apps - which data- centre’s to use, how far from users(read latency), how far are replicas (write latency), how many replicas • Clients automatically failover between replicas • Data dynamically moved between data-centres to balance resources 48
- 49. 49
- 50. Span server stack & transactions 50
- 51. 51
- 52. References • Designing Data-Intensive Applications ( Chapter 7 & 9) By Martin Kleppmann • Database Internals (Chapter 5 & 13 ) By Alex Petrov 52 Books • Amazon Aurora: Design considerations for high throughput cloud native relational databases • Amazon Aurora: On avoiding distributed consensus…. • Dynamo: Amazon’s highly available key value store • Distributed Transactions at scale in Amazon DynamoDB • Spanner : Google’s Globally Distributed Database Whitepapers https://www.infoq.com/articles/amazon-dynamodb-transactions/ Blog