The database ruins all good ideas • Hacker News Board

Re: The database ruins all good ideas

#161

Post by CRConrad » Wed, Jul 21, 2021, 4:30 AM UTC

lmm wrote: post #147

kayodelycaon wrote: post #125

Earlier quoted context omitted.

If you allow invalid records and multiple versions of a schema in a collection, you will forever being paying for that mistake every time you read from the database.

If you're fine with just dropping that invalid data, you can always just delete it at any point in the future. (Yes, that should horrify you - but so should the idea of just erroring and dropping it when someone first tried to write it, which is what an RDBMS would do). The overall effect is the same either way. Fixing up data that was written wrongly takes work, there's no getting away from that. But if you have a r…

> Yes, that should horrify you - but so should the idea of just erroring and dropping it when someone first tried to write it, which is what an RDBMS would do

Have you ever actually encountered any RDBMS that just silently "drops" your write without informing you, or is this just how you think they work?

Otherwise, isn't this just like any other data write erroring out -- MongoDB driver saying "Service down!", simple flat-file write saying "Disk full!", etc -- in that if your app doesn't react to this, it's not the data store but your code that sucks?

Re: The database ruins all good ideas

#162

Post by CRConrad » Wed, Jul 21, 2021, 4:31 AM UTC

lmm wrote: post #146

justinclift wrote: post #135

Earlier quoted context omitted.

> Well if you can't get input that violates that integrity then what are you gaining by enforcing that integrity? Perhaps I'm wording this badly? Your application should _not_ be generating data which can't go into the database correctly. If it is, that's a different set of problems. ;)

What are you claiming the purpose of integrity constraints in the database is? If your application doesn't generate data which can't go in the database correctly, what's the observable difference between a database that enforces constraints and a database that doesn't?

The difference is that one of them informs you when you've failed at generating valid data to save, and the other doesn't.

Re: The database ruins all good ideas

#163

Post by CRConrad » Wed, Jul 21, 2021, 4:41 AM UTC

benlivengood wrote: post #30

And this is why Google wrote Spanner. I think cockroachdb tries to solve the same problems. If you need ACID compliance and you need a lot of it, everywhere, all the time, now there are better options than giant Sun/IBM boxes. Databases are not the problem.

> If you need ACID compliance and you need a lot of it, everywhere, all the time, now there are better options than giant Sun/IBM boxes.

Oh I dunno, I'd still say most claims to be "better" at data integrity with performance, and a lot of it than a good old zOS mainframe with a soundly designed DB2 database on it are [Citation needed]-class...

But yeah, databases certainly aren't the problem here.

Re: The database ruins all good ideas

#164

Post by slumdev » Thu, Jul 22, 2021, 5:54 PM UTC

rad_gruchalski wrote: post #65

slumdev wrote: post #54

Earlier quoted context omitted.

I get the same impression. Relational with ACID guarantees can't be implemented in a distributed system. Depending on which guarantees you want to give up, you might be able to get close. A lot of newer platforms give up guarantees to achieve something like this. But if you have multiple nodes that have to sync every transaction over a dedicated NIC, well, that's not a distributed system. It's just multiprocessing wi…

> Relational with ACID guarantees can't be implemented in a distributed system. CockroachDB and YugabyteDB would like to have a word.

It's a causality problem, not a technology problem.

Information can't be changed in two places simultaneously. That latency, no matter how small, requires us to either eat the latency, give up guarantees, or alter our system's behavior in some other small way.

Re: The database ruins all good ideas

#165

Post by rad_gruchalski » Sun, Aug 01, 2021, 10:57 PM UTC

slumdev wrote: post #164

rad_gruchalski wrote: post #65

Earlier quoted context omitted.

> Relational with ACID guarantees can't be implemented in a distributed system. CockroachDB and YugabyteDB would like to have a word.

It's a causality problem, not a technology problem. Information can't be changed in two places simultaneously. That latency, no matter how small, requires us to either eat the latency, give up guarantees, or alter our system's behavior in some other small way.

Of course. But thanks to raft per table, the queries are coordinated in such a way that to the observer it looks like acid.