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

Why SQL is beating NoSQL, and what this means for the future of data

blog.timescale.com

Post reply on HN
Print view View original

21–30 of 310 posts

Re: Why SQL is beating NoSQL, and what this means for the future of data

#21

Post by Clubber »

LeoPanthera wrote: post #17
Clubber wrote: post #14

Earlier quoted context omitted.

Most structured data is relational. If you include data like (someone else's) web site content, images, sound files, video files, etc, it's a different picture (pardon the pun).

How is NoSQL better than simply using the filesystem?

I'm not an expert on NoSQL, but based on general computer knowledge I would say some advantages over a filesystem would be:

  1. Single entry point.
  2. Not having to share your filesystem.
  3. Centralized security separated from your OS
  4. Simple key/value access (no folder structure)
  5. Abstraction of the filesystem (like #2)
  6. Distribution of data over multiple nodes.
  7. Separation of NoSQL admin and network admins.
  8. Shiney new thing :)
I'm sure now a days, an advanced filesystem/sharing protocol would handle some of these.

Re: Why SQL is beating NoSQL, and what this means for the future of data

#22

Post by wjossey »

peterwwillis wrote: post #7

SQL wins because big iron wins. At the end of the day, the big, clunky, slow, complicated, aggravating, old systems stick around because they are built to stick around. Looking at, say, an eventually consistent distributed decentralized kv store, one might be tricked into believing it's simple enough to deploy with enough nodes and general enough interfaces that you can build a complicated system on top of it if need…

As someone who helped design, then manage a massive NoSQL store which hundreds of terabytes of data, of which most of it was hot, I’ll humbly disagree and say it’s not necessarily as bad as you make it sound.

Did we have someone who managed that system? Sometimes, but mostly it just did it’s own thing. We ironically invested way more time on our MySQL database over the years because we couldn’t get that to scale the way we wanted to, but I think that was specific to a problem we were having.

Did we later invest a lot of time in that system (the NoSQL one)? Yes, because it was very cost effective for us to do so. At certain scale throwing people at optimization problems can pay huge dividends. But, this can be said of most infrstracture. It’s usually worth revisiting every year or two and seeing how what you can squeeze out.

Did we have churning CPU, infinitely expanding disk, replication issues, and more? Sure, but not very commonly and mostly it was fairly easily resolved. More importantly though, it was a solid system that was the underpinning of a colossal system, and it behaved admiraly more than 99.9% of the time.

Will most projects benefit from a hugely distributed KV store? Nope. But I’m still glad they exist!

Re: Why SQL is beating NoSQL, and what this means for the future of data

#24

Post by ChicagoDave »

I had the task of replicating data from DynamoDB to Redshift on AWS on two large projects on the last few years. The primary factor in using DynamoDB is that is's cheap and scales like nothing else in the galaxy.

Then the other shoe fell. The data was needed for reports. Reports require a static schema. NoSQL (and the developers who love it) despises static schema. "I can add properties whenever I want!"

This process of analyzing and reporting on production data becomes a very time-consuming, costly, and brittle exercise.

So then you have to determine, did we save enough money on the design side (using NoSQL over SQL) and then piss it away on reporting?

I'd argue AWS and other cloud providers need to create a SQL capable relational database as a service. This would (I hope) solve the problem.

But in the meantime, let's build our micro-services on relational databases so we can actually get aggregate data to stakeholders in real-time.

Re: Why SQL is beating NoSQL, and what this means for the future of data

#25

Post by pjungwir »

I've always found it a little funny that SQL was originally designed for non-programmers, sort of like AppleScript. I used to think neither of those panned out, but in fact there really are a lot of smart not-programmers who can use it. At a company I work with many of the support staff have been learning SQL to help customers pull reports from our data warehousey reporting database. So maybe the article is onto something about the value of the language.

On the other hand, SQL-the-language isn't essential to relational databases. I have often wondered where C.J. Date has been the last few years. I actually love SQL, but it does have its limitations. I wouldn't mind a solid relational database with an alternative query language. It's such a missed opportunity for a great VC pitch: Tutorial D, NoSQL before it was cool. :-)

Re: Why SQL is beating NoSQL, and what this means for the future of data

#26

Post by MBCook »

ChicagoDave wrote: post #24

I had the task of replicating data from DynamoDB to Redshift on AWS on two large projects on the last few years. The primary factor in using DynamoDB is that is's cheap and scales like nothing else in the galaxy. Then the other shoe fell. The data was needed for reports. Reports require a static schema. NoSQL (and the developers who love it) despises static schema. "I can add properties whenever I want!" This process…

> I'd argue AWS and other cloud providers need to create a SQL capable relational database as a service. This would (I hope) solve the problem.

Isn’t that Aurora?

Re: Why SQL is beating NoSQL, and what this means for the future of data

#28

Post by daveFNbuck »

ChicagoDave wrote: post #24

I had the task of replicating data from DynamoDB to Redshift on AWS on two large projects on the last few years. The primary factor in using DynamoDB is that is's cheap and scales like nothing else in the galaxy. Then the other shoe fell. The data was needed for reports. Reports require a static schema. NoSQL (and the developers who love it) despises static schema. "I can add properties whenever I want!" This process…

> I'd argue AWS and other cloud providers need to create a SQL capable relational database as a service.

Like Google's Cloud SQL? https://cloud.google.com/sql/

Re: Why SQL is beating NoSQL, and what this means for the future of data

#30

Post by Clubber »

pjungwir wrote: post #25

I've always found it a little funny that SQL was originally designed for non-programmers, sort of like AppleScript. I used to think neither of those panned out, but in fact there really are a lot of smart not-programmers who can use it. At a company I work with many of the support staff have been learning SQL to help customers pull reports from our data warehousey reporting database. So maybe the article is onto some…

Also, SQL was designed back when most programming was done in assembler or C. Compared to assembler, SQL is easy. Programming itself has gotten a lot easier since.
Post reply on HN