MongoDB World 2018: Building a New Transactional Model
3 likes424 views
The document discusses MongoDB's development of ACID transactions over multiple releases. Key points include: - MongoDB added initial transaction support in 2.6 using MMAPv1 storage engine and document-level locking. - Version 3.0 introduced a new storage engine, WiredTiger, that supports multi-version concurrency control. - Later versions added features like causal consistency, prepared transactions, and secondary reads to enhance consistency. - MongoDB 4.0 introduced multi-document transactions across replica sets using the storage engine's prepared transaction support. - Future work may integrate oplog and journaling further and use timestamps for cross-shard transactions.
MongoDB World 2018: Building a New Transactional Model
- 1. MongoDB: A New Transactional Model keith.bostic@mongodb.com
- 2. Keith Bostic keith.bostic@mongodb.com Distinguished Engineer, MongoDB Inc. Welcome!
- 3. MongoDB: A New Transactional Model keith.bostic@mongodb.com
- 5. Relational vs document data modeling
- 6. Goals: performance and complexity
- 7. Goals: application domains, programmer models
- 8. Goals: checkboxes and vendor lock-in
- 9. Application developers are the focus
- 10. But not the only audience
- 11. “ACID transactions are a key capability for business critical transactional systems, specifically around commerce processing. No other database has both the power of NoSQL and cross collection ACID transaction support.This combination will make it easy for developers to write mission critical applications leveraging the power of MongoDB.” -- Dharmesh Panchmatia, Director of E-commerce, Cisco Systems
- 12. ACID
- 15. Consistency, availability, partition tolerance
- 18. MongoDB World talk! Transactions and Durability: Putting the “D” in ACID -- Sue LoVerso, Senior Engineer, MongoDB
- 19. The Path
- 20. Multi-year, all-hands company effort • The storage layer,
- 21. Multi-year, all-hands company effort • The storage layer, • Sharding architecture,
- 22. Multi-year, all-hands company effort • The storage layer, • Sharding architecture, • Introducing a global logical clock,
- 23. Multi-year, all-hands company effort • The storage layer, • Sharding architecture, • Introducing a global logical clock, • Replication consensus protocol,
- 24. Multi-year, all-hands company effort • The storage layer, • Sharding architecture, • Introducing a global logical clock, • Replication consensus protocol, • Metadata management, … and that’s just part of the list!
- 25. Multi-year, all-hands company effort • The storage layer, • Sharding architecture, • Introducing a global logical clock, • Replication consensus protocol, • Metadata management, … and that’s just part of the list! Not forgetting the driver teams, documentation and education.
- 26. MongoDB 2.6: mmapv1 with ACID 2.6 P S S S
- 27. The “storage engine” is part of the MongoDB database server. It’s where the actual data lives. Detour: the storage engine networking, sharding, replication, drivers analytics, middleware, query optimizer storage engine
- 28. Detour: the storage engine Single Node
- 29. MongoDB’s pluggable storage architecture • MMAPv1 • RocksDB (Facebook) • TokuMX (TokuTek) • WiredTiger
- 30. MongoDB 3.0: a new storage engine 2.6 3.0 B-D Keys E-I Keys J-N Keys F Keys & Values E Keys & Values G Keys & Values Write-heavy workloads Document level locking Compaction Encryption Compression In-Memory
- 31. MongoDB 3.0: transactional features 2.6 3.0
- 32. MongoDB 3.2 P S S S:w “majority” readConcern 2.6 3.0 3.2
- 33. MongoDB 3.4 2.6 3.0 3.43.2
- 34. MongoDB 3.6: transactional features 2.6 3.0 3.63.43.2 P S S S logical sessions global clock … leads to causal consistency
- 35. MongoDB 3.6: enhanced consistency 2.6 3.0 3.63.43.2 P S S S secondary reads retryable writes read concern majority
- 36. MongoDB University video Implementation of Cluster-Wide Causal Consistency in MongoDB -- Misha Tyulenev, Engineer, MongoDB
- 37. MongoDB 4.0: multi-document transactions 2.6 3.0 3.63.43.2 4.0 P S S S
- 38. MongoDB 4.0: prepared transactions 2.6 3.0 3.63.43.2 4.0 Commit? Yes Yes Commit! Phase One Phase Two
- 39. MongoDB 4.X 2.6 3.0 3.63.43.2 4.0 P S S S PS S 4.X
- 40. MongoDB World talk! What’s Next? The Path to Sharded Transactions -- Andy Schwerin, VP, Engineering, MongoDB
- 41. Why is this work hard?
- 42. Reason #1: single-node ordering vs. group ordering MongoDB WiredTiger
- 43. Replication example ... 37 38 39 ... 37 38 39 ... 37 38 39 ... 37 38 39 Primary Oplog Secondary reads
- 44. Multi-threaded secondary oplog application OpLog ... 37 38 39 40 4241 Primary oplog order Secondary apply order 40 39 41 38
- 45. “People assume that time is a strict progression of cause to effect, but actually, from a non-linear, non-subjective point of view, it is more like a big ball of wibbily-wobbly timey-wimey … stuff.” -- Doctor Who
- 46. Reason #2: increasing entanglement Getting the right answer requires communication.
- 47. Timestamps
- 48. MongoDB’s timestamp ... 40 4138 39 42 ACID for a set of systems durability based on replication
- 49. WiredTiger’s transaction ID ... 40 4138 39 42 ACID for a single-node durability based on checkpoints and journaling
- 50. MongoDB timestamp overrides WiredTiger ID 64-bit counter fast comparisons strictly increasing MSB hex API
- 51. MongoDB secondary example Set the timestamp at update or commit OpLog ... 37 38 39 40 4241 Primary oplog order Secondary timestamp order ... 37 38 39 40 4241
- 52. Timestamp stored with each MVCC update FRUIT mango apple banana TXN ID TIMESTAMP
- 53. Overlapping reads with oplog application Secondary timestamp order ... 37 38 39 40 4241 Timestamp #1 Timestamp #2 3.6 4.0 Blocking Parallel
- 54. Queries can be “as of” a timestamp set at transaction begin largest LTE value
- 56. Durability based on the “stable” timestamp
- 57. Replication rollback for a single server ... 37 38 39 40 4241 Primary Oplog ... 37 38 39 117 119118 Corrected (Secondary) Oplog Replacements
- 59. Sydney & New York
- 60. Keith Bostic keith.bostic@mongodb.com Distinguished Engineer, MongoDB Inc. Thank you!
- 61. WiredTiger and transactions • Per-thread “session” structure embodies a transaction
- 62. WiredTiger and transactions • Per-thread “session” structure embodies a transaction • Session structure references data-sources: cursors
- 63. WiredTiger and transactions • Per-thread “session” structure embodies a transaction • Session structure references data-sources: cursors • Transactions are implicit or explicit (scope determined by the application) • session.begin_transaction() • session.commit_transaction() • session.rollback_transaction() // Abort • Transactions could always span objects and data-sources
- 64. Sample key-value store CRUD transaction cursor = session.open_cursor(“some collection”); session.begin_transaction();
- 65. Sample key-value store CRUD transaction cursor = session.open_cursor(“some collection”); session.begin_transaction(); cursor.set_key(“fruit”); cursor.set_value(“apple”); cursor.insert();
- 66. Sample key-value store CRUD transaction cursor = session.open_cursor(“some collection”); session.begin_transaction(); cursor.set_key(“fruit”); cursor.set_value(“apple”); cursor.insert(); cursor.set_key(“fruit”); cursor.set_value(“banana”); cursor.update();
- 67. Sample key-value store CRUD transaction cursor = session.open_cursor(“some collection”); session.begin_transaction(); cursor.set_key(“fruit”); cursor.set_value(“apple”); cursor.insert(); cursor.set_key(“fruit”); cursor.set_value(“banana”); cursor.update(); session.commit_transaction(); cursor.close();
- 68. MongoDB on top of WiredTiger • MongoDB maps the document model on top of this key/value model • For example • A single document change involves indexes • Multiple cursors updating a collection and its indexes • Glue layer below the pluggable storage API • 14K lines of code
- 69. WiredTiger transaction information • 64-bit transaction ID
- 70. WiredTiger transaction information • 64-bit transaction ID • Isolation level and other snapshot information • Read-uncommitted: everything • Read-committed: committed updates after start • Snapshot: committed updates as of start
- 71. WiredTiger transaction information • 64-bit transaction ID • Isolation level and snapshot information • Read-uncommitted: everything • Read-committed: committed updates after start • Snapshot: committed updates as of start • Linked list of change records • For logging on commit, discard on rollback
- 72. MongoDB 4.0 • Multi-document transactions in a replica set • Storage engine support for prepared transactions • Replica set point-in-time reads • Recovery to a timestamp • Performance enhancement so operations only rolled forward
- 73. Right the order in getting ... 37 38 39 ... 37 39 38 Oplog WiredTiger Operations
- 74. The storage problem is concurrency control • Engines support lots of concurrency to increase throughput • Traditionally, the storage layer decides how operations interleave
- 75. Well, there’s durability as well • Engines support lots of concurrency to increase throughput • Traditionally, the storage layer decides how operations interleave • The storage layer is also responsible for single-node crash recovery If the storage layer owns concurrency and durability … the rest of the system can ignore the details
- 76. Future use of timestamps: 4.0++ • Global snapshot reads • 2-phase commit for transactions that span shards • Unified oplog and WiredTiger journal • Reducing pain of write amplification • Originally 4 data copies (oplog and collection, plus 2 x journal)
- 77. Background: majority commits ... 37 38 39 ... 37 38 39 ... 37 38 39 ... 37 38 39 Primary Oplog Secondary reads
- 78. WiredTiger • Multi-row and multi-table transactions • Document level locking • Multi-version concurrency control (MVCC) FRUIT MANGO APPLE BANANA
- 79. Future use of timestamps: 4.0++ • Global snapshot reads 2-phase commit for transactions that span shards Rollback all changes if any shard cannot commit Make commits visible at a common timestamp across shards