Sorry to reply to this old thread, but I'm actually facing the situation
you're describing at the end: having possibly many rels to traverse.
As you mentioned, the fix in 2.1 won't fix this and there is the workaround
you describe above or even, as Mark Needham and Cédric Fauvet told me, the
pos
Thanks Michael - I understood your workaround and see that it would work.
However, I wanted to confirm that neo4j does not have native ability to
filter quickly by relationship label? I just did some more testing using
the "profile" statement, and it looks like it is doing some native
filtering
Michael,
What do you mean by filter on the relationship type? I was under the
impression that all relationships for a node are in the same linked list
and there's no fast way to filter for the relationship type without
traversing through the whole linked list.
On Monday, January 6, 2014 5:43:
I have suffered from this issue and we have a few workarounds currently
that fit our data model.
I do not recommend indexing as a solution. We attempted to do this, and it
lead to GC problems as Lucene was create a lot of trash, so my high
performance query was spending a lot of time doing GC.
Jason,
The release is afaik planned either for some time in Q2 2014.
actually the workarounds are not so difficult.
The easiest one is to add a separate node which holds the 1M relationships. So
your actual node has just 1+100, the 100 that you mentioned of type 2 and the
one to the separate n
Michael,
This is a major performance bottleneck for me as I have nodes that may have
1M relationships of type 1, but only a hundred relationships of type 2.
Traversal performance for type 2 will be brought down due to the type 1
relationships. I've read through the archives and it seems like thi
This will be addressed in Neo4j 2.1 or 2.2 depending on the roadmap
What is your concrete use-case?
There are some ways to mitigate it manually for now depending on your use-cases
Eg introduce a hierarchy or a separate node for the large relationship-set
Or index certain rels that are important
Your understanding here is correct.
In your example: Given a node with 10E7 relationships and you want to know
if it is connected to node x. If you know that x has significant lesser
relationships you can reverse the traversal direction and check if x is
connected to a. This will be cheaper as only
I've been reading about Neo4j's internals and found it interesting that a
node's relationships are stored as a doubly linked list of relationships.
This seems to be ideal for traversing a graph with relatively few
relationships per node. It does not seem ideal for traversing when a single
node
