small obvious correction btw, it's not 2 primary databases, it's 1 primary and 1 secondary ;) my bad
On Fri, Jul 29, 2011 at 6:49 AM, John cyuczieekc <[email protected]>wrote: > 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
