aviondb / aviondb

A decentralised database with MongoDB-like developer interface (Fully Compatible with OrbitDB)

Home Page:https://twitter.com/aviondb

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Will AvionDb support multi-document atomic transactions?

ChristianKleineidam opened this issue · comments

Many databases have atomic transactions. That's useful because it prevents you from bringing your data into a bad state when a part of a transaction that goes over multiple document fails.

Will AvionDb support multi-document atomic transactions or will it in that regard be like MongoDb which doesn't?

commented

@ChristianKleineidam Transactions are already in our Feature List that we are working on #8

If this answers your question, feel free to close this issue 😉

The feature list isn't specific about whether the transactions in the future list will be atomic for multiple documents or not. It links to MongoDb description of Transactions and MongoDb transactions that go over multiple documents aren't atomic and speaks about atomicity. Whether that atomicity is per document such as in MongoDb or over multiple documents like in Firestore is an important question.

commented

@ChristianKleineidam Good point, we should add more details to the feature list in this regard. We're planning to have transaction atomicity for multiple documents like in Firestore.

I think transaction atomicity is a very valuable feature but I don't think it's trivial to say "we'll include it". MongoDb and CouchDb have reasons for not including it.

In a database of a few terabyte and 1000s of users of the database who sync with each other in a decentralized way resolving transactions takes a lot of work.

If it would be easy to simply add transaction multi-document atomicity in MongoDb's design, MongoDb would already have done it.

I think it would be great to see discussion of tradeoffs in some design document.

Some explanation on how aviondb works under the hood in regards to operations. When a document is modified in any fashion (Whether its multiple or a single one at once). When the operation is first started, the system will search the database for the specified query. Returning a list of IDs. When the operation is broadcasted to the network it includes the operation modifier, and list of IDs to modify. This prevents conflicts of modifying all documents some of which may have not yet propagated across the entire network.

The part on preventing modification conflicts in being looked into. Something like including a StateHash in each operation can mitigate or at least detect operation conflicts.