Hi Bryce, Sorry for my belated response. I have been away for a couple of days and wasn't able to check my emails. I am glad you took the time to look into the IndexRelationship module. It certainly could use some scrutiny. Remarks: 1) Good catch... Something the unit test didn't catch because it runs in the same namespace as IndexedRelationship itself. Didn't catch it in user code either, because personally I prefer to directly call SortedTree. 2) Agreed. It should be possible to define more than one IndexRelationship per node. 3) I haven't tried out an anonymous inner class as Comparator. As far as I can tell any object implementing Comparator<Node> should be able to work as a comparator.
Questions: 1) That is certainly an option. IndexRelationships however offer you the possibility to sort your Relationships based on some value associated with a node (for example creation/edit date of the document). This may be a reason to use IndexRelationships even in the situation where you have less than 500 entries per tag (though it would be possible to do that sorting in memory too). 2) The end node of an IndexRelationship is always referred to by a Relationship with RelationshipType "KEY_VALUE", and has a property "tree_name" (both are defined in SortedTree). The "tree_name" property has the same value as the RelationshipType.name used in IndexRelationship. To traverse from a leaf node to the tree root, keep following the incoming relationships: KEY_VALUE (there is only one), KEY_ENTRY (there can be many), SUB_TREE (there can be many), TREE_ROOT (there is only one) Niels > Date: Fri, 2 Sep 2011 11:44:40 +1200 > From: [email protected] > To: [email protected] > Subject: [Neo4j] IndexedRelationship some observations and questions > > Hi, > > I have been looking at performance options for Neo4j as presently I have > been observing a number of performance issues. I am still investigating the > way to get the best performance out of what I am doing, and one thing it > might be are longer running transactions stopping other work going on (but > thats an aside to what this message is about). > > One of the things that I investigated using was the IndexedRelationship work > by Niels. Thought I would give a bit of feedback, although I haven't quite > got this implemented at present. > > 1) I had to change the IndexedRelationshipExpander to be a public class in > order to use it outside the package its in. > > 2) IndexedRelationship assumes only one tree root per node, whereas the > expander allows for multiple (IndexedRelationship uses getSingleRelationship > vs expander using getRelationships then matching on tree name). Having > multiple would obviously be good as it means you could have two types of > relationships covered by IndexedRelationship's. > > 3) Might pay to make it clear in the Javadocs for IndexedRelationship that > the comparator can't be an anonymous inner class. > > Then I have some questions about usage of this. First a little background > of the model I have, from reading a few things it seems quite standard. > There are a lot of "document" nodes each of which have a relationship with > multiple "tag" nodes. Documents generally have in the order of 10-20 tags, > and tags can have as few as 1 document and sometimes tens of thousands. > When tags are viewed through the UI they are almost always displayed with a > descending date ordered list of documents. Seemed to be to fit quite well > with IndexedRelationship. > > 1) I was thinking of having a switch over point at say around 500 documents > for a given node where I will switch from using normal relationships to an > IndexedRelationship as I was thinking at small numbers of relationships > normal relationships would be quicker. Would that be correct, or not worth > it? > > 2) On the tag end (which is the incoming end of the document-tag > relationship) I was going to use a IndexedRelationshipExpander which would > cover the case of whether the relationship was done through normal > relationships, or through an IndexedRelationship. I also need to get a set > of tags from the document end where their may be both normal relationships, > and relationships coming from multiple IndexedRelationship's. From looking > at it IndexedRelationshipExpander doesn't cover the reverse direction, but I > would imagine using a relationship expander here would be correct. What > would the best way of doing this be? > > As an aside it may be a good idea to note in the configuration settings > page: > http://wiki.neo4j.org/content/Configuration_Settings#Optimizing_for_traversals_example > that -XX:+UseNUMA > only works when using the Parallel Scavenger garbage collector (default > or -XX:+UseParallelGC) not the concurrent mark and sweep one. Based on > > Cheers > Bryce > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
