11–20 of 43 posts
Earlier quoted context omitted.
Elaborate?
You elaborate. Graph databases cause expensive writes and cheap reads. Something anybody typically never ever needs. I worked with neo4j and cypher. Same garbage.
Graph databases have been the great white whale at my org for a number of years. We gave a crack at Janus a while back. It (like a few attempts at Neo4J) failed to deliver on the promise of unlocking queries with more than a hop or two, while dramatically underperforming on those one or two hop queries vs a graph implemented in MySQL.
Graph databases have been the great white whale at my org for a number of years. We gave a crack at Janus a while back. It (like a few attempts at Neo4J) failed to deliver on the promise of unlocking queries with more than a hop or two, while dramatically underperforming on those one or two hop queries vs a graph implemented in MySQL.
I also don't see many valid use cases for graph databases.
I do think there's a valid question of how useful n-hop queries are for an N that is greater than 2 or 3.
* Flexible knowledge association i.e. Knowledge Graphing
* Modeling and querying associations / models with many-steps-removed requirements
* Expert Systems / Inference Engines
* Lazy traversal for complex job scheduling
Graph DBs are not good at being a general purpose 95% of use cases database. Just use Postgres/MySQL if you're not sure. We use Neptune (AWS managed GraphDB) to model cybersecurity dependencies between many companies and report on supply chain vulnerabilities many steps removed. Those kinds of queries are non-trivial and expensive on anything but a Graph Database.
As GraphDBs meet niche query requirements you usually have other databases involved in the full application. If you want to tractably manage many databases in a system you ideally want to be in streaming / event sourced semantics. If you're already in an imperative crud-around-data / batch pipeline you'll find greater maintenance costs in adopting a GraphDB or any additional DB for that matter.
Graph databases have been the great white whale at my org for a number of years. We gave a crack at Janus a while back. It (like a few attempts at Neo4J) failed to deliver on the promise of unlocking queries with more than a hop or two, while dramatically underperforming on those one or two hop queries vs a graph implemented in MySQL.
I also don't see many valid use cases for graph databases.
Sorry to ask about it, but while deciding the name of your Java graph database, how did you ended up with anus?
Earlier quoted context omitted.
Pretty much common knowledge... Doc db -> very cheap reads / very cheap writes Sgl db -> cheap reads / expensive writes Graph db -> cheap reads -> very expensive writes ...for the type of data.
If it were as simple as that, then surely the whole world would be using document DBs exclusively. The whole world isn't doing that. So maybe there's more to it. I'm doing some work right now where a graph is a good conceptual fit to the problem space. Writes are much less common than reads. A graph-theoretic approach is a good fit for the queries it needs to support; transitive closure and topological sort for examp…