No-SQL databases are glorified caches(hernantz.github.io) |
No-SQL databases are glorified caches(hernantz.github.io) |
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.
So I will try it again, see if it works this time around.
- Datomic
- Crux
- Datahike
- DataScript
- Datalevin
Some of them running in the browser, which power Roam Research and its clones
- Athens
- Logseq
- Obsidian
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.
Nothing new or interesting in this article.
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.
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.
Check out: https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc...
> Query optimizations can be difficult.
I don't think they're any more difficult than SQL really. In fact, with Dgraph we can avoid scans, where SQL has to scan for most of the queries.
In fact, we're aiming to work on query optimization in depth starting mid-May. So, perhaps in a few months, this would be a topic worth writing a blog post about.
The query optimization issue seems more to do with how the data is structured than perhaps the query engine? For example, if I wanted to query for all node type X, starting from node type A, it can potentially take a very very long time. But if I add a few known constraints like query all node type X, starting from node type A that paths through node B, C, D. It quickly gets much faster. I guess it's really more up the user to optimize the queries in these cases.
And the flexibility that graphdbs afford to the user makes it hard to realize that perhaps there are these natural constraints that can be used for this query. So it seems like there is definitely a graph analysis component to this that gives you the insight to write the queries faster.
I guess this problem also only applies to natural world problems that you are trying to force into a graph structure rather than a pre-designed database.
I might have a better write-up about this in a quarter or so.
It’s worth noting that GQL comes from Facebook, where they spend quite a bit of time operating with graph data.
The goal of GQL is to gather a useful subset of your microservice data into a single tree for your frontend to render. In a facebook context, a typical query is "give me all the info i need to be able to show my home feed".
The goal of graph dbs is to allow arbitrary, complexm, often cyclic and aggregating queries to be run against a data source expressed as a graph. A typical query is something like "how many of my friend-of-friends like basketball, displayed by location."