'Is it possible to implement Multi-Version Concurrency Control (MVCC) on top of MongoDB?
MongoDB is to me a great database. However there are cases where I really need atomic multi-document transactions. For example to transfer things (like money or reputation) between accounts and this needs to either succeed completely or fail completely.
I wonder if it would be possible to interact with MongoDB through a library implementing the MultiVersion Concurrency Control pattern.
How bad would it be concerning performances? Would it be possible and profitable to use a hybrid approach, using the 'mongo-mvcc' library only when necessary and the traditional db connection when working only on a single document or would this break the mvcc stuff ?
Solution 1:[1]
Money transaction can be implemented via two-phase commit : http://www.mongodb.org/display/DOCS/two-phase+commit
Solution 2:[2]
There is an implementation of MVCC on MongoDB available now on GitHub:
Solution 3:[3]
MongoDB isn't really designed to work with transactions. There is a really good discussion of how you might be able to implement this over at: http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/
Solution 4:[4]
You could create a versions collection and have a document for the last committed version.
Atomically update this document with the Read Timestamp (rts) which is not a time based timestamp but a monotonically increasing number when your application code has read a document from a collection.
Before you update a collection, fetch this versions collection document and check if there is a read timestamp below your current transaction, if there is, abort the read or write.
Update the versions document when you want to "publish" with a lastCommit the version of a record and cause it to be visible.
You should only "see" transactions data that are less than or equal to the last committed transaction number.
I implemented MVCC in Java in this repository.
Solution 5:[5]
Well when you need real TRANSACTIONS you use RDBMS which are designed to support them :) NoSQLs are faster and more scalable mainly because they don't support transactions.
If you need both maybe it's a good idea to have transactional layer to support transactions and NoSQL layer for other purposes? In some cases it shouldn't be difficult to create a hybrid system using for example MongoDB and PostgreSQL
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | fun_vit |
| Solution 2 | Thorsten Reitz |
| Solution 3 | Leonard Garvey |
| Solution 4 | Samuel Squire |
| Solution 5 | Daimon |