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

251–260 of 310 posts

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

#251

Post by flamtap »

marrs wrote: post #204
SmellTheGlove wrote: post #18

Earlier quoted context omitted.

> It's a Google/Twitter size problem that most industries wouldn't have, but since it's the new shiny thing, you know how that goes. You nailed it on both points. Very few organizations are going to need that kind of scale, but many want to think that they will! Even when you get to horizontal scaling, you can simply replicate what needs to be replicated. Key-value is really just a subset of relational data, right? I…

Very few organizations are going to need that kind of scale, but many want to think that they will! Further to that point, many software engineers know that NoSQL is a bad fit for their organisation but use it anyway because they wish to gain the experience required to work with Big Data in the future.

Nothing helps you learn new tech quite like fighting to the death with it!

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

#252

Post by coldtea »

heedlessly2 wrote: post #243
coldtea wrote: post #176

Earlier quoted context omitted.

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

>For most of us here around HN, judging from posts, comments, and discussions, the NoSQL era was very real so you're favoring buzzword hype over actual production environments? Who cares if people are talking about it but not really using it?

No, I'm favoring actual buzzword-oriented production environments -- which is most of us work.

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

#253

Post by taeric »

pjmlp wrote: post #198
oblio wrote: post #184

Earlier quoted context omitted.

Wide scale adoption is almost as good, if not better, than "ground breaking".

Somehow SV has a tendency to re-discover stuff.

Not unique to SV. And to be fair, fundamental constraints wax and wane, as well.

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

#254

Post by xeonoex »

hvidgaard wrote: post #134
craigkerstiens wrote: post #53

I don't think the article could have said it much better. SQL is super powerful and makes much sense in so many ways. Nearly all apps have a relational structure to them and SQL is a reasonable way to interact with them. Some of my favorite conversations from the Postgres community 5-6 years back were when they were talking about a time when Postgres was being disrupted. The gray bearded DBAs (Hi Berkus and others) w…

> SQL has never been a particularly elegant language I hear that often. But SQL is close to a 1-to-1 mapping with sets of data. It's refreshing to use something as math like when programming. I find that elegant.

There's a lot of simple improvements that could be made to the syntax. Some DBMSs (mostly Postgres) do make syntax improvements, but I'll never understand why Oracle still doesn't support "is distinct from". If I want to do a join where null == null is true, I have to write

    (NOT (a  b OR a IS NULL OR b IS NULL) OR (a IS NULL AND b IS NULL))
instead of "a is not distinct from b".

The query structure is odd as well. I think it should more like

    from 
    [declare] 
    [group by] 
    [where] 
    select
Where declare is a section to declare variables (or virtual variables), so that you do not have to rewrite a calculation every time it is used. You could also declare scalar variables there. There's also no reason to have both a where and having clause.

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

#255

Post by vgt »

tyingq wrote: post #183
tarsinge wrote: post #172

Earlier quoted context omitted.

> The biggest reason I've heard is RDBMS's don't horizontally scale well Not true anymore with "NewSQL" databases (Google Spanner, CockroachDB, ...)

Both are laudable. But, Spanner is closed source and hosted on a high egress cost cloud. So use cases are limited. And Cockroachdb is promising, but in it's 1.0 release. Follow the current bug list and performance numbers...you wouldn't use it just yet for something important.

While I agree that there are situations where "network egress" can become a large part of one's bill, I encourage you to think of the technical impact of having something like Spanner and something like the Google network.

A large part of what Spanner does to sustain its high cross-regional availability at strong consistency relies on Google's powerful network [1]. Spanner isn't just source code - it's vertically integrated custom hardware + software + Google network + Google SRE - you would have very limited use from Spanner if you had just source code.

Example: Recently Google introduced "hot potato" network tiers that closer match AWS and Azure offerings (aka degraded Google network)[0]

(work at G)

[0] https://cloudplatform.googleblog.com/2017/08/introducing-Net...

[1] https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp...

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

#256

Post by pjungwir »

snuxoll wrote: post #220
ww520 wrote: post #110

Earlier quoted context omitted.

Mike Stonebraker started Ingres to build a relational database. After Ingres, he and Larry Rowe wanted to see what could be done to add the OO aspect and other complex data types in addition to the relational model; OO was starting to take off back then. They started the Postgres project (Post-Ingres) in UCB to research on object-relational database. It turned out the object-relational part was better done on the cli…

I suppose you could say Postgres did end up as an object-relational database still, composite UDT’s, array’s and domains are all features that match the original vision.

I think that is a great way of thinking about it! Composite types and user-defined types are very useful and it makes sense to see them as inspired by object-oriented ideas.

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

#257

Post by rayascott »

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…

Well said. It's amazing how many engineers will make sweeping generalisations like it's a provable fact. You'd think from their training, they'd know better. But hey, he's got a blog and service, and everyone listen up now.

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

#258

Post by tyingq »

vgt wrote: post #255
tyingq wrote: post #183

Earlier quoted context omitted.

Both are laudable. But, Spanner is closed source and hosted on a high egress cost cloud. So use cases are limited. And Cockroachdb is promising, but in it's 1.0 release. Follow the current bug list and performance numbers...you wouldn't use it just yet for something important.

While I agree that there are situations where "network egress" can become a large part of one's bill, I encourage you to think of the technical impact of having something like Spanner and something like the Google network. A large part of what Spanner does to sustain its high cross-regional availability at strong consistency relies on Google's powerful network [1]. Spanner isn't just source code - it's vertically int…

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.

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

#259

Post by testvox »

autokad wrote: post #236
taco_emoji wrote: post #233

Earlier quoted context omitted.

> "you said 125 characters for that string field and you just received 130, FAIL" Most (all?) RDBMS's have something like a varchar(max) which accepts reasonably large strings. > you have to create indexes and fus with all sorts of relational nonsense No, you don't. > its going to read the entire table into memory and re-write it back to disk Probably not, if you're adding a nullable column.

you obviously have not used databases very much if you think you can join 2 billion row tables on a key that is not indexed in a reasonable amount of time.

So? It's not like a nosql db without indexes will be any faster at it.

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

#260

Post by AzzieElbab »

Why is no one stating the obvious? 1) hardware improvments along with db hosted solutions simplified sql management and scaling 2) most data is simply useless or of very temporary value. Having said that, I do not think sql can compete with specialized solutions when it comes to unstructured or semi-structured data like EMR for example. Also, with notable exception of datalog/datomic NoSQL solutions remain kV stores hacked together by some horrible programming models
Post reply on HN