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

NoSQL: The Baby and the Bathwater

brooker.co.za

Post reply on HN
Print view View original

21–30 of 59 posts

Re: NoSQL: The Baby and the Bathwater

#21

Post by strbean »

wvenable wrote: post #8
roenxi wrote: post #5

I don't like NoSQL databases. "NoSQL" should be manna from heaven. It may be impossible to create a less pleasant language than SQL. It isn't composable, it isn't internally consistent, it isn't easy to parse, it claims to be declarative but the ordering of the clauses is completely rigid, it fights every attempt at writing testable or maintainable code. It is hard to read. It is hard to programatically generate. Eve…

NoSQL really means NoRDMS. The SQL language, or lack there of, has little to do with it. The unfortunate naming leads to this kind of confusion. Probably a technology should never be named for what it is not.

It originally was the name for a non-SQL RDBMS: https://en.wikipedia.org/wiki/Strozzi_NoSQL

It malappropriated in 2009.

Re: NoSQL: The Baby and the Bathwater

#22

Post by collaborative »

winrid wrote: post #12
collaborative wrote: post #4

Sure SQL DBs can have all the advantages of NoSQL DBs and then some... but they will never have a lower price tag. And that's because NoSQL DBs use very, very little CPU. All that's needed is giving up reliance on SQL. Design your NoSQL "schema" with this in mind, and you're golden

Very little CPU depending on sorting, indexes, etc... Have a lot of indexes on a collection? Mongo will eat 5-10ms of CPU time per query even with cached query plan stats just to start executing the query. So no different than PG here. What you're getting at is Joins, but I haven't seen a company that didn't end up doing joins with Mongo at some point. Or, they do it in the app layer, in Java/Node/PHP which requires…

But you are describing incorrect ways of using NoSQL. NoSQL requires getting the schema right from the get go. Many people don't like it because they are used to relying on SQL (or a language like you mentioned) to smooth things out. NoSQL requires you to ask yourself hard questions - what specific queries are going to consume this data and then model the data as opposed to in SQL where you just store the data and worry about querying it later. This produces efficient queries that ultimately don't need as much CPU

Re: NoSQL: The Baby and the Bathwater

#23

Post by zztop44 »

roenxi wrote: post #15
emodendroket wrote: post #6

Earlier quoted context omitted.

I think the right way to think about NoSQL databases is you have an application where traffic is expected to be heavy enough that it's worth throwing out what SQL gives you for free and having a highly optimized solution where you deal with those problems yourself. Of course, it was a big enough trend that many people jumped on it without having a practical use for it. Arguably psql does offer a NoSQL-like experience…

> Arguably psql does offer a NoSQL-like experience with JSON columns. I hope not. JSON columns purge all the good things a relational database offers and keeps the SQL . It is the worst of every option. That really should be the opposite of the NoSQL experience. Disbarred by the fact that SQL is involved.

JSON columns are very useful in some circumstances but you shouldn’t use them as a replacement for a database schema, and if I’m honest I’m yet to see anyone truly suggest that.

Re: NoSQL: The Baby and the Bathwater

#24

Post by masklinn »

roenxi wrote: post #5

I don't like NoSQL databases. "NoSQL" should be manna from heaven. It may be impossible to create a less pleasant language than SQL. It isn't composable, it isn't internally consistent, it isn't easy to parse, it claims to be declarative but the ordering of the clauses is completely rigid, it fights every attempt at writing testable or maintainable code. It is hard to read. It is hard to programatically generate. Eve…

> It may be impossible to create a less pleasant language than SQL.

It’s not by the way, there’s an entire segment of the esolang space for which it’s the goal (starting with the canonical example that is INTERCAL).

But ignoring esolangs, there are lots of very unpleasant programming languages out there. M/MUMPS is a well known one (especially with “legacy” coding styles, or so I gather). I also consider XSLT to be abhorrent, especially given the nice underlying conceptual idea (not entirely dissimilar to SQL really, just worse).

About SQL, an idea I saw surface recently in a related discussion was how nice it’d be if databases could expose the data model interaction and allow building on that directly: most every SQL database compiles the query into some sort of bytecode (combining direct translation and planner information) to actually run it on its storage layer, some databases allow peeking at the bytecode (sqlite actually prints the bytecode as part of its EXPLAIN output) but I don’t know that any allows bytecode input.

TBF the bytecode is very much considered an internal detail, it can change a lot between versions and (most importantly) tends to be more or less completely unchecked, it relies on the compiler generating it being correct (not unlike cpython for instance).

Re: NoSQL: The Baby and the Bathwater

#25

Post by moehm »

kaoD wrote: post #16
threeseed wrote: post #9

Earlier quoted context omitted.

> Bless them, but PostgreNoSQL would be so much better for all the use cases I have than MongoBD And for some of us MongoDB is a better option than PostgreSQL. Many of us simply can't rely on scalability and high availability being something that isn't part of the core product.

In what way is scalability and high availability not part of Postgres' core?

Master-master replication probably, think Galera.

Re: NoSQL: The Baby and the Bathwater

#26

Post by bullen »

Explicit schema is the most important feature to drop.

You cannot have a live service that is interrupted by database modifications.

My solution is to use JSON.

But the most important feature to add is HTTP as transport and async-to-async (both client and server needs to only use a thread when they are doing work, zero idling): To scale a distributed database across continents:

2000 line distributed DB: http://root.rupy.se

Re: NoSQL: The Baby and the Bathwater

#27

Post by trashtester »

bullen wrote: post #26

Explicit schema is the most important feature to drop. You cannot have a live service that is interrupted by database modifications. My solution is to use JSON. But the most important feature to add is HTTP as transport and async-to-async (both client and server needs to only use a thread when they are doing work, zero idling): To scale a distributed database across continents: 2000 line distributed DB: http://root.r…

It may be the most important feature to drop, for some.

It's certainly the most important feature to KEEP for others.

Schemas allow you to keep the more critical business relationships consistent. For variable data elements, you can always use JSON columns for that.

Re: NoSQL: The Baby and the Bathwater

#28

Post by tgv »

benrutter wrote: post #18

I'm surprised to see so many opinions on what is "objectively" the best database paradigm. My incredibly boring take: databases are such a generic tool that it really depends on your use case, there are times when noSQL is stand out the best choice, and lots more when it isn't- the real pain point comes from people blindly cargo culting into a db paradigm without considering their use case.

Yup. I've got a (legacy) postgresql database with time series: one timestamp plus measurement per row. And there's a useless third column too. It's awful, and sluggish.

For a newer project, where we basically use one object, I've chosen a NoSQL database. Get the object, edit it in the browser, put it back. Done. No need to update relations, ORMs or any of that. But: that won't fly for more complex projects.

So I agree: pick the right tool for the job.

Re: NoSQL: The Baby and the Bathwater

#29

Post by regularfry »

bullen wrote: post #26

Explicit schema is the most important feature to drop. You cannot have a live service that is interrupted by database modifications. My solution is to use JSON. But the most important feature to add is HTTP as transport and async-to-async (both client and server needs to only use a thread when they are doing work, zero idling): To scale a distributed database across continents: 2000 line distributed DB: http://root.r…

> You cannot have a live service that is interrupted by database modifications.

So don't do that, then. Designing database migrations to be non-breaking is part of the game and if you're not doing it, you can't claim to understand the technology you're replacing. Not having an explicit schema doesn't mean you don't have to think about your schema. It just means you've chucked out all the tooling for keeping it sane.

Re: NoSQL: The Baby and the Bathwater

#30

Post by revscat »

reidjs wrote: post #10
threeseed wrote: post #3

You would think after all these years people would stop using the term NoSQL. They are just databases. Many of the so-called NoSQL ones like MongoDB or Cassandra can support schemas, transactions, strong consistency, joins, secondary indexes etc. And SQL databases like PostgreSQL support schema-less data structures. And with Presto, Spark SQL etc you can use SQL with almost any data store.

Just because they support those things does it mean it’s straight forward to use them Our team had a lot of trouble trying to map highly relational data to a noSQL database (mongo) It could have been a failing of our team, but I also think it just made our lives way harder. We’re on Postgres now and a lot of issues have faded away.

Same experience here.

We had a small-ish application that was originally built in top of MongoDB. Once it made it into production and started to see some success, it became quickly apparent that the schemaless design caused problems that an RDBMS would have solved.

It was decided fairly quickly to remove the MongoDB underpinnings and migrate everything to Postgres. It was the right call, and the final nail in any remaining affection — and interest — I had for NoSQL stores.

Post reply on HN