4 ms·

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

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.

tschellenbach 5y ago
I also don't see many valid use cases for graph databases.
- freewilly1040 5y ago
  Marketing and fraud detection are pretty valid imo. Just inherently hard to scale. 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.
- tejtm 5y ago
  Have you tried getting grants promising they will deliver? </s>
- alexott 5y ago
  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
  - pphysch 5y ago
    2-3 hops (JOINs) is well within RDBMS territory, no?
    - freewilly1040 5y ago
      Yes. But it’s not a very exciting solution so people keep trying graph db’s.
- rektide 5y ago
  > 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.
- jshen 5y ago
  They are great for data exploration, data science, analytics, etc. I would NOT put one as a dependency on a user experience though.
im_down_w_otp 5y ago
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?

tschellenbach 5y ago

I also don't see many valid use cases for graph databases.

freewilly1040 5y ago
Marketing and fraud detection are pretty valid imo. Just inherently hard to scale. 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.
tejtm 5y ago
Have you tried getting grants promising they will deliver? </s>
alexott 5y ago
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
- pphysch 5y ago
  2-3 hops (JOINs) is well within RDBMS territory, no?
  - freewilly1040 5y ago
    Yes. But it’s not a very exciting solution so people keep trying graph db’s.
rektide 5y ago
> 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.
jshen 5y ago
They are great for data exploration, data science, analytics, etc. I would NOT put one as a dependency on a user experience though.

im_down_w_otp 5y ago

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?