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

181–190 of 310 posts

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

#181

Post by ddorian43 »

sandGorgon wrote: post #175
ddorian43 wrote: post #170

Earlier quoted context omitted.

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.

1. I know it's open-source, but they have a `citus-mx` product which has multiple masters which isn't open-source (currently you have to do coordinators manually).

2. Kind hard to creep up on scylladb by seeing it's architecture and assuming you use it for what it's best at, the asyncness and raw performance.

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

#182

Post by ivanhoe »

Mikushi wrote: post #148
kazagistar wrote: post #142

Earlier quoted context omitted.

1. Postgres has a json and jsonb datatype specifically to be your values. 2. It has built in query and modification tools that can manage the nested objects and array and whatnot. 3. It let's you build indexes to help with all this, including reverse indexes for asking something like "is this string in the array inside this object". 4. You don't have to specify your schema in sone horrid way, you can just throw what…

Same can be said of MySQL. Not comparing to Postgres, but I've been amazed at how many people do not know that either of these as a powerful JSON type.

Yes, too many devs I know haven't even heard about generated columns and virtual indexes in mysql.

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

#183

Post by tyingq »

tarsinge wrote: post #172
Clubber wrote: post #12

Earlier quoted context omitted.

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

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.

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

#184

Post by oblio »

pjmlp wrote: post #140
aaron-lebo wrote: post #11

Earlier quoted context omitted.

The thing is ORMs have made writing easy queries easy and hard queries possible since at the very least 2005 with Rails, and they are easily extensible and composable. It's mostly a solved issue. If you want to do complex data manipulation, surprise, it takes a powerful tool. Seems a lot of the hype is the result of VC $ + naiveity/overselling about what MongoDB and co would be capable of. The marketing is natural -…

> The thing is ORMs have made writing easy queries easy and hard queries possible since at the very least 2005 with Rails, Contrary to the hype it created, Rails was not ground breaking. We were using ORMs with Rails like concepts and scaffolding in 1999, based on Tcl, our own mod_tcl and several DB bindings to Oracle, Informix, DB2, MS SQL Server, Sybase SQL Server, running on top of Windows NT/2000, Aix, HP-UX and…

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

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

#186

Post by primeblue »

ojosilva wrote: post #136
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…

>I think the bigger issue is that you can use an RDBMS to do NoSQL-like things, such as key-value stores, with the flexibility to structure your data if you need that later. So why not start with a relational database? I've tried that in the past and failed miserably. 1) values in a key-value table will endup needing to hold nested data structures, such as a JS object/hash. Ie. mykey={...} 2) turning values to JSON (…

Modern SQL servers implement this

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

#187

Post by primeblue »

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…

XML databases lol

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

#188

Post by koolba »

Clubber wrote: post #33
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…

Also, the unstructured data is another thing. For example, lets say you need to store a bunch of contracts (as in your industry) in PDF/TIFF or whatever. The filesystem isn't a really good place to store it because you have a loose coupling between the index in the table and the file on the filesystem. That can get messy and unless security is tight, some developer or admin could muck something up on the filesystem.…

This is a perfect example of not having to use the same hammer for everything. The "standard" solution to this problem is to store the files themselves in cheap yet durable object storage (S3, NFS, etc) with a reference to the unique ID or URL in your primary database. The record locator is small (which is good for the RDBMS) and can be transactionally updated in the DB with any changes that involve that object (ex: update contract associated with a client).

There's no need to store the full details as a BLOB in your DB. That has nothing to do with SQL, NoSQL, distributed, or centralized. It's just a vanilla separation of immutable object data (the raw bytes of the PDFs) and application state (the record locator).

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

#189

Post by majewsky »

sk5t wrote: post #96
aaron-lebo wrote: post #11

Earlier quoted context omitted.

The thing is ORMs have made writing easy queries easy and hard queries possible since at the very least 2005 with Rails, and they are easily extensible and composable. It's mostly a solved issue. If you want to do complex data manipulation, surprise, it takes a powerful tool. Seems a lot of the hype is the result of VC $ + naiveity/overselling about what MongoDB and co would be capable of. The marketing is natural -…

One of the last things I'd want to do is fight with an ORM to build a complex query that doesn't fit the ORM's natural tendencies. A micro-ORM to take care of the boilerplate is great, but otherwise, given the choice between two unpleasant options, I'd rather write 100% of my database interaction code in sprocs than an ORM (promising never to use the raw-SQL escape hatch).

Micro-ORM plus plain SQL for big reports is the sweet spot IMO.

A few years ago, I was refactoring a large legacy Perl application to be much less messy and a bit more object-oriented, and I accidentally a micro-ORM without really realizing it. I think it was a 1000 lines of code in the end, and 95% of all existing SQL usages in the application could be replaced by simple method calls on the ORM's objects.

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

#190

Post by ma2rten »

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…

It's not just a subset, but there are also incompatibilities like limit limits the number of rows scanned not the number of rows returned.
Post reply on HN