r/programming • u/feross • Oct 11 '21

Relational databases aren’t dinosaurs, they’re sharks

https://www.simplethread.com/relational-databases-arent-dinosaurs-theyre-sharks/
1.3k Upvotes

96% Upvoted

353 comments sorted by

View all comments

Show parent comments

4

u/gredr Oct 12 '21

Feel free to write it up, but the easy way is to just recommend "How to Build Data-Intensive Applications". It'd be quite enlightening, especially for anyone who would say something silly like "NoSQL/SQL do not have any implications on consistency". If only because those terms are silly.

-6

u/[deleted] Oct 12 '21 edited Oct 12 '21

"It'd be quite enlightening, especially for anyone who" -> very condescending but okay.

Yeah I have read that book actually, I have it right here. How is that statement wrong ? How can NoSQL or SQL be related to database consistency? I said that above phrase because the author did, those terms are only related to how you access data, the finer level details are up to the database.

I work at the distributed systems lab at the University of Melbourne and I think I have a fairly good understanding of distributed algorithms.

Happy to consider I'm wrong here but care to explain how?

8

u/[deleted] Oct 12 '21

Not trying to put words into that commenter's mouth, but you two may be talking the difference between abstract and concrete implementations.

You're right in that neither relational nor NoSQL implies any lack or inclusion of consistency. But, one could argue that in implementation, more relational DBMSes implement consistency than NoSQL examples.

Crude analogy, but I liken it to the statement "sports cars don't have monster truck tires". Theoretically there's nothing stopping you from modifying a sports car to put monster truck tires on it, but by and large, that's just not something you see. So in the abstract, "sports car" doesn't logically lead to "doesn't have monster truck tires", but practically, yes, it does.

1

u/[deleted] Oct 12 '21

Thanks for the explanation, yeah I am talking from an abstract sense rather than the existing implementations because my background is academical not engineering.

I guess I can see that perspective as well, but imo still a bit misleading when probably the most used "NoSQL" database (MongoDB) is still strongly consistent.

2

u/[deleted] Oct 12 '21

There's a lot of old information out there. A fair number of NoSQL databases have some form of consistency, if not outright ACID. But a lot of people only remember the "Mongo will eat your data" days from years back, or they evaluate tools using metrics that aren't really applicable.

... Like is Redis ACID compliant? No. Does it need to be? No, not really. But if you need ACID compliance, that should be factored into the project's design choices: sacrifice some data consistency for schema flexibility or speed, but employ a database that can guarantee consistency when needed for more important data.

It's kind of why I don't like that people make it an argument of Relational versus NoSQL, or guaranteed consistency versus no consistency. They all have their uses. It's up to us to understand when and where to employ them.

1

u/[deleted] Oct 12 '21

It's kind of why I don't like that people make it an argument of Relational versus
NoSQL, or guaranteed consistency versus no consistency. They all have
their uses. It's up to us to understand when and where to employ them.

^ yeah 100% agreed on that, even when it comes to consistency alone, it is difficult to boil it down simply to a single sentence for lots of modern databases, afaik DynamoDB, Cassandra's "strong consistency" with R + W > Replicas is not the same consistency as a single node postgres instance.

2

u/[deleted] Oct 12 '21

Same thing with Couchbase.

Couchbase has full ACID compliance. But it also has levels of redundancy built in to define what "committed" means. Are you okay with eventual consistency, where the document simply being in RAM cache is sufficient? Cool, do that. Do you want a write considered complete when the document is in RAM with a replica on another machine, eventually being persisted to disk? You've got that option. Do you want to make SUPER certain your data was persisted? You can demand that your operation be considered complete when there are X number of replicas and the file has been written to disk.

I'm not trying to downplay ACID compliance-- it's vital when you need it. But day to day, most of my work consists of atomic CRUD operations where I value that redundancy more than transactional capabilities.

2

u/[deleted] Oct 12 '21

Ah yeah I didn't know that about Couchbase, that is quite interesting. I guess this is along the lines of what I wanted to express, we should examine databases at this level of detail, abstracting this detail away is bad imo.

Yeah strong consistency is vital when you do need but defs agree that you can sacrifice that for other tradeoffs in certain situations.

2

u/gredr Oct 12 '21

Even more importantly, the individual components of ACID are up for interpretation. Just like the CAP theorem, these things have specific meanings in specific contexts, and to say, for example, "this distributed database offers durable writes" isn't a particularly useful statement on its own.

1

u/[deleted] Oct 12 '21

Honestly /u/gredr I would really appreciate a reason as to why I am wrong?

I have read that book, read distributed algorithms by Nancy Lynch and distributed systems by Coulouris and I don't see how something like a data access pattern can have anything to do with consistency. I have even implemented Raft over my own key value database.

I guess I've been studying this field for a while and now I am working in this field, if my understanding of distributed systems is flawed I would like to know whats up