Looking at what they are providing, it's a shared nothing architecture, with data stored in ordered form. Technically, you can make this work in a very scalable fashion with an SSTable style store.
Think of it as LevelDB with a distributed B+ tree (or even just a few extra levels) handling the partitioning between nodes. That can scale quite well, and wrap updates and reads with snapshots at very low overhead to provide all the key bits to handle ACID in a distributed database.
What's problematic is when you have a transaction that span amongst several nodes and you need to reconcile several transactions (commit phase).
The usual way to do it is to refuse the transaction if a conflict is detected, however this is a real performance and useability issue for a NoSQL database.
What I'm implying is that if you have ACID transactions but they can fail very easily, you don't offer much...
It's not that hard to retry a transaction until some deadline is reached. Many programming languages have standard library facilities to make this extremely easy.
If the database is fast enough and transaction failure is at least moderately unlikely, it's not really an issue.
SSTable style databases are very cheap to snapshot, so you could totally handle this MVCC style. I buy the logic could get nutty in some pathological cases, but performance wise it shouldn't be much of a problem.
Comments
Looking at what they are providing, it's a shared nothing architecture, with data stored in ordered form. Technically, you can make this work in a very scalable fashion with an SSTable style store.
Think of it as LevelDB with a distributed B+ tree (or even just a few extra levels) handling the partitioning between nodes. That can scale quite well, and wrap updates and reads with snapshots at very low overhead to provide all the key bits to handle ACID in a distributed database.
What's problematic is when you have a transaction that span amongst several nodes and you need to reconcile several transactions (commit phase).
The usual way to do it is to refuse the transaction if a conflict is detected, however this is a real performance and useability issue for a NoSQL database.
What I'm implying is that if you have ACID transactions but they can fail very easily, you don't offer much...
It's not that hard to retry a transaction until some deadline is reached. Many programming languages have standard library facilities to make this extremely easy.
If the database is fast enough and transaction failure is at least moderately unlikely, it's not really an issue.
SSTable style databases are very cheap to snapshot, so you could totally handle this MVCC style. I buy the logic could get nutty in some pathological cases, but performance wise it shouldn't be much of a problem.