Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Relational databases aren’t dinosaurs, they’re sharks

simplethread.com

Post reply on HN
Print view View original

21–30 of 135 posts

Re: Relational databases aren’t dinosaurs, they’re sharks

#21

Post by mrweasel »

cageface wrote: post #17
laurent92 wrote: post #7

For some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “databases are slow”. Particularly when using a getter on a lazy-loaded relationship. A query might end up taking 1ms per record instead of 10ms for 10k records. You can rewrite all you want in Hibernate and greatly improve performance, but you often need to introduc…

Building SQL queries by gluing strings together is tedious and error prone. So you write a lot of helper functions to build queries for you and pretty soon you've invented your own crappy ORM. Why not save a lot of time and bugs and use a battle tested ORM and drill down to SQL for the queries that really matter instead?

Or you rewrite you queries so that you can use prepared statements. You’re right that we should avoid gluing strings together, but in most cases we can use prepared statements.

There’s also a middleground where developers learn to use the ORM better. I’ve seem people get terrible performance using the Django ORM, but after a rewrite, redesigning the queries and using the more advanced features performance would improve massively. The problem is that need to be able to write the SQL and then mentally backport to the ORMs syntax.

We’ve had customers complain about poor database performance. When we find the horrible queries generated by their ORM it’s frequently easier for the developer to just request more hardware or ask if we can: “performance tune” the database.

Re: Relational databases aren’t dinosaurs, they’re sharks

#22

Post by ransom1538 »

cpursley wrote: post #20
thatwasunusual wrote: post #8

