5 ms·

No-SQL databases are glorified caches

45 points by hernantz 5y ago

stevefan1999 5y ago
and caches are glorified LRU based, key-value associated data structure with persistent storage to track data states
noofen 5y ago
RAM is a cache for the disk. Disk is a cache for the network.
- rwoerz 5y ago
  So, in principle you could rid of all RAM and disks an keep everything in wires?
- spurdoman77 5y ago
  Cpu registers are cache for...
  - hernantz 5y ago
    RAM
j16sdiz 5y 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.
- FractalHQ 5y ago
  What about the guy that decided to learn about databases 5 minutes ago? He doesn’t know what they can or cannot do.
  - myrryr 5y 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.
- hernantz 5y ago
  You would be suprised to find out that mongodb is still popular for the wrong reasons
  - myrryr 5y 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.
    - MapleWalnut 5y ago
      Which NoSQL store are you talking about regarding fast aggregations? I don’t think that’s a property of all NoSQL dbs.
deleted 5y ago
[deleted]
vaughan 5y 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.
- slifin 5y 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
- tluyben2 5y 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.
  - zozbot234 5y 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.
  - daemonk 5y 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.
nine_k 5y 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.
- tshaddox 5y 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.
  - solipsism 5y ago
    It's called a materialized view.
    - tshaddox 5y ago
      That’s one implementation of a similar idea in RDBMSs, although they generally require manually refreshing them when desired. I think I’ve heard that some RDBMSs also allow you to apply normal inserts and updates to materialized views if you want to manually keep them up to date as well, although I’ve never tried that approach.
      - vaughan 5y ago
        It’s called incremental view maintenance. Check out: https://wiki.postgresql.org/wiki/Incremental_View_Maintenance https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc...

45 points by hernantz 5y ago

stevefan1999 5y ago

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

noofen 5y ago

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

rwoerz 5y ago
So, in principle you could rid of all RAM and disks an keep everything in wires?
spurdoman77 5y ago
Cpu registers are cache for...
- hernantz 5y ago
  RAM

j16sdiz 5y 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.

FractalHQ 5y ago
What about the guy that decided to learn about databases 5 minutes ago? He doesn’t know what they can or cannot do.
- myrryr 5y 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.
hernantz 5y ago
You would be suprised to find out that mongodb is still popular for the wrong reasons
- myrryr 5y 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.
  - MapleWalnut 5y ago
    Which NoSQL store are you talking about regarding fast aggregations? I don’t think that’s a property of all NoSQL dbs.

deleted 5y ago

[deleted]

vaughan 5y 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.

slifin 5y 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
tluyben2 5y 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.
- zozbot234 5y 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.
- daemonk 5y 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.

nine_k 5y 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.

tshaddox 5y 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.
- solipsism 5y ago
  It's called a materialized view.
  - tshaddox 5y ago
    That’s one implementation of a similar idea in RDBMSs, although they generally require manually refreshing them when desired. I think I’ve heard that some RDBMSs also allow you to apply normal inserts and updates to materialized views if you want to manually keep them up to date as well, although I’ve never tried that approach.
    - vaughan 5y ago
      It’s called incremental view maintenance. Check out: https://wiki.postgresql.org/wiki/Incremental_View_Maintenance https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc...