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

31–40 of 59 posts

Re: NoSQL: The Baby and the Bathwater

#31

Post by trashtester »

emodendroket wrote: post #7
personomas wrote: post #2

Structure is important, that's where NoSQL fails from the get go. We should stop investing so much time into NoSQL and look more into combining SQL and Graphs

That seems a little like saying there's no reason for anyone to use a language without GC. Sure, for most applications it is fine.

That's a good analogy. SQL RDBMS's, just like Java and other languages with GC have huge utility in a multitude of enterprise software situations. These probably make up the majority of software systems and lines of code out there.

Then there are a few domains that NEED other solutions. In terms of CPU cycles these may be consuming more resources. These are operating systems, game engines, ML libraries, search engines, social media platforms and huge webshops like Amazon.

But to store all data in Spark or MongoDB just because that's what is doing makes about as much sense at programming everything in C/C++.

Re: NoSQL: The Baby and the Bathwater

#32

Post by trashtester »

collaborative wrote: post #22
winrid wrote: post #12

Earlier quoted context omitted.

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 wo…

Some claim the opposite, though. Even in this discussion. That NoSQL is needed when you need to change the schema in a production system.

Anyway, most systems that last more than a couple of years tend to change over time, meaning the schema is likely to need extensions.

Re: NoSQL: The Baby and the Bathwater

#33

Post by brightball »

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…

You can always use JSONB columns to get the Postgres experience.

Re: NoSQL: The Baby and the Bathwater

#34

Post by jrumbut »

collaborative wrote: post #22
winrid wrote: post #12

Earlier quoted context omitted.

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 wo…

This is true, it's also very difficult to do in most business situations (getting the schema right from the get go).

Re: NoSQL: The Baby and the Bathwater

#35

Post by revscat »

collaborative wrote: post #22
winrid wrote: post #12

Earlier quoted context omitted.

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 wo…

Which seems to imply a static schema, known more-or-less perfectly at the outset, and unchanging thereafter. That is obviously unreasonable. Application data structures change as new requirements arise, and as existing requirements become better understood.

Re: NoSQL: The Baby and the Bathwater

#36

Post by 9dev »

winrid wrote: post #13
personomas wrote: post #2

Structure is important, that's where NoSQL fails from the get go. We should stop investing so much time into NoSQL and look more into combining SQL and Graphs

You can use NoSQL with a schema and have strict enforcement. What the NoSQL db does is make storing objects easy with less boilerplate or abstraction.

How is NoSQL with schema validation and strict enforcement anything but SQL with extra steps?

Re: NoSQL: The Baby and the Bathwater

#37

Post by nhourcard »

tgv wrote: post #28
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 agre…

Hi tgv, curious to hear why you picked NoSQL for your time-series use case?

Re: NoSQL: The Baby and the Bathwater

#38

Post by RedShift1 »

collaborative wrote: post #22
winrid wrote: post #12

Earlier quoted context omitted.

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 wo…

This is completely opposite to the raison d'être of NoSQL databases. They all started out without support for schemas because there was a desire to get away from the schema-upfront and rigidness of SQL databases. They were created to be able to drop in whatever you want as opposed to SQL databases that has strict rules about what goes in.

Re: NoSQL: The Baby and the Bathwater

#39

Post by dgb23 »

9dev wrote: post #36
winrid wrote: post #13

Earlier quoted context omitted.

You can use NoSQL with a schema and have strict enforcement. What the NoSQL db does is make storing objects easy with less boilerplate or abstraction.

How is NoSQL with schema validation and strict enforcement anything but SQL with extra steps?

The schema restrictions you can express in SQL are both insufficient and not flexible enough even for relatively trivial things, except you are either fine with storing and retrieving things in a completely different shape than you actually need, or if you are fine with constantly migrating your schema.

That's not a sufficient argument against adopting SQL for something, but other solutions are certainly _not_ just SQL with extra steps. Not everything maps nicely onto flat tables with predefined slots.

Re: NoSQL: The Baby and the Bathwater

#40

Post by sudhirj »

zztop44 wrote: post #23
roenxi wrote: post #15

Earlier quoted context omitted.

> 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.

I use schema for everything relational, and put everything else (all the nice-to-know data) in JSONB. Works really well. Stacks like Rails lean into this with `store_accessor` which lets you designate a JSON column as storage for arbitrary data that looks and feels like a separate column.
Post reply on HN