Great article, and I this particularly brought back memories for me: > [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database. I've worked with a big application that utilised this appro…

This is exactly what I do - store location components as jsonb in Postgres

IMHO Blobs usually turn into a mess though. Some VP will ask "what weekday do users comment the most". With blobs this is drama. You end up parsing all these blobs and creating relational tables anyway. Sure you could do metrics separately -- but good luck predicting what stats you will want in the future. Need an admin portal? With blobs you are coding all these custom admin pages.

With mysql, I love when new people join and they can see and play with actual tables - slap in a good sql viewer and BAM you now have an admin portal. VP wants stats? give them mysql access and slack any sql they want: done .

Re: Relational databases aren’t dinosaurs, they’re sharks

#23

Post by watt »

laurent92 wrote: post #7

For some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “databases are slow”. Particularly when using a getter on a lazy-loaded relationship. A query might end up taking 1ms per record instead of 10ms for 10k records. You can rewrite all you want in Hibernate and greatly improve performance, but you often need to introduc…

I've worked on a real-life product built using MyBatis, which you'd think is supposed to be best of both worlds - non connected DTOs, seamlessly filled out from SQL statements you write in the mapping configuration, etc etc.

In practice the developers go overboard with SQL - the native-first SQL actually makes for quite confusing data model. There is value in clarity that limitations of Hibernate model brings or promotes.

With MyBatis approach the underlying DB can contain incredibly bizarre joins, crazy FKs, you find aggregation functions in queries trip you up, massive views used under the hood, triggers make appearance to confuse you, the list just goes on.

(The reason this happens is as years tick by, extra requirements get fitted into SQL model by doing these "clever hacks" and avoiding re-architecting. The kludges pile up, it's done because it's possible to do so, and every little decision seems like fair tradeoff when made in isolation. End result = massive pile of confusion.)

You think staying close to SQL is the salvation, but really it's just another way to hang yourself. I will not argue it's possible to do excellent work, but in no way it's guaranteed.

Re: Relational databases aren’t dinosaurs, they’re sharks

#24

Post by jeremyjh »

ransom1538 wrote: post #22
cpursley wrote: post #20

Earlier quoted context omitted.

This is exactly what I do - store location components as jsonb in Postgres

IMHO Blobs usually turn into a mess though. Some VP will ask "what weekday do users comment the most". With blobs this is drama. You end up parsing all these blobs and creating relational tables anyway. Sure you could do metrics separately -- but good luck predicting what stats you will want in the future. Need an admin portal? With blobs you are coding all these custom admin pages. With mysql, I love when new people…

I haven't used mysql this way but we do lots of reporting on jsonb data using the provided json functions of postgres. It is very easy to extract a (nested) key, or extract a set of key/values to a table value that you join to just as if it were a separate table.

Re: Relational databases aren’t dinosaurs, they’re sharks

#25

Post by jeremyjh »

mastrsushi wrote: post #16

> Relational DBs are Sharks > OOP is the Roman numerals of paradigms > C is a PDP assembler that thinks it’s a compiler Yup, everything popular is evil and bad. Run away to your ivory towers.

You might have missed the fact that sharks are awesome.

Re: Relational databases aren’t dinosaurs, they’re sharks

#26

Post by aenis »

Another consideration is that, at scale, no sql is way cheaper. I run a service with approx. 900k daily users, each generating about 210 object writes and reads that need to execute within 50ms, and I am running this on firestore for about $350 a month, incl. Elb, waf, regionally replicated compute, managed NLP and translate. I sync the no sql stuff to bigquery for analytical usage. Cheap, and scales without any problems as long as one observes the recommended patterns. And all of that scaled from a 5 user POC without a single adjustment in the infra setup or architecture.

Not doing relational again.

Re: Relational databases aren’t dinosaurs, they’re sharks

#27

Post by eska »

watt wrote: post #23
laurent92 wrote: post #7

For some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “databases are slow”. Particularly when using a getter on a lazy-loaded relationship. A query might end up taking 1ms per record instead of 10ms for 10k records. You can rewrite all you want in Hibernate and greatly improve performance, but you often need to introduc…

I've worked on a real-life product built using MyBatis, which you'd think is supposed to be best of both worlds - non connected DTOs, seamlessly filled out from SQL statements you write in the mapping configuration, etc etc. In practice the developers go overboard with SQL - the native-first SQL actually makes for quite confusing data model. There is value in clarity that limitations of Hibernate model brings or prom…

Not to be rude but your comment can be summarized as „one can mess up with SQL as well“, which is kind of „duh“. Absolutely every technology can be criticized this way. The more important point is that the layers on top of SQL always lead to horrible performance as soon as something non-trivial is done. And the trivial parts would’ve been trivial in SQL as well. People just really hate learning SQL to the extent that they implement their own, worse query language instead of wielding SQL with skill.

Re: Relational databases aren’t dinosaurs, they’re sharks

#28

Post by kroolik »

ransom1538 wrote: post #22
cpursley wrote: post #20

Earlier quoted context omitted.

This is exactly what I do - store location components as jsonb in Postgres

IMHO Blobs usually turn into a mess though. Some VP will ask "what weekday do users comment the most". With blobs this is drama. You end up parsing all these blobs and creating relational tables anyway. Sure you could do metrics separately -- but good luck predicting what stats you will want in the future. Need an admin portal? With blobs you are coding all these custom admin pages. With mysql, I love when new people…

> Some VP will ask "what weekday do users comment the most".

This is why people invented read models. Because the data model that works for the app and makes it easy to work with there might not necessarily work for analytics.

Generate analytics data from you app model so that both world can move independently.

> Need an admin portal? With blobs you are coding all these custom admin pages.

Admin portal with direct access to database columns? No thanks! IMHO, admin portal should hook into you business logic so that all the constraints are validated. Unless your app is just a CRUD.

Re: Relational databases aren’t dinosaurs, they’re sharks

#29

Post by mastrsushi »

jeremyjh wrote: post #25
mastrsushi wrote: post #16

> Relational DBs are Sharks > OOP is the Roman numerals of paradigms > C is a PDP assembler that thinks it’s a compiler Yup, everything popular is evil and bad. Run away to your ivory towers.

You might have missed the fact that sharks are awesome.

Oh

My

God

Re: Relational databases aren’t dinosaurs, they’re sharks

#30

Post by glimmung »

erk__ wrote: post #18
chrisandchris wrote: post #14

Earlier quoted context omitted.

> The term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. […] Except that it does not. It does mean „Not Only SQL“, and not „no SQL“.

I think that is a more recent backronym and was not the original, so it is wrong to say that what the above post said is incorrect.

'backronym' - like it, thank you.
Post reply on HN