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

271–280 of 310 posts

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

#271

Post by [deleted] »

vgt wrote: post #266
tyingq wrote: post #258

Earlier quoted context omitted.

Sure. I wasn't trying to make it sound like a conspiracy. Just that the constraints of running it only on the Google cloud invalidate some typical use cases. For many companies, you would have to migrate quite a high percentage of your business data out there to avoid huge amounts of egress charges. Spanner also doesn't support INSERT, UPDATE, etc, which may also be limiting.

I think your point is a microcosm of the popular "cloud TCO" debate - benefits of higher levels of abstraction. Can you get Google's network elsewhere? No. Does it cost more? Sometimes. Is it useful? For a lot of folks running products and services very much so. Higher levels of automation and abstraction (Spanner) may cost more on paper, but when you start calculating the cost of dealing with shoddy network, cost of…

[deleted]

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

#272

Post by unclebucknasty »

craigkerstiens wrote: post #104
unclebucknasty wrote: post #103

Earlier quoted context omitted.

I think I'm one of those graybeards. I see it in so many things tech. It's a pattern, and once you've seen it repeat a half-dozen times and also gain a depth of experience over that time, you can actually recognize when something represents genuine progress vs yet another passing fad. Spoiler alert: those that are most rabidly promoted are often the latter. But, if you try to raise the point in the midst of the lates…

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…

>I didn't mean the graybeard in a bad way at all.

Oh, no offense taken. What you read in my comment was genuine recognition on my part that I've likely crossed over into the graybeard camp--both in experience and disposition.

>I feel a bit 50-50 on some of the reactions to JSON as a new thing at the time.

Yeah, there have certainly been real improvements in tech that are perfectly reasonable. And, actually, I think it's the incremental improvements that add up over time which actually comprise the bulk of our real progress.

I think where things get off track is when we make sudden pronouncements that we must now cease doing everything we've done heretofore with tech Y in favor of new and shiny tech X. Every use case. Period. Whether it's killing XML because, JSON or killing SQL because, NoSQL or adopting J2EE for every "enterprise" app, or never writing Vanilla JS again because, Framework Fill-in-The-Blank; the list goes on.

There's just a tendency in the tech community to lurch in different directions with this extreme vigor. But, when you really think about it, once the foundations are laid there just aren't many quantum leaps that truly merit such strong reactions.

And, what's really strange is that we somehow manage to overlook glaring weaknesses in the new tech, and likewise disregard (or even impugn) the strengths of the tech we're displacing in ways that are obviously unfavorable. For instance, suddenly deciding we don't need ACID transactions. What?

You see that stuff and it's an automatic, "yeah, this will all blow over soon". We then generally a.) forget it ever happened or b.) settle into assigning the proper use-cases, adopting/integrating the best properties of the tech, and moving on. Incremental.

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

#273

Post by tyingq »

vgt wrote: post #266
tyingq wrote: post #258

Earlier quoted context omitted.

Sure. I wasn't trying to make it sound like a conspiracy. Just that the constraints of running it only on the Google cloud invalidate some typical use cases. For many companies, you would have to migrate quite a high percentage of your business data out there to avoid huge amounts of egress charges. Spanner also doesn't support INSERT, UPDATE, etc, which may also be limiting.

I think your point is a microcosm of the popular "cloud TCO" debate - benefits of higher levels of abstraction. Can you get Google's network elsewhere? No. Does it cost more? Sometimes. Is it useful? For a lot of folks running products and services very much so. Higher levels of automation and abstraction (Spanner) may cost more on paper, but when you start calculating the cost of dealing with shoddy network, cost of…

None of that is my particular issue.

This is specific to moving a largish companies data to the cloud. Typically, nobody wants to move it all at once. They want to move one thing first. Think like a trucking company. They have databases of customers, drivers, equipment, orders, invoices, quotes, etc, etc. With the current model where egress traffic is priced so high, it's difficult to move one of those subject areas to the cloud. The reason is because none of them act like an island. They are used together. So unless you move it all at once, huge amounts of data go back and forth all day long.

Not every customer with concerns is just someone that needs to be educated about how awesome Google is :) I do like Spanner. I'm just pointing out a barrier to adoption.

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

#274

Post by 6nf »

jaequery wrote: post #132
6nf wrote: post #92

Earlier quoted context omitted.

> damn near impossible for most MySQL users. MySQL? Nobody, and I mean NOBOBY is saying you should use MySQL. All of the things you mention is trivial using a decent SQL solution like PostgreSQL.

i haven't touched mysql in years but quite frankly, 99% of websites out there (blog/cms) will run fairly fine on a Mysql database. as for the other 1%, they would be big enough to pick the right db of their choice as the time comes. so there is no need to tell everyone you should be using this or that. this is kind of like telling everyone that they should ALL be using emacs, when vim/nano is still sufficient for the…

I honestly don't see a single reason why MySQL should be used over PostgreSQL for anything, thus my sweeping statement. I could be wrong but I don't think so.

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

#275

Post by MBCook »

PKop wrote: post #47
MBCook wrote: post #26

Earlier quoted context omitted.

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

OP probably means not worrying about instances, scaling or over/under provisioning etc, just service usage at a more fine grained level.. more like Spanner

It’s been a while since I looked at it but isn’t that how Aurora works? Isn’t that (along with performance) their argument for why you should use it over MySQL or Postgres in RDS?

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

#276

Post by botskonet »

I've long struggled with NoSQL. My data is relational, and I've been long taught to normalize and de-dup my data, so how do I use this? I keep feeling like I'm missing the genius because I keep coming back to wishing I had a true relational table.

However, there have been times where being forced to define a schema has been painful. If our app has to store dynamic keys/values it all winds up as records in a relational db table acting like key/value store. Whereas in Mongo we can just store the document, without affecting the entire table schema.

I want the best of both worlds...

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

#277

Post by tomnipotent »

pixelmonkey wrote: post #179
tomnipotent wrote: post #16

Earlier quoted context omitted.

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

You missed the point - both SQL & CQL are declarative languages.

>> CQL does not even have SQL SELECT.

https://docs.datastax.com/en/cql/3.1/cql/cql_reference/selec...

This sure looks a lot like SQL SELECT. It returns a projection of data. Beyond that it's just pedantry.

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

#278

Post by pixelmonkey »

tomnipotent wrote: post #277
pixelmonkey wrote: post #179

Earlier quoted context omitted.

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

You missed the point - both SQL & CQL are declarative languages. >> CQL does not even have SQL SELECT. https://docs.datastax.com/en/cql/3.1/cql/cql_reference/selec... This sure looks a lot like SQL SELECT. It returns a projection of data. Beyond that it's just pedantry.

Not supporting WHERE, GROUP BY, all aggregate functions, almost all other "standard" functions, most forms of DISTINCT, ORDER BY (except one order defined at table create time), all forms of sub-select/CTEs, etc. is pedantry?

OK. :)

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

#279

Post by dgudkov »

richardknop wrote: post #173
dgudkov wrote: post #83

Earlier quoted context omitted.

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

I deal a lot with SQL for reporting and analysis and wouldn't call a 300-line query easy. I found that visual tools can cover 90% of the cases for querying, merging, aggregating, filtering and calculating. They also help with hand-written SQL for the remaining 10% because you can use them to generate parts of SQL that can be used as subqueries or as a starting point in a hand-written SQL query. Also debugging complex SQL queries can be a pain, because SQL is a declarative language. You can't just put a breakpoint in a SQL query and see capture its intermediate state.

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

#280

Post by jjirsa »

stephenr wrote: post #247
jjirsa wrote: post #49

Earlier quoted context omitted.

There is so much wrong with this post I don’t know where to start Old school sql replication is awful. It’s awful in Postgres (single threaded replay? A single vacuum can make your slaves fall behind). It’s awful in MySQL (go ahead and tell me how you do dual master without rewriting your app). People use nosql not because it’s eady or flawless, but because doing it with sql is an order of magnitude harder. Go ahead…

Galera + HAProxy or ProxySQL should give you a multi-master MySQL with no app rewrites required, no?

Primary key conflicts are still a thing. Especially problematic where you're either not using auto_incrementing PKs, and/or you try to switch writes from one master to the other and app has to be aware of the switch.
Post reply on HN