this post was submitted on 11 Feb 2025
1233 points (98.7% liked)
Programmer Humor
20039 readers
1658 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
They probably do use lots of NoSQL DBs too, which perform better for non relational "data lake" style architectures where you just wanna dump mountains of data as fast as possible into storage, to be perused later.
When you have cases where you have very very high volume of data in, but very low need to query it (but some potential need, just very low), nosql DBs excel
Stuff like census data where you just gotta legally store it for historical reasons, and very rarely some person will wanna query it for a study or something.
Keep in mind when I talk about low need to query, the opposite high need us on the scale of like, "this db gets queried multiple times per minute'
Stuff like... logins to a website, data that gets queried many times per minute or even second, then sometimes nosql DBs fall off.
Depends what is queried.
Super basic "lookup by ID" Stuff that operates as just a big ole KeyValuePair mapping ID -> Value? And thats all you gotta query?
NoSql is still the right tool for the job.
The moment any kind of
JOIN
enters the discussion though, chances are you actually wanna use sql nowSo you're saying Relational DataBase Management Systems do really well as soon as Relations are involved?
And Structured Query Language is a handy language for querying structured data?
What’s funny is that Relational Databases in fact sucks when somewhat complex Relations are involved. Moment you step out the of the realm of Tabular data you’ll have very miserable time. Like good luck modeling and querying simple nested product catalog.
Graph databases are better choice for truly relational data
Eyup, it's intuitive overall but there's just weirdly some people out there that are all or nothing, and don't understand "right tool for the job" lol
To nitpick, Census data is heavily queried. They use Oracle now, I believe.
Just so you know census data is very heavily queried. Everything from civil engineering to economics wants to look at that dataset every day.
Like I said, in the scale compared to actual high frequency data though, that's still be infrequent.
High frequency DBs are on the scale of many queried per second
Even with tonnes of data scientists and engineers querying the data, that's still in the scale of queries per minute, which is low frequency in the data world.
I wouldn't put it past them to experience numbers in the per second realm, especially as new data posts and everyone is rushing to grab it.
I wouldn't even consider "per minute" frequently queried. Per millisecond for stock market shit