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

171–180 of 310 posts

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

#171

Post by GrayShade »

ddorian43 wrote: post #169
GrayShade wrote: post #141

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

Thanks, I wasn't aware of it.

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

#172

Post by tarsinge »

Clubber wrote: post #12
SmellTheGlove wrote: post #10

This was a nice read for the history. Honestly, being in a big legacy industry (Insurance), it's as though NoSQL never happened. We're too big, at least my organization, to have made the wholesale change and we've been plugging along mostly in Teradata and DB2 for a long time. Teradata in particular has performed well across a variety of use cases, its only large downside being the cost. Anyhow, only point I'd add is…

>So why not start with a relational database? I asked the same question. The biggest reason I've heard is RDBMS's don't horizontally scale well, meaning you can't easily have 50 replicated nodes across the globe and expect it to perform well, or setup easily, because it's fairly complicated with an RDBMS. There's things like Oracle's grid or SQL's high availability clusters, but they get complicated fast, particularl…

> The biggest reason I've heard is RDBMS's don't horizontally scale well

Not true anymore with "NewSQL" databases (Google Spanner, CockroachDB, ...)

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

#173

Post by richardknop »

dgudkov wrote: post #83
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…

>I work with many of the support staff have been learning SQL to help customers pull reports from our data warehousey reporting database. Why wouldn't you use a visual query tool for this? Tableau and similar apps generate pretty decent SQL queries nowadays. Even old-school BusinessObjects does a decent job (although requires way more initial modelling).

SQL is just much more powerful. If your staff learns SQL they can pull out very complex reports easily, aggregating and combining, joining data. Expressiveness of SQL allows you to get better results you can get from any visual tool.

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

#174

Post by ak39 »

dragonwriter wrote: post #79
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…

Tutorial D obviously isn't SQL, but its not noSQL, either; despite the name, noSQL refers to non-relational stores, not relational stores with alternative query languages. But as much as I think it's better than SQL, I don't think Tutorial D (or D as a concept more broadly) offers enough to really displace SQL.

> noSQL refers to non-relational stores, not > relational stores with alternative query languages.

Very well said. The concept of relational databases (based on relational/algebraic theory) is thoroughly independent of the dialects to access said databases. Currently it's SQL.

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

#175

Post by sandGorgon »

ddorian43 wrote: post #170
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.

citus is all opensource now - https://www.citusdata.com/blog/2016/03/24/citus-unforks-goes...

https://github.com/citusdata/citus

Which is why Postgres is creeping up on both scylladb and cassandra.

Plus PG 10 will have declarative partitioning built in. Pretty cool.

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

#176

Post by coldtea »

randomdrake wrote: post #40

I don't buy it. The makers of the software that this appears to be a carefully written advertisement for, came to the same conclusion as the rest of the IT world (that some of us saw a mile away): NoSQL was, and still is, only good for very specific things in very specific cases; it's generally dreadful for anything that SQL engines could already do well. The subtitle for this contains: "After years of being left for…

>Who? Where's the data? This blog post has a lot of links, references, and studies, but where's the data to back up the premise?

If you had been following startup blogs and HN, then you don't need any more data to back their premise.

It's not like total data matters anyway -- what's important is what use cases people regularly encounter in their periphery and the part of the industry they work on, which might not be what some overall data will show.

I don't care for example if NoSQL only caught on with 1% of developers while 99% of Fortune 500 enterprises and companies in rural Idaho and southern Mongolia used trusty old MS-SQL Server.

For most of us here around HN, judging from posts, comments, and discussions, the NoSQL era was very real, in the kind of companies and environments we knew.

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

#177

Post by naranha »

jondubois wrote: post #146

this article is overly opinionated and narrow-minded. Many startups use NoSQL. Personally I prefer NoSQL for most use cases. That said I have nothing against SQL itself but I will NEVER go back to using an ORM - They're a dirty hack; always have been and always will be. I'd rather write the SQL by hand. I love using MongoDB; it's very simple to use. I liked RethinkDB's ReQL even more (even though the company itself h…

I really agree with you. I think ORM is responsible for a lot of failed software projects, since it leads to over-engineering. I saw a lot of projects where 90% of the mapped columns or tables could be replaced with JSON, because they were simply never queried against.

One thing I learned writing SPAs is that joins are often unnecessary because with proper state management a lot of data is already present on the client side. NoSQL Query languages (for example Mongo or CouchDB queries) are more than sufficient for these use cases.

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

#178

Post by coldtea »

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…

>I've always found it a little funny that SQL was originally designed for non-programmers

That's not true.

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

#179

Post by pixelmonkey »

tomnipotent wrote: post #16
SmellTheGlove wrote: post #10

This was a nice read for the history. Honestly, being in a big legacy industry (Insurance), it's as though NoSQL never happened. We're too big, at least my organization, to have made the wholesale change and we've been plugging along mostly in Teradata and DB2 for a long time. Teradata in particular has performed well across a variety of use cases, its only large downside being the cost. Anyhow, only point I'd add is…

>> Pretty sure that SELECT, FROM, WHERE will work just about anywhere Cassandra & CQL is a prime example. CQL become the de facto interface for getting data out of Cassandra, even without the benefits of JOIN's & sets.

CQL is not SQL. CQL does not even have SQL SELECT. There is no support for arbitrary WHERE clauses, for example. You need to either slice an ordered column, or select a row by primary key -- and nothing else! They have an ALLOW FILTERING option which lets you "do it anyway", but this reduces down to paging the whole dataset without the WHERE applied, and then doing client-side filtering.

I always felt that CQL did more harm than good for Cassandra. It's not like Redshift -- which implemented a full mostly-Postgres compatibility layer. Cassandra's CQL "looks like" SQL in the same way JavaScript "looks like" Java. Similarity by superficial appearance only; under the hood, totally different.

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

#180

Post by dom0 »

Clubber wrote: post #21
LeoPanthera wrote: post #17

Earlier quoted context omitted.

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

The biggest advantage is that you get transactions. (Or Not). Possibly faster small objects with less (memory, storage) overhead.
Post reply on HN