Popular posts

Dario Cangialosi you can downvote :) I don't mind.

I just said I would take it, not you should take it. Frankly you could've just pointed out that MVVC is spelled wrong and it means MVCC and stands for "multi version concurrency" and is supported more or less by any major database :) ... So this would be a fact, not a taste discussion where you can complain that I need to explain to you why I would take something ... but the main point was to say -> think of what you need.

Once again ... I said "I take" .... not it's the only one .... nor you should take, I just wrote some examples.

---

But to make it clear why I to some extend prefer the MVCC of the SQL engines.

SQL supports transactions, every transaction is finished when it's written to the 1 single data storage - I will not get into the details of how which engine lock what -

SQL picks CP of CAP hence it will rather loose availability than consistency.

since SQL is not a noSQL engine it's not built for distributed sharding but for a classic replication.

So circling back to the transaction, a SQL transaction is finished when it's written to disc. Since there is only 1 database, again I have to point out it's per default behavior not by a replication setup with STONITH or Master - Master or infinity sequences and we're not taking in account that if you're on VM-Ware the VM actually sends the ACK while the data is not persisted.

So a classic SQL instance, not what you can build around it. As soon as you've written the transaction it will be "true" for the next one.

So anytime I execute concurrent SQL statements within a transaction the second one will get an error and has to retry.

That's a behavior I like but you're right I could go with the mongodb MVCC as well or the couchDB MVCC or the kafka MQ MVCC

just to point out different behaviours:

couchDB basically will save every version of the data as a list and will accept all request all the time. So for the version handling you have to pass the version id of your dataset and you have to resolve your conflicts yourself.

Kafka used DSM deterministic state-machines where it will take concurrent writes and just distributes them across partitions (I know pulling a MQ in here is kinda off topic) it's as well a list based system where a central index defines ranges on partitions it's an "send at least once" system.

MongoDB uses BASE transactions to my knowledge the problem with mongoDB is can return you the "old" dataset on read because it's async.