4 ms·

EDIT: For full disclosure purposes, the parent post is from John Hugg, a software engineer at VoltDB, which is a high-scale data store that competes with many "

EDIT: For full disclosure purposes, the parent post is from John Hugg, a software engineer at VoltDB, which is a high-scale data store that competes with many "NoSQL" databases. I am not claiming his point of view is invalid, just that it comes from a certain perspective, and should be viewed in this light. Amazon's Dynamo itself is built on BerkeleyDB, which is ACID compliant. That doesn't mean Dynamo is an ACID system. You have to view the system as a whole, not just the component parts. The information systems I refer to in large banks, stock exchanges, and logistics are often composed of thousands of instances of ACID-compliant databases, but as a whole operate with eventual consistency guarantees. EC is kind of a misnomer for Dynamo anyways, because it's really TUNABLE consistency. Dynamo can operate in a fully consistent mode, but you're going to sacrifice availability. CAP theorem doesn't care if you're a bank or a stock exchange or you have a trillion dollars. It still applies.

jhugg 16y ago
I was referring to the Dynamo model for EC, not a particular software implementation. That model has next-to-zero traction in systems that handle non-trivial sums of money, and for good reason. That's not to say it's not great for lots of things. Amazon uses this model for all kinds of stuff, but as soon as you go to checkout your order, you get kicked back into ACID-ville.
- rbranson 16y ago
  Dynamo's consistency ranges from fully consistent to loosely consistent and is tunable on a per-application and per-call basis. This means a write can be reconciled against 100% of the replicas before it is considered finished. How is this any different than the consistency guarantees an ACID compliant system provides? You make a claim that Amazon uses ACID semantics for the checkout process. The Dynamo paper claims that in order to meet business goals, the complete Amazon.com order process must be highly-available and partition tolerant. A system that is ACID compliant must sacrifice availability or partition tolerance, but this isn't the case for Amazon's purchase process. Amazon simply strengthens consistency and durability guarantees in the case of checkouts with a quorum write. It would be exceedingly rare for a partition or disaster to knock out communication with more than one datacenter, so this works very well in practice.
  - 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.
jhugg 16y ago
As for the VoltDB comment, how much we compete with NoSQL or whether we are NoSQL is an interesting line of questions. We're trying to bleed customers away from entrenched systems the same as most NoSQL systems. I think there's plenty to go around.

jhugg 16y ago

I was referring to the Dynamo model for EC, not a particular software implementation. That model has next-to-zero traction in systems that handle non-trivial sums of money, and for good reason. That's not to say it's not great for lots of things. Amazon uses this model for all kinds of stuff, but as soon as you go to checkout your order, you get kicked back into ACID-ville.

rbranson 16y ago
Dynamo's consistency ranges from fully consistent to loosely consistent and is tunable on a per-application and per-call basis. This means a write can be reconciled against 100% of the replicas before it is considered finished. How is this any different than the consistency guarantees an ACID compliant system provides? You make a claim that Amazon uses ACID semantics for the checkout process. The Dynamo paper claims that in order to meet business goals, the complete Amazon.com order process must be highly-available and partition tolerant. A system that is ACID compliant must sacrifice availability or partition tolerance, but this isn't the case for Amazon's purchase process. Amazon simply strengthens consistency and durability guarantees in the case of checkouts with a quorum write. It would be exceedingly rare for a partition or disaster to knock out communication with more than one datacenter, so this works very well in practice.
- 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.

jhugg 16y ago

As for the VoltDB comment, how much we compete with NoSQL or whether we are NoSQL is an interesting line of questions. We're trying to bleed customers away from entrenched systems the same as most NoSQL systems. I think there's plenty to go around.