4 ms·

This is not really very accurate. At their core, each of these systems use ACID databases (or very nearly if you nitpick about isolation levels in Oracle). Bet

by jhugg 16y ago

This is not really very accurate. At their core, each of these systems use ACID databases (or very nearly if you nitpick about isolation levels in Oracle). Between databases and between companies, they've developed "eventually correct" schemes to synchronize information. The lease patterns that many of these systems rely on require atomic operations at their core and offer stronger guarantees than the basic eventually consistent systems popularized by models like Amazon's Dynamo. It's not just that the account values have to agree between systems at the end of the day; they have to actually be correct at the end of the day. I know that consistency models vary between NoSQL systems (and even within a single NoSQL system). There's some great technology out there and plenty of problems to solve. There's are certainly plenty of use cases for NoSQL systems within banks and stock exchanges. But the "banks are eventually consistent" line of reasoning needs to die.

spenrose 16y ago
I take your points. Here's the thing: if ACID is an aspect of developer tools and not a user experiences, and if ACID tools are the default, and if (as anyone who has held a checking account in the U.S. would surely agree) user-experience failures analogous to ACID violations occur regularly, isn't that evidence that we should continue to question what value we actually get from basing our systems on ACID/relational data stores?
- jhugg 16y ago
  Asking what value a particular app gets from an ACID store vs a non-ACID store as part of a comprehensive analysis of two competing technologies is a GOOD THING. As for banks, exchanges, credit cards, packages, etc: When non-trivial sums of money are changing hands, ACID stores offer tremendous benefits as a building block in a larger system. Yes, things go wrong. Even given ACID building blocks, building huge banking systems is hard. Forcing bank developers to worry about consistency not just between systems, but also within systems isn't going to make that job easier.
rbranson 16y ago
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.

by jhugg 16y ago

spenrose 16y ago

I take your points. Here's the thing: if ACID is an aspect of developer tools and not a user experiences, and if ACID tools are the default, and if (as anyone who has held a checking account in the U.S. would surely agree) user-experience failures analogous to ACID violations occur regularly, isn't that evidence that we should continue to question what value we actually get from basing our systems on ACID/relational data stores?

jhugg 16y ago
Asking what value a particular app gets from an ACID store vs a non-ACID store as part of a comprehensive analysis of two competing technologies is a GOOD THING. As for banks, exchanges, credit cards, packages, etc: When non-trivial sums of money are changing hands, ACID stores offer tremendous benefits as a building block in a larger system. Yes, things go wrong. Even given ACID building blocks, building huge banking systems is hard. Forcing bank developers to worry about consistency not just between systems, but also within systems isn't going to make that job easier.

rbranson 16y ago

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.