1

I have to choose a graph database system and am very surprised that the mainstream ones don't support this feature ?

Why is it such a no-go for database systems ? And why developers out there don't seem to ask for it ? There should be a reason I'm not aware of.

Thanks for your help.

snwfdhmp
  • 360
  • 2
  • 11
  • 1
    Can you please provide some examples of which databases you are referring to? The databases I am thinking of DSE Graph, JanusGraph, Neo4j, OrientDB, etc. all support directed edges but allow you to traverse them in either direction. They also allow you to create bidirectional edges by adding two edges, one from A -> B and one from B -> A – bechbd Apr 09 '19 at 02:04
  • @bechbd I can't find any database implementing **bidirectional** edges. Creating two unidirectional edges A->B and B->A is not the same as bidirectional edges. I don't want to double the amount of edges for being able to traverse in either direction. I tried Dgraph and Neo4j and didn't find anything for creating a unidirectional edge and being able to traverse it in either direction. My point is to create the edge "friendship" between "you" and "me" and be able to traverse it in both directions, without having to double the amount of (i) edge creation requests (ii) storage size. – snwfdhmp Aug 09 '19 at 03:40
  • 1
    Both Neo4j and DGraph support traversing edges in both directions as do most other data bases. In any TinkerPop enabled database this is done via in the in() and out() steps g.V().has('person', 'name', 'you').out('friendship') and g.V().has('person', 'name', 'friend').in('friendship'). In Cypher you do this by switching the direction of the arrows MATCH (you)-[:friendship]->(friend) RETURN you.name, friend.name or by changing the arrow direction MATCH (friend)<-[:friendship]-(you) RETURN you.name, friend.name – bechbd Aug 18 '19 at 03:43
  • Objectivity/DB is both an object-oriented database and graph database and its schema model supports both uni-directional and bi-directional edges. It also supports edge objects (where you can put attributes on your edges). The database also handles edge consistency for you (i.e. when you delete an object both ends of the bi-directional relationships are cleaned up). – djhallx Oct 17 '19 at 19:02

1 Answers1

2

To my understanding, a "pure" bidirectional graph database cannot support cases where there are also unidirectional relationship, Twitter for example.

So the question becomes "why there are no hybrid (bidirectional and unidirectional) graph databases?" There are two problems with this solution:

  1. It might not save storage as you expected because for bidirectional relationship, a hybrid graph database would need to store three edges instead of just one: A -> B, B -> A, and A <-> B. The reason is that some very common queries involve unidirectional relationship.

  2. The cost of some basic queries is rather high. For example, there are two frequently asked questions in graph databases:

    • Find all friends of A

    • Find all friends of B

Commonly a graph database saves all friends of A as edges adjacent (AB, AC, AD, …). To find all of A's friends they just need to locate A and skim to the first edge whose prefix is not A. Suppose A has m friends and there are n. records in database in total, then the query complexity is O(log(n)) + O(m). The same logic applies to B. However, in case bidirectional edge is used, say A<->B, the cost of query for A's friends is the same but query for B's friends would be O(n) because a full database scan is required.

venegr
  • 148
  • 8
  • 1
    Thank you ! It's much clearer now. I understand that bidirectional edges look good in theory but are costly to implement. – snwfdhmp May 31 '20 at 08:08