Looking over these
On Sat, Jul 30, 2011 at 1:42 PM, John cyuczieekc <[email protected]>wrote:
> those got concatenated for some reason, I'll repost them here so I can see
> them
>
> Relatationship:
> To associated Node: RelId -> NodeId
> From associated Node: NodeId -> RelId
>
> RelationshipType:
> To associated Node: RelationhipType.name -> NodeId
> From associated Node: NodeId -> RelationshipType.name;
>
> here, this may indeed be faster as you said it ('cause it doesn't require
double lookup in both Relationship: and RelationshipType: above); but I
wondering if it's more neatly if RelationshipType: here would be:
Relid <-> RelationshipType
expanding this notation as:
To associated Relid: RelationshipType -> Relid
>From associated Relid: Relid -> RelationshipType
the logic would be, if you have the start node, you can get the Relid (via
"Relationship:" above) then you can get the RelationshipType
and if you have RelationshipType you can get all Relids of that type, and by
having those, you can lookup the nodes that form them in the "Relationship:"
above
but of course the way you said it it's faster I guess, I don't suppose
lookup by name would be slower by much compared to lookup by long/id
and XA transactions or any transactions, would make sure Relationship: is
consistent with RelationshipType: anyway.
I should probably be thinking/doing about other things, this seemed useless
> RelationshipRole:
> To associated Node: RelationhipRole.name -> NodeId
> From associated Node: NodeId -> RelationshipRole.name;
>
> PropertyType:
> To associated Node: PropertyType.name -> NodeId
> From associated Node: NodeId -> PropertyType.name;
>
> Property:
> To associated Node: Node, PropertyType.name -> NodeId
> From associated Node: NodeId -> Node, PropertyType.name
>
> On Fri, Jul 29, 2011 at 5:27 PM, Niels Hoogeveen <
> [email protected]> wrote:
>
>>
>> What I need to store in an index depends on the type of element that needs
>> to be reified.
>> Relatationship:
>> To associated Node: RelId -> NodeIdFrom associated Node: NodeId -> RelId
>> RelationshipType:
>> To associated Node: RelationhipType.name -> NodeIdFrom associated Node:
>> NodeId -> RelationshipType.name;
>> RelationshipRole:To associated Node: RelationhipRole.name -> NodeIdFrom
>> associated Node: NodeId -> RelationshipRole.name;
>> PropertyType:To associated Node: PropertyType.name -> NodeIdFrom
>> associated Node: NodeId -> PropertyType.name;
>> Property:To associated Node: Node, PropertyType.name -> NodeIdFrom
>> associated Node: NodeId -> Node, PropertyType.name
>> Niels
>> > Date: Fri, 29 Jul 2011 06:49:31 +0200
>> > From: [email protected]
>> > To: [email protected]
>> > Subject: Re: [Neo4j] bdb-index
>> >
>> > 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
>>
>> _______________________________________________
>> Neo4j mailing list
>> [email protected]
>> https://lists.neo4j.org/mailman/listinfo/user
>>
>
>
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
