Hi xD I'm not clear what you need to store here, if I understand correctly you could store in 2 primary bdb databases the nodeID (ie. long) of each node in a relationship ie. key->value
dbForward: A->B A->C X->D X->B dbBackward: B->A B->X C->A D->X A,B,C,D,X are all nodeIDs ie. longs this way you could check if A->B exists, or all of A's endNodes , or what startNodes are "pointing" to the endNode B the storing of these would be sorted and in BTree, lookup would be fast, so you can consider ie. A as being a set of B and C, and X being a set of B and D, (that is you cannot set the order as in a list, they are sorted by bdb for fast retrievals). (But upon this, sets, can build lists np - that is using only bdb; tho you won't need that using neo4j) So, if this is the kind of index you wanted... (I am not aware of specific indexes with bdb, though that doesn't mean they don't exist) Insertions would require transaction protection so both A->B in dbForward and B->A in dbBackward are inserted atomically. Parsing A then X of B-> in dbBackward for example can only be done with a cursor... Either way, I'm taking a look on that bdb-index thingy; will report back if I have any ideas heh John. On Thu, Jul 28, 2011 at 9:42 PM, Niels Hoogeveen <[email protected]>wrote: > > Thank you, Peter,There is no rush here. It would be nice to investigate > this option, but it can wait until Mattias has returned and sifted through > urgent matters. The question is even, if it would be a good idea to use an > index to do the book keeping for Enhanced API.As it is now, the Reification > of eg. a Relationship, requires one property to be set on a relationship, > containing the node ID of the associated node. On the associated node is a > property containing the ID of the relationship, so there is a bidirectional > look up. Introducing an index would remove the need to have these additional > properties, but would lead to slower look-up times (no matter how fast the > index).So it's a trade-off between speed and cleanliness of namespace. Using > the Enhanced API disallows certain property names to be used in user > applications.The property names used in Enhanced API all start with > "org.neo4j.collections.graphbd.", so there is little chance a user > application would want to use those property names, but it is a restriction > not found in the standard API, so ultimately something to consider.Niels > > From: [email protected] > > Date: Thu, 28 Jul 2011 10:39:47 -0700 > > To: [email protected] > > Subject: Re: [Neo4j] bdb-index > > > > niels, > > in this spike, I just concentrated on getting _something_ working in > > order to test insertion speed. This is not up to real indexing > > standards, so some love is needed here. I think Mattias is the best > > person to ask about pointers, let's wait until he is back next week if > > that is ok? Maybe some other (like the standard Lucene) index can > > suffice for the time being to test out things? > > > > Cheers, > > > > /peter neubauer > > > > GTalk: neubauer.peter > > Skype peter.neubauer > > Phone +46 704 106975 > > LinkedIn http://www.linkedin.com/in/neubauer > > Twitter http://twitter.com/peterneubauer > > > > http://www.neo4j.org - Your high performance graph > database. > > http://startupbootcamp.org/ - Öresund - Innovation happens HERE. > > http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. > > > > > > > > On Thu, Jul 28, 2011 at 10:36 AM, Niels Hoogeveen > > <[email protected]> wrote: > > > > > > Trying to find something useful to hide the implementation book keeping > of Enhanced API, I tried out dbd-index as can be found here: > https://github.com/peterneubauer/bdb-index > > > It looks interesting, but fails its tests. When recovering it performs > BerkeleyDbCommand#readCommand from the log. The retrieved indexName is not > actually garbage. I would like to help make this component workable, but > area of the database is a bit beyond the scope that I know. > > > I know this is completely unsupported software, but can someone give me > some pointers on how to fix this issue? > > > Niels > > > _______________________________________________ > > > Neo4j mailing list > > > [email protected] > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
