For some stuff, no ACID is no problem. They have their place. What I’m more suspicious of is things like Google offering distributed databases that they pretend as if they could break the CAP theorem.
And yet my Uni treats it like the biggest thing in existence. Meanwhile I’ve never used anything other than RDBS and Redis (only for cache), neither in private nor at work.
MongoDB is huge though for all the wrong reasons, businesses think that just because it’s JS, they can just have frontend devs - sorry, they are “fullstack” now - doing DBA work.
I worked as one of two NoSQL DBAs for a Fortune 50 finance company, and there is a ton of CV-driven development going on giving NoSQL a bad name. Most use cases don’t need NoSQL. And for those which do, NoSQL is almost always harder to implement than simple SQL based RDBMSs.
If you need to run queries that aggregate big amounts of data in a reasonable time and cost, you’ll need something built for it. For example, with a column oriented file format instead of the row oriented file format found in traditional relational databases
And the key word “big” here is far bigger than most engineers need to deal with. Hell, most supposed “big data” problems I’ve seen people try to tackle are small enough to fit the whole database into memory.
My point is more that 90% of use cases don’t need that, and for those that do, you can’t just slap eg. Cassandra at it and pretend it’s a relational database.
Atomicity: either all parts of the transaction complete, or all parts of the transaction don’t complete; there’s no “partly complete” state
Consistency: the state of the database after a transaction is stable; all “downstream” effects (e.g. triggers) of the query are complete before the transaction is confirmed.
Isolation: concurrent transactions behave the same as sequential transactions
Durability: a power failure or crash won’t lose any transactions
Traditionally, ACID is where relational databases shine.
ACID is really just an arbitrary set of requirements for databases that made sense way back in the day when things were much simpler. ACID starts to hold you back when you want to scale out, because to have consistency you have to wait for your transaction to percolate through all the nodes of your system, and it doesn’t allow for things like a replicating node to be temporarily offline or lagging behind. Turns out though that not everything needs to be strictly ACID. For example, there are many cases where it doesn’t matter that a reader node has stale data for a second or two.
The thing MongoDB does is that instead of being dogmatically ACID all the time it allows you to decide exactly how ACID your transactions and your reads need to be, through the writeConcern and readConcern parameters. If you want it to be completely ACID, you can, but it comes at a cost.
Traditionally, ACID is where relational databases shine.
Relational databases shine with ACID on single-node systems when they’re not trying to solve the scale-out problem that MongoDB is trying to solve, but when they are trying to do that, they actually do much worse.
For example: most RDBMS systems have some kind of replication system, where you can replicate your transactions to one or more backup nodes either for failover or to use as a read-only node.
Now if you consider that whole system, replicas included, as “the database”, none of them are ACID, and I don’t know of any RDMBS-es that has mechanisms to automatically recover from a crashed primary without data loss, or that can handle the “split brain” problem.
You’ve gotten good answers from other folks but I’ll provide a ELI5:
Basically a set of rules in the database to make sure that it is immediately consistent.
NoSQL databases offer eventual consistency in exchange for speed so they are generally not considered to be ACID compliant.
Most traditional databases (MySQL, postgresql, etc.) are.
There are a couple of emerging companies that try to tackle speed for traditional databases. CockroachDB offers a postgress-based database that scales more like NoSQL while still offering ACID transactions.
Atomicity (something happens in its entirety or not at all), consistency (database is always in a valid state — if the database has constraints, they will always be honored), isolation (transactions don’t step on each other), durability (complete transaction is complete even if there’s a power failure).
Not a database expert, my parenthetical explanations may need work.
NoSQL has always been a niche use case thing.
For some stuff, no ACID is no problem. They have their place. What I’m more suspicious of is things like Google offering distributed databases that they pretend as if they could break the CAP theorem.
And yet my Uni treats it like the biggest thing in existence. Meanwhile I’ve never used anything other than RDBS and Redis (only for cache), neither in private nor at work.
MongoDB is huge though for all the wrong reasons, businesses think that just because it’s JS, they can just have frontend devs - sorry, they are “fullstack” now - doing DBA work.
I worked as one of two NoSQL DBAs for a Fortune 50 finance company, and there is a ton of CV-driven development going on giving NoSQL a bad name. Most use cases don’t need NoSQL. And for those which do, NoSQL is almost always harder to implement than simple SQL based RDBMSs.
Jumping in this, bingo. JavaScript only shops scare the fuck out of me.
Just wail til they become AI-generated-JavaScript-only shops. They’re gonna be vibing like the Tacoma Narrows Bridge.
why is my deploy process so slow? ©_©=> 500k npm packages
Sharded RDBS gets you very very far from my experience at least.
Definitely, and I’m saying that while my jobs were mostly on NoSQL and I love doing it.
If you need to run queries that aggregate big amounts of data in a reasonable time and cost, you’ll need something built for it. For example, with a column oriented file format instead of the row oriented file format found in traditional relational databases
And the key word “big” here is far bigger than most engineers need to deal with. Hell, most supposed “big data” problems I’ve seen people try to tackle are small enough to fit the whole database into memory.
My point is more that 90% of use cases don’t need that, and for those that do, you can’t just slap eg. Cassandra at it and pretend it’s a relational database.
It always depends on the context… My current job is 100% on Elasticsearch and I’m not missing transactions at all.
What’s ACID?
Atomicity: either all parts of the transaction complete, or all parts of the transaction don’t complete; there’s no “partly complete” state
Consistency: the state of the database after a transaction is stable; all “downstream” effects (e.g. triggers) of the query are complete before the transaction is confirmed.
Isolation: concurrent transactions behave the same as sequential transactions
Durability: a power failure or crash won’t lose any transactions
Traditionally, ACID is where relational databases shine.
ACID is really just an arbitrary set of requirements for databases that made sense way back in the day when things were much simpler. ACID starts to hold you back when you want to scale out, because to have consistency you have to wait for your transaction to percolate through all the nodes of your system, and it doesn’t allow for things like a replicating node to be temporarily offline or lagging behind. Turns out though that not everything needs to be strictly ACID. For example, there are many cases where it doesn’t matter that a reader node has stale data for a second or two.
The thing MongoDB does is that instead of being dogmatically ACID all the time it allows you to decide exactly how ACID your transactions and your reads need to be, through the
writeConcernandreadConcernparameters. If you want it to be completely ACID, you can, but it comes at a cost.Relational databases shine with ACID on single-node systems when they’re not trying to solve the scale-out problem that MongoDB is trying to solve, but when they are trying to do that, they actually do much worse.
For example: most RDBMS systems have some kind of replication system, where you can replicate your transactions to one or more backup nodes either for failover or to use as a read-only node.
Now if you consider that whole system, replicas included, as “the database”, none of them are ACID, and I don’t know of any RDMBS-es that has mechanisms to automatically recover from a crashed primary without data loss, or that can handle the “split brain” problem.
You’ve gotten good answers from other folks but I’ll provide a ELI5:
Basically a set of rules in the database to make sure that it is immediately consistent.
NoSQL databases offer eventual consistency in exchange for speed so they are generally not considered to be ACID compliant.
Most traditional databases (MySQL, postgresql, etc.) are.
There are a couple of emerging companies that try to tackle speed for traditional databases. CockroachDB offers a postgress-based database that scales more like NoSQL while still offering ACID transactions.
TiDB is a similar company but for MySQL.
Not all NoSQL databases are the same. Neo4j is acid compliant, and lightning fast for complex relationships that relational databases struggle with.
https://en.m.wikipedia.org/wiki/ACID
Atomicity (something happens in its entirety or not at all), consistency (database is always in a valid state — if the database has constraints, they will always be honored), isolation (transactions don’t step on each other), durability (complete transaction is complete even if there’s a power failure).
Not a database expert, my parenthetical explanations may need work.