3 ms·

Quorum writes to Dynamo nodes allow you make atomic and durable updates to single keys and the data associated with them. ACID transactions allow you to mutate

by jhugg 16y ago

Quorum writes to Dynamo nodes allow you make atomic and durable updates to single keys and the data associated with them. ACID transactions allow you to mutate data associated with multiple keys atomically. This is not the same thing at all. Common operations like debit from one account and credit another or sum a set of values become difficult. Now atomic updates to single keys can actually be used as the building blocks for transactional functionality (using the lease pattern and/or compensating operations). If you need a transaction here or there, this might be a very workable solution. If you need lots of transactions, then you end up using Dynamo systems in unnatural ways; many of their performance and availability advantages are wasted in this configuration. So yes, you could build a bank given quorum writes, but the point is that it would probably be a poor engineering choice.

rbranson 16y ago
I wasn't saying banks should use Dynamo, but that Dynamo-style consistency is appropriate for conducting e-commerce transactions, and originally that most scaled industries don't depend on ACID semantics in their core datastores. Bank accounts are eventually consistent logs, which doesn't look like Dynamo, but also look nothing like an RDBMS table. It's well known and understood that almost all banking systems are based around mainframe-era batch-process systems that are eventually consistent in nature. It's awfully ironic that the "hello world" used to demonstrate transactions in the RDBMS world is a debit and credit of bank accounts, a situation that is vanishingly rare in the real world. Also, please address my original rebuttal to your claim that Amazon uses an ACID database for their checkout process.
jhugg 16y ago
Again, replying to a deeper comment. I sure don't disagree with everything you are saying. As for adding transactions to get a balance, yes, this is how the basics work and it doesn't look like ACID at all. However, what you're describing isn't eventual-consistency (per Dynamo), it's eventual-completeness. You can't lose a log entry. All of these messages are two-phase committed between systems. So as I said before, you could build this kind of system using quorum writes on a Dynamo system, but it wouldn't be a solid engineering choice. Also, yes, BerkelyDB has multi-key transactions. Dynamo on top of BDB does not expose this functionality or use it (as described in the paper). Publicly available systems that implement Dynamo like Cassandra, Riak or SimpleDB do not have native transactions either. Fun chatting. I'm off to bed.

by jhugg 16y ago

rbranson 16y ago

I wasn't saying banks should use Dynamo, but that Dynamo-style consistency is appropriate for conducting e-commerce transactions, and originally that most scaled industries don't depend on ACID semantics in their core datastores. Bank accounts are eventually consistent logs, which doesn't look like Dynamo, but also look nothing like an RDBMS table. It's well known and understood that almost all banking systems are based around mainframe-era batch-process systems that are eventually consistent in nature. It's awfully ironic that the "hello world" used to demonstrate transactions in the RDBMS world is a debit and credit of bank accounts, a situation that is vanishingly rare in the real world. Also, please address my original rebuttal to your claim that Amazon uses an ACID database for their checkout process.

jhugg 16y ago

Again, replying to a deeper comment. I sure don't disagree with everything you are saying. As for adding transactions to get a balance, yes, this is how the basics work and it doesn't look like ACID at all. However, what you're describing isn't eventual-consistency (per Dynamo), it's eventual-completeness. You can't lose a log entry. All of these messages are two-phase committed between systems. So as I said before, you could build this kind of system using quorum writes on a Dynamo system, but it wouldn't be a solid engineering choice. Also, yes, BerkelyDB has multi-key transactions. Dynamo on top of BDB does not expose this functionality or use it (as described in the paper). Publicly available systems that implement Dynamo like Cassandra, Riak or SimpleDB do not have native transactions either. Fun chatting. I'm off to bed.