MongoDB World 2018: How and When to Use Multi-Document Distributed Transactions
Download as PPTX, PDF0 likes280 views
This document discusses when and how to use multi-document transactions in MongoDB. It provides examples of use cases for transactions, such as processing related data across multiple collections atomically. It also describes characteristics of transactions, including all-or-nothing execution, snapshot isolation, and how write conflicts are handled by aborting transactions. Considerations for transactions in a production environment are discussed, such as replication and cache pressure. Guidelines are given for avoiding cache pressure and retrying transactions.
![{_id: “OWNER12345”,
name: { first: “Aly”,
last: “Cabral”},
accountType: “Paid”,
pets: [ { type: “Dog”,
name: “Lady”}],
contact: { phoneNumber: 8008675309},
Address: { city: “New York”,
street: “94th”,
zipecode: 10025}}
So now you have transactions…
@aly_cabral
Owners
ID First Name Last Name Account Type
Pets
ID Name Type Weight OwnerID
Address
ID Street City OwnerID
Contact
ID Phone Number OwnerID](https://image.slidesharecdn.com/gramercyw935-alycabralmdbw18transactions-180703172845/85/MongoDB-World-2018-How-and-When-to-Use-Multi-Document-Distributed-Transactions-4-320.jpg)
![Read Your Own Writes
@aly_cabral
Operation
Read
TXN
{_id: “OWNER12345”,
name: { first: “Aly”,
last: “Cabral”},
accountType: “Paid”,
pets: [ { type: “Dog”,
name: “Lady”}],
contact: { phoneNumber: 8008675309},
Address: { city: “New York”,
street: “94th”,
zipecode: 10025}}
Uncommitted Writes
street: “92nd”
Address.street = 94th
Address.street = 92nd](https://image.slidesharecdn.com/gramercyw935-alycabralmdbw18transactions-180703172845/85/MongoDB-World-2018-How-and-When-to-Use-Multi-Document-Distributed-Transactions-11-320.jpg)
![@aly_cabral
TXN
Write
TXN
Write
{_id: “OWNER12345”,
name: { first: “Aly”,
last: “Cabral”},
accountType: “Paid”,
pets: [ { type: “Dog”,
name: “Lady”}],
contact: { phoneNumber: 8008675309},
Address: { city: “New York”,
street: “94th”,
zipecode: 10025}}
street: “94th”
No-op writes are not writes
Only writes make write conflicts](https://image.slidesharecdn.com/gramercyw935-alycabralmdbw18transactions-180703172845/85/MongoDB-World-2018-How-and-When-to-Use-Multi-Document-Distributed-Transactions-17-320.jpg)
MongoDB World 2018: How and When to Use Multi-Document Distributed Transactions
- 1. How and When to Use Multi-Document Transactions @aly_cabral
- 2. ALYSON CABRAL Product Manager – Distributed Systems, MongoDB @aly_cabral
- 4. {_id: “OWNER12345”, name: { first: “Aly”, last: “Cabral”}, accountType: “Paid”, pets: [ { type: “Dog”, name: “Lady”}], contact: { phoneNumber: 8008675309}, Address: { city: “New York”, street: “94th”, zipecode: 10025}} So now you have transactions… @aly_cabral Owners ID First Name Last Name Account Type Pets ID Name Type Weight OwnerID Address ID Street City OwnerID Contact ID Phone Number OwnerID
- 5. Transactions Use Cases @aly_cabral Many to Many Relationships Positions and Trades Event Processing Account Creation Application Event Logging Application Auditing
- 6. with client.start_session() as s: s.start_transaction(): try: owners.insert_one(doc1, session=s) owners.insert_one(doc2, session=s) except: s.abort_transaction() raise s.commit_transaction() @aly_cabral
- 9. All or Nothing Execution @aly_cabral TXN Application MongoDB Uncommitted Writes { Document 1 } { Document 2 } { Document 3 } Committed Writes
- 10. Snapshot Isolation @aly_cabral 100 101 102 103 104 105 106 107 108 109 110 111 Snapshot 102 Snapshot 108
- 11. Read Your Own Writes @aly_cabral Operation Read TXN {_id: “OWNER12345”, name: { first: “Aly”, last: “Cabral”}, accountType: “Paid”, pets: [ { type: “Dog”, name: “Lady”}], contact: { phoneNumber: 8008675309}, Address: { city: “New York”, street: “94th”, zipecode: 10025}} Uncommitted Writes street: “92nd” Address.street = 94th Address.street = 92nd
- 12. Write Conflicts
- 13. @aly_cabral TXN Write TXN Write {Doc 1} TXN write is unable to obtain a write lock! TXN is ABORTED rolledback entirely
- 14. @aly_cabral TXN Write Operation Non-Transactional Write {Doc 1} Operation Blocks Behind TXN Commit Infinitely retries with Backoff Logic until MaxTimeMS is reached Operation non-transactional write is unable to obtain a write lock!
- 15. @aly_cabral When non-transactional writes encounter write conflicts Operation Blocks Behind TXN Commit Infinitely retries with Backoff Logic until MaxTimeMS is reached When transactions encounter write conflicts Transactions abort rollback entirely
- 16. @aly_cabral TXN Read TXN Write {Doc 1} Reads do not lock a document from being modified Only writes make write conflicts
- 17. @aly_cabral TXN Write TXN Write {_id: “OWNER12345”, name: { first: “Aly”, last: “Cabral”}, accountType: “Paid”, pets: [ { type: “Dog”, name: “Lady”}], contact: { phoneNumber: 8008675309}, Address: { city: “New York”, street: “94th”, zipecode: 10025}} street: “94th” No-op writes are not writes Only writes make write conflicts
- 19. @aly_cabral P S S Writes are replicated once committed
- 20. @aly_cabral … … keys K K K KVV V V txn time data next Update Structure txn time data next 1) Cache pressure builds up by write volume after a snapshot 2) Transactions use the same snapshot throughout it’s duration 3) The update structure can only be cleaned up after the snapshot is evicted WiredTiger Cache
- 21. @aly_cabral How to Avoid WiredTiger Cache Pressure: transactionLifetimeLimitSeconds = default to 60s Commit READ-ONLY Transactions Abort Abandoned Transactions <1000 Documents Modified, <16MB Oplog Entry
- 29. 1) All data modeling rules still apply 2) Transactions should not be the most common operation (sanity check for rule 1) 3) Pass in the session to all statements 4) Implement retry logic, transactions can always abort 5) Don’t unnecessarily leave snapshots open 6) To trigger write conflicts, make sure you’re doing writes 7) Plan for DDL Operations