Hacker News Reader

Comment by Derek_MK | Hacker News Reader

There are places where relational DBs are inherently better than noSQL (namely when you need fully up-to-date information on every query, no matter what) - But those situations are becoming more rare compared to situations where potentially stale data is an okay tradeoff for performance gains.

Honestly, IMO the biggest issue holding noSQL databases back is lack of good documentation/support a lot of the time. Technically, though, they're going to become the standard for most use cases soon.

View on HN

Why do people continue to use the term NoSQL ? It's ridiculous.

There are hundreds maybe thousands of NoSQL databases ranging from Redis to MongoDB to Cassandra to InfluxDB to Druid. They pretty much have nothing in common other than storing data. Many of them support SQL directly, others via Spark and almost all have a SQL equivalent.

Exactly this, „non-traditional“ and noSQL is as inexact as it gets. It includes an incredibly wide range of architectures, from Spanner and CockroachDB which deliver ACID guarantees equal and even surpassing relational systems to pure performance tuned systems such as Aerospike which have few guarantees and features but are blazingly fast. There are pretty much all shades of consistency in between, like Cassandra and Scylla with tunable consistency amd LWT. Lumping them all together into a single category will yield poor results.

> when you need fully up-to-date information on every query, no matter what

This doesn't require something relational, just something centralized. And not even that; consider Spanner.

Agreed. I think for temporal data (accounting) reporting non-relational databases are fine.

To clarify further. Of course, you will need a relational data repository.

The problem with noSQL is that there are too many players out there making duplicated efforts. You have MySQL & MariaDB and PostgreSQL as the two main SQL platforms, but you have too may to list in the noSQL field- most of them providing the same amount of functionality.

This always happens and the noSQL market will eventually consolidate / settle down to a handful of players just as the SQL market did.

That depends on the functionality requirements of noSQL customers. I posit that writing a new, indepedent RDBMS that implements the latest SQL spec with the same maganement and replication capabilities as the incumbents is on-par with trying to compete with WebKit and Gecko. The SQL Server engineering team at Microsoft is about 1,000 people according to my friends on campus.

Whereas implementing a Key-Value Store is orders of magnitude simpler. There is plenty of room for innovation, of course - but you don’t need 1,000 people to build-on some new replication scheme or distributed backend.

If you take a simple NoSQL system then tack on things like object scheme support, JSON blob value indexes, node graph support, etc you’ll end up with an RDBMS analogue.

So the barrier-to-entry to building a NoSQL system is much lower than a RDBMS - and for many companies they might decide to build their own rather than extend an existing system - leading to more completion but not necessarily a better product.

It always starts that way. In time, the legacy baggage that gets added will turn the noSQL databases into the same bloated monsters that the SQL databases have become. There was a time when many of the SQL database options were the (relatively) simpler and more powerful options vs the wide variety of home-grown databases they eventually replaced. (i.e. there was a lot of baked in business logic etc. that the move to SQL databases forced companies to disentangle from the database engine itself) SQL Server was originally just a fork of Sybase SQL Server (a much smaller, simpler version) with some FoxPro tech bolted on to it...

Right - and FoxPro was just another dBase clone. NoSQL today is where dBase was 30 years ago.

A famous P. Greenspun quote may be savagely hacked for the topic at hand: Any sufficiently complicated No/New/WhateverSQL engine contains an ad hoc, informally-specified, bug-ridden, slow implementation of a RDBMS.

> That depends on the functionality requirements of noSQL customers. I posit that writing a new, indepedent RDBMS that implements the latest SQL spec with the same maganement and replication capabilities as the incumbents is on-par with trying to compete with WebKit and Gecko. The SQL Server engineering team at Microsoft is about 1,000 people according to my friends on campus.

CockroachDB is the newest from-scratch SQL engine that I am aware of: https://www.cockroachlabs.com/

They re-use the RocksDB K/V store maintained by Facebook (in C++) as the storage layer, and their own code is written in Go, so I suspect that their development work is probably a lot less time-expensive than the teams working on older SQL databases.

Are you forgetting about SQL Server and Oracle?

And SQLite!

and Sybase and ComDB...

That’s what happens in a growing market. Once it’s matured, it boils down to a handful.

> You have MySQL & MariaDB and PostgreSQL as the two main SQL platforms

Based on license revenue it's actually Oracle and MS SQL server by miles. They are currently #1 and #3 on DB-Engines.com. (https://db-engines.com/en/ranking) MySQL is #2. PostgreSQL is #4, though it's pretty far back from the first three.

Maybe I'm confused, but ranking databases on license revenue will inevitably show that the databases that charge licenses are higher.

I mean PostgreSQL is open source, and required no license fee. I'm not sure that license revenue is a good comparison metric.

DBMS Engines uses a set of metrics that does not include revenue. See https://db-engines.com/en/ranking_definition for more. Oracle and MS SQL Server have consistently ranked highly there for many years.

You know MySQL, MariaDB, and Postgres don't have licensing costs, right?

Of course. I've worked in and around the OSS DBMS market for over a decade. But the numbers were really big. It seems to me that out of a 2015 US $30B DBMS market Oracle and MS were collecting something like US $29B. The rest of the market,which included products like MongoDB and Cassandra was close to a rounding error. (I don't have the Gartner report handy, sorry.)

It's popular on HN to focus on OSS products, but there's a very large proprietary RDBMS market measured both in terms of revenue as well as users. That's how Oracle and MS got to be the behemoths they are today.

> namely when you need fully up-to-date information on every query, no matter what

So you basically want full consistency (vs eventual consistency) in a distributed environment. You can set up you noSQL that way. I don't see how relational DB's are "better" than noSQL in consistency.

And if you do that you go back to the performance of one instance or (probably) worse.

Absolutely, but isn't that the case for SQL too? My point being, noSQL is not worse than SQL if all you care about is storing and retrieving documents vs joins, etc.

Reply on news.ycombinator.com