4 ms·

No ACID db is most useful in free web apps. Where users data is practically worthless. So who cares about occasionally lost data record. When people are paying

by dgregd 16y ago

No ACID db is most useful in free web apps. Where users data is practically worthless. So who cares about occasionally lost data record. When people are paying for a service then ACID db is a must.

rewind 16y ago
But it's not always the data by itself that has value. Sure, it might be useless on its own, but if your app loses it and it causes the experience of using the app to be bad, then it doesn't matter how useless you think the data is; it's going to hurt the user's perception of your product. Also, "free web apps" doesn't translate to "worthless user data", although that's a different argument altogether.
chrisaycock 16y ago
Twitter is pretty lucky they were able to survive all of the negative press when they kept going down a couple years back.
nickik 16y ago
With alots of the big KeyValue store like cassandra you can make your data very save. You just have to traid of other stuff.
rbranson 16y ago
Electronic banking systems are far from ACID (think ATM operations, check and credit card transfer processes). Stock exchanges aren't ACID. Amazon.com isn't ACID. Logistics systems (FedEx, UPS, etc) aren't ACID. In fact, if you look at the information systems of Fortune 100 corporations, you'll find that almost every single one of them is non-ACID at the core.
- 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

by dgregd 16y ago

No ACID db is most useful in free web apps. Where users data is practically worthless. So who cares about occasionally lost data record. When people are paying for a service then ACID db is a must.

rewind 16y ago

But it's not always the data by itself that has value. Sure, it might be useless on its own, but if your app loses it and it causes the experience of using the app to be bad, then it doesn't matter how useless you think the data is; it's going to hurt the user's perception of your product. Also, "free web apps" doesn't translate to "worthless user data", although that's a different argument altogether.

chrisaycock 16y ago

Twitter is pretty lucky they were able to survive all of the negative press when they kept going down a couple years back.

nickik 16y ago

With alots of the big KeyValue store like cassandra you can make your data very save. You just have to traid of other stuff.

rbranson 16y ago

Electronic banking systems are far from ACID (think ATM operations, check and credit card transfer processes). Stock exchanges aren't ACID. Amazon.com isn't ACID. Logistics systems (FedEx, UPS, etc) aren't ACID. In fact, if you look at the information systems of Fortune 100 corporations, you'll find that almost every single one of them is non-ACID at the core.

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