Detailed read from two contributors on the project- https://www.ibm.com/cloud/blog/database-deep-dives-janusgrap...
JanusGraph – Distributed, open source, scalable graph database
21–30 of 43 posts
Re: JanusGraph – Distributed, open source, scalable graph database
#22Earlier 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.
>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…
An Orch like you will never understand the difference between a fruit and berry. You better get off the Internet before you break it all with your hairy feet. Surprising? It is basic db design.
Re: JanusGraph – Distributed, open source, scalable graph database
#23Graph 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.
There is a lot - customer support (aka customer 360), fraud detection, some maintenance cases, inventory, recommendations, etc. But it’s heavily dependent on requirements - what should be response time. Most of graph databases are good in fast response time, but will do it only for 2-3 hops from known start points. For many other things, graph analytics with Spark or something like could be better
Re: JanusGraph – Distributed, open source, scalable graph database
#24Earlier quoted context omitted.
I also don't see many valid use cases for graph databases.
There is a lot - customer support (aka customer 360), fraud detection, some maintenance cases, inventory, recommendations, etc. But it’s heavily dependent on requirements - what should be response time. Most of graph databases are good in fast response time, but will do it only for 2-3 hops from known start points. For many other things, graph analytics with Spark or something like could be better
2-3 hops (JOINs) is well within RDBMS territory, no?
Re: JanusGraph – Distributed, open source, scalable graph database
#25Earlier quoted context omitted.
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…
I am a senior IT architect. I give you the junior card but in the whole, you don't know at all what you are babbling about. ALL databases have tradeoffs.
Please refrain from personal attacks, it doesn't contribute to the discussion. And it's not consistent with the community guidelines [0].
> ALL databases have tradeoffs
That was exactly my point.
Re: JanusGraph – Distributed, open source, scalable graph database
#26Earlier 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.
First of all, "expensive writes and cheap reads" is the common case. Second, nothing about graph databases implies expensive writes and cheap reads.
This is the ONLY reason to use a graph databases.... Go a head and down vote instead of learn something. :)
Re: JanusGraph – Distributed, open source, scalable graph database
#27Graph 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 also don't see many valid use cases for graph databases.
It's the most general purpose means I can see to model entities. I can't see many invalid uses.
Re: JanusGraph – Distributed, open source, scalable graph database
#28Graph 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.
We kind of ran into a similar problem. Our core data (multi-context execution/event traces) is fundamentally graph shaped, but it's also among the pathologically poor graph structures for most general purpose graph databases and their associated query DSLs and execution planners/optimizers, so we had to build a solution that was tailored more for our domain (verifying system properties of complex interacting components).
Which I suppose kind of typifies the problem. Graph databases are fantastic because they let you flexibly and coherently model practically anything. But, perhaps principally because of this, they can become an impediment once you better understand the nuances and idiosyncrasies of your domain, and thus need something that has more optimal (or perhaps predictable) performance for the kinds of questions you know you need to ask over a representation of your domain/data that you know is sufficient?
Re: JanusGraph – Distributed, open source, scalable graph database
#29Earlier quoted context omitted.
First of all, "expensive writes and cheap reads" is the common case. Second, nothing about graph databases implies expensive writes and cheap reads.
This is the ONLY reason to use a graph databases.... Go a head and down vote instead of learn something. :)
That is not the only reason to use a graph database, and you're not exactly making a compelling argument, or a coherent one. I doubt I have much to learn from you on the subject.
Re: JanusGraph – Distributed, open source, scalable graph database
#30Earlier quoted context omitted.
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…
I am a senior IT architect. I give you the junior card but in the whole, you don't know at all what you are babbling about. ALL databases have tradeoffs.
This is practically parody...
I'm the founder of a company building a graph product. I've talked to numerous researchers in the field, read papers on the subject, I've even reviewed PHD candidates thesis for universities. I routinely field offers for consulting explicitly on graph database technology.
You haven't said anything of substance and the little you have said has only served to convey your own ignorance on the subject. I've flagged a few of your posts since they break HN rules.