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

161–170 of 310 posts

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

#161

Post by imtringued »

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…

SQL is just a querying language, the point of the article is that it's not exclusive to RDBMS, it is also used by NoSQL databases. There is also no law that says RDBMS must be strongly consistent. They can also be eventually consistent. The opposite also applies to NoSQL databases.

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

#162

Post by smt88 »

bni wrote: post #155
davidw wrote: post #70

Earlier quoted context omitted.

> SQL was originally designed for non-programmers SQL sounds like something from the Star Trek original series era to me. Read it with a Shatner voice: Computer, SELECT course WHERE klingons = 0;

And this is a bad thing? Sounds awesome to me, make the computer do stuff for me without specifying how.

It's very tedious to write and change a big query. It's really hard to read a big block of SQL.

And it's bizarrely rigid about certain rules, meaning "English-like" is more of a hindrance because you're tempted to think, "This makes sense in English," even though SQL doesn't allow it.

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

#164

Post by scapecast »

ChicagoDave wrote: post #87
curun1r wrote: post #75

Earlier quoted context omitted.

> Reports require a static schema This may be true, but reports also normally require a different schema from the OLTP database. Data warehousing with star schemas is a thing and it doesn't matter whether your OLTP database is an RDBMS or a NoSQL solution...you're going to have to push data to your warehouse to run those reports. The last thing you want to be doing is running reporting queries against a database that…

The level of effort to move data from DynamoDB to a data-warehouse (which is what Redshift is), is not trivial. It may be that the Data Pipeline tools within AWS are still opaque and incomplete, but but I've seen the same problem with MongoDB implementations. Reporting is nearly always an afterthought in system architecture and it should be a first-class requirement.

I will print and frame your last sentence.

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

#165

Post by majewsky »

davidw wrote: post #70
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…

> SQL was originally designed for non-programmers SQL sounds like something from the Star Trek original series era to me. Read it with a Shatner voice: Computer, SELECT course WHERE klingons = 0;

Now that you mentioned Star Trek, I'll probably read every SQL query ever with the voice of Commander Data.

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

#166

Post by Wildgoose »

wolco wrote: post #108
craigkerstiens wrote: post #104

Earlier quoted context omitted.

Oh, I generally agree. I didn't mean the graybeard in a bad way at all. I feel a bit 50-50 on some of the reactions to JSON as a new thing at the time. But, also the practicality of how JSONB finally came to exist, the foundation it was built on and the new index types[1] in Postgres to leverage it felt like it came in the right time and in the right way. [1] http://www.craigkerstiens.com/2017/03/12/getting-started-w…

It is greybeard or graybeard?

American spelling is gray, English/UK spelling is grey.

Easy way to remember is use "a" for "American" in the American spelling, and "e" (for English) in UK (and presumably the rest of the Commonwealth).

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

#167

Post by sandGorgon »

Nobody has mentioned Postgres 10 which is going to be pretty cool in its release - https://www.ashnik.com/new-features-coming-in-postgresql-10/

Postgres is creeping up on Cassandra faster than Cassandra becomes usable. Especially the really cool work that Citus is doing.

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

#168

Post by EdiX »

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…

> SQL was originally designed for non-programmers

SQL was designed for mainframe programmers, made to look similar to COBOL and PL/I presumably with the idea that at some point in the future it could be integrated into one of those.

Its syntax has all the drawbacks of COBOL's syntax: too many useful words end up as reserved; it doesn't compose very well, leading to statements with very complex syntax rules; and it lulls users into a false sense of security by looking like natural language while being something very different (see HAVING vs. WHERE).

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

#169

Post by ddorian43 »

GrayShade wrote: post #141
happymellon wrote: post #133

Earlier quoted context omitted.

What? No they aren't, I work with satellite imagery processing which is quite large in it raw data format, and after a decade we are not dealing with petabytes of active data, hundreds of gigs for a full earth coverage. Before that I have held positions in finance, dealing with realtime transaction processing. We did not work in petabytes. If you are working in petabytes you are storing crap in your production databa…

> What? No they aren't, I work with satellite imagery processing which is quite large in it raw data format, and after a decade we are not dealing with petabytes of active data, hundreds of gigs for a full earth coverage. This get large rather fast when processing time series from multiple sensors. But I agree with you otherwise, and it's not like you're storing satellite products in a database. Now I'm curious what…

https://accumulo.apache.org/

See (History): https://en.wikipedia.org/wiki/Apache_Accumulo

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

#170

Post by ddorian43 »

sandGorgon wrote: post #167

Nobody has mentioned Postgres 10 which is going to be pretty cool in its release - https://www.ashnik.com/new-features-coming-in-postgresql-10/ Postgres is creeping up on Cassandra faster than Cassandra becomes usable. Especially the really cool work that Citus is doing.

Nah, postgresql still doesn't have a nice/easy sharding policy. Don't forget that citus is still single-master (the opensource one). Postgresql-xl also doesn't have nice/easy replication.

Scylladb is creeping up on Cassandra though.

Post reply on HN