7 ms·
"In our opinion, the NoSQL decision to give up on ACID is the lazy solution to these scalability and replication issues." They had me up until they called NoSQ
by richardmarr 16y ago
"In our opinion, the NoSQL decision to give up on ACID is the lazy solution to these scalability and replication issues."
They had me up until they called NoSQL "lazy" and claimed NoSQL solutions "give up on ACID". They aren't lazy and a lot of them support ACID, or most of it.
From that point on this veers away from logic and moves towards a self-justified argument. Tools are just tools. If you need immediate consistency then go for an immediately consistent solution, if you don't then you should feel free to take advantage of the performance gain of eventual consistency.
- lemming 16y agoThe thing is that implementing ACID is, well, atomic - you either support it or you don't. Anything else is one of a series of different types of compromise. All currently available NoSQL systems I'm aware of compromise it very heavily, resulting in greatly increased programmer complexity for the types of applications that really require something that looks like ACID. I'd be interested to know which ones you think support ACID - as far as I'm aware none of them claim to support anything like it (with the possible exception of VoltDB, which has its own set of problems).
- jbellis 16y agoScalaris has supported ACID transactions for years, but it never caught on because at scale you care more about availability than about having transactions: http://twitter.com/Werner/status/1008722501 http://twitter.com/Werner/status/1008722501
- jhugg 16y agoIf you're counting important things (money, inventory, etc), being up with the wrong answer can be worse than not being up.