JanusGraph – Distributed, open source, scalable graph database
1–10 of 43 posts
Re: JanusGraph – Distributed, open source, scalable graph database
#2No
Re: JanusGraph – Distributed, open source, scalable graph database
#3No
Elaborate?
Re: JanusGraph – Distributed, open source, scalable graph database
#4Re: JanusGraph – Distributed, open source, scalable graph database
#5Re: JanusGraph – Distributed, open source, scalable graph database
#6Earlier 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.
That's a bit much. I have a hobby project that is the graph of all taxons. It is not write heavy, to say the least. (I use mysql for it but still :))
Re: JanusGraph – Distributed, open source, scalable graph database
#7Earlier 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 cause expensive writes and cheap reads. Something anybody typically never ever needs.
I find this statement really surprising, just about every application not dealing with money I've ever been on has had lots more reads than writes and would thereby benefit if the reads were cheap - obviously nobody wants expensive writes but if the benefit is cheap reads and the expensiveness of writes can be dealt with by batching etc. I guess it's an acceptable tradeoff.
Re: JanusGraph – Distributed, open source, scalable graph database
#8Earlier quoted context omitted.
You elaborate. Graph databases cause expensive writes and cheap reads. Something anybody typically never ever needs. I worked with neo4j and cypher. Same garbage.
That's a bit much. I have a hobby project that is the graph of all taxons. It is not write heavy, to say the least. (I use mysql for it but still :))
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.
Re: JanusGraph – Distributed, open source, scalable graph database
#9There were a couple years where it was mostly abandoned. Good to see this solid graph database being well maintained. the milestones[1] mostly show a lot of upgrading libraries, some enhancements/features sprinkled in, but for a while Janus was nearly abandoned.
Maintenance re-started in 2017, with IBM & Google stepping up to back it[2].
[1] https://github.com/JanusGraph/janusgraph/milestones?state=cl...
[2] https://architecht.io/google-ibm-back-new-open-source-graph-...
Re: JanusGraph – Distributed, open source, scalable graph database
#10Earlier quoted context omitted.
That's a bit much. I have a hobby project that is the graph of all taxons. It is not write heavy, to say the least. (I use mysql for it but still :))
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 example.
Would I use a graph DB for a heavily transactional system like banking? No. Different problem, different requirements, different tech choice.
But you seem to be suggesting that there are no problem scenarios where the characteristics of a graph DB are a good fit. That seems naive at best.