No-SQL databases are glorified caches (opens in new tab)

(hernantz.github.io)

45 pointshernantz4y ago29 comments

29 comments

It's surprising that graph dbs aren't more popular.

Just as document dbs can be derived/denormalized from SQL dbs, relational dbs can be derived from a graph.

Conceptually, data is a graph.

I always find the decision between 1-M and M-M is so sticky with RDBMS, and with a graph, it can be whatever you want it to be.

tuatoru4y ago

They were tried in the past, culminating in the CODASYL data model [1]. The relational model was a vast improvement in reliability and maintainability then, and it still is now.

1. https://en.wikipedia.org/wiki/CODASYL

tluyben24y ago

I have used 'graph dbs' (or stuff bolted onto something else exposing a graph and/or being called a graph-db), mostly commercial ones, for the past 20+ years because I have the same feeling as you have; every one of them was too slow (and not scalable but we didn't even get to that point). From absolutely unusable to useable as a toy; one of them was 50k$/server and it was a toy. But that was a long time ago; things moved on and I hear good things about Dgraph.

So I will try it again, see if it works this time around.

daemonk4y ago

The flexibility of a graphdb translates to flexibility in writing your queries. And that's my main problem with graphdb. Query optimizations can be difficult. It is very easy to write a query that logically does what you want, but takes hours to run. And if you take a bit of time thinking about how the query runs, you can optimize to run in milliseconds.

2 more replies

zozbot2344y ago

General-purpose graph databases have been kinda obsoleted, now that SQL can express recursive queries in a standard syntax. There's still a case for very specialized datastores that are optimized for running relatively complex algorithms on stored network/graph data, but for anything simpler you're going to get quite good performance from a standard RDBMS.

mrjn4y ago

[Author of Dgraph] Do try it out. I don't consider Dgraph to be a "NoSQL" DB. Typical NoSQL DBs are document DBs. Dgraph is unique in that it is able to use graph to deconstruct a JSON document, and re-construct it at query time. Your document could be anything you'd want at query time -- and that's really powerful. So, give it a shot.

slifin4y ago

These databases are really prevalent in the Clojure community

- Datomic

- Crux

- Datahike

- DataScript

- Datalevin

Some of them running in the browser, which power Roam Research and its clones

- Athens

- Logseq

- Obsidian

noofen4y ago

RAM is a cache for the disk. Disk is a cache for the network.

rwoerz4y ago

So, in principle you could rid of all RAM and disks an keep everything in wires?

spurdoman774y ago

Cpu registers are cache for...

hernantzOP4y ago

RAM

nine_k4y ago

Caches are fleeting. Databases are durable. This is one distinction. Caches return a value by association. Databases usually allow for range and aggregate operations on many values. This is another distinction.

Also, "no-SQL databases" is like "non-green colors"; it encompasses a much larger spectrum than it excludes. Putting graph databases, local KV stores, distributed KV stores, document stores, time-series stores, etc in the same basket just because they are not RDBMSes is not very productive.

tshaddox4y ago

Is there a term for derived denormalized data that is stored separately for very fast retrieval (so far that’s basically the definition of “cache”) and must exist for the software to function? That last part makes it distinct from (or at least a special case of) a cache. This comes up all the time in application design. A basic example would be an activity feed in a social networking app. You probably want to show all recent events which are stored in many different tables, e.g. posts, comments, likes, friend requests, etc. but you probably also need to denormalize that data because a big SQL union or join across every table that represents an event is probably not possible to do on demand.

solipsism4y ago

It's called a materialized view.

1 more reply

j16sdiz4y ago

I think the no-sql vs sql war have ended already. Most of us now know what they can or cannot do.

Nothing new or interesting in this article.

FractalHQ4y ago

What about the guy that decided to learn about databases 5 minutes ago? He doesn’t know what they can or cannot do.

myrryr4y ago

I think this article won't tell him though, and that is a problem.

This person thinks they are glorified caches, but they miss what they are good at, REALLY fast aggregation across many servers, that isn't a glorified cache, that is something else.

hernantzOP4y ago

You would be suprised to find out that mongodb is still popular for the wrong reasons

myrryr4y ago

It is also popular for the right reasons too. Sometimes you want to aggregate large datasets incredibly fast.

Sometimes you want user defined queries which are easy to restrict to parts of a dataset by rules.

If you don't have a use case for something, it doesn't mean no one else does.

1 more reply

stevefan19994y ago

and caches are glorified LRU based, key-value associated data structure with persistent storage to track data states

j / k navigate · click thread line to collapse

29 comments

vaughan4y ago

It's surprising that graph dbs aren't more popular.

Just as document dbs can be derived/denormalized from SQL dbs, relational dbs can be derived from a graph.

Conceptually, data is a graph.

I always find the decision between 1-M and M-M is so sticky with RDBMS, and with a graph, it can be whatever you want it to be.

tuatoru4y ago

They were tried in the past, culminating in the CODASYL data model [1]. The relational model was a vast improvement in reliability and maintainability then, and it still is now.

1. https://en.wikipedia.org/wiki/CODASYL

tluyben24y ago

So I will try it again, see if it works this time around.

daemonk4y ago

2 more replies

zozbot2344y ago

mrjn4y ago

slifin4y ago

These databases are really prevalent in the Clojure community

- Datomic

- Crux

- Datahike

- DataScript

- Datalevin

Some of them running in the browser, which power Roam Research and its clones

- Athens

- Logseq

- Obsidian

noofen4y ago

RAM is a cache for the disk. Disk is a cache for the network.

rwoerz4y ago

So, in principle you could rid of all RAM and disks an keep everything in wires?

spurdoman774y ago

Cpu registers are cache for...

hernantzOP4y ago

RAM

nine_k4y ago

tshaddox4y ago

solipsism4y ago

It's called a materialized view.

1 more reply

j16sdiz4y ago

I think the no-sql vs sql war have ended already. Most of us now know what they can or cannot do.

Nothing new or interesting in this article.

FractalHQ4y ago

What about the guy that decided to learn about databases 5 minutes ago? He doesn’t know what they can or cannot do.

myrryr4y ago

I think this article won't tell him though, and that is a problem.

This person thinks they are glorified caches, but they miss what they are good at, REALLY fast aggregation across many servers, that isn't a glorified cache, that is something else.

hernantzOP4y ago

You would be suprised to find out that mongodb is still popular for the wrong reasons

myrryr4y ago

It is also popular for the right reasons too. Sometimes you want to aggregate large datasets incredibly fast.

Sometimes you want user defined queries which are easy to restrict to parts of a dataset by rules.

If you don't have a use case for something, it doesn't mean no one else does.

1 more reply

stevefan19994y ago

and caches are glorified LRU based, key-value associated data structure with persistent storage to track data states

j / k navigate · click thread line to collapse