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.

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

4. Review & Motivations

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

13. Transactions: Acid

14. Transactions: aCid

15. Consistency, availability, partition tolerance

16. Transactions: acId

17. Transactions: aciD

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

55. The “oldest” timestamp

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

58. The “stable” timestamp

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