: user@lists.neo4j.org
> Date: Fri, 1 Jul 2011 15:24:03 +0200
> Subject: Re: [Neo4j] traversing densely populated nodes
>
>
> I delved a bit deeper into the BTree implementation in graph-collections and
> learned that it is essentially a tree based version of a property containe
nsert times.
Niels
Niels
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Fri, 1 Jul 2011 02:06:24 +0200
> Subject: Re: [Neo4j] traversing densely populated nodes
>
>
> So far we have only considered the situation where one side of the
> relationship
ized correctly by users & especially API makers (eg I
really need to hint TinkerPop Pipes/Gremlin to use this relationship
indexing when I do a v(1).outE('HAS_PART') ).
Agelos
Date: Thu, 30 Jun 2011 22:56:22 +0200
From: Michael Hunger
Subject: Re: [Neo4j] traversing densely populat
be traversed transitively are marked with a *
Niels
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Fri, 1 Jul 2011 00:36:32 +0200
> Subject: Re: [Neo4j] traversing densely populated nodes
>
>
> The relationship expander approach could certainly work for
acts. The inverse of the node id is equally
unique, but has a nicer distribution, making inserts into the Btree probably a
bit faster.
Niels
> Date: Thu, 30 Jun 2011 23:50:24 +0200
> From: cr...@amanzi.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] traversing densely pop
nted now is not thread safe (per the implementations Javadocs),
> so it need some love and attention to make it work properly.
> Niels
>
> > Date: Thu, 30 Jun 2011 13:57:20 +0200
> > From: cr...@amanzi.com
> > To: user@lists.neo4j.org
> > Subject: Re: [Neo4j] traversin
(per the implementations Javadocs), so it
need some love and attention to make it work properly.
Niels
> Date: Thu, 30 Jun 2011 13:57:20 +0200
> From: cr...@amanzi.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] traversing densely populated nodes
>
> This topics has come
tx.finish();
}
}
Am 30.06.2011 um 14:47 schrieb Niels Hoogeveen:
>
> Michael,
> Is it possible/feasible to change the store-format so relationships are
> stored partitioned per relationshiptype per direction? What would be the
> impact of such change?
> Niels
>
he
> impact of such change?
> Niels
>
>> From: michael.hun...@neotechnology.com
>> Date: Thu, 30 Jun 2011 14:10:38 +0200
>> To: user@lists.neo4j.org
>> Subject: Re: [Neo4j] traversing densely populated nodes
>>
>> The issue being that relationships on
neo4j.org
> Subject: Re: [Neo4j] traversing densely populated nodes
>
> The issue being that relationships on disk are not ordered, so that, even
> when just accessing the few relationships of the one
> type you still have to scan all rels.
>
> For supporting different approaches
t;
>> I just reported to Michael the runs with the latest M05 snapshot, which are
>> not very positive...
>> I have suggested an (auto) indexing of relationship types / direction that
>> is used by traversing frameworks,
>> but I ain't no graphdb-engine expert :-(
ameworks,
> but I ain't no graphdb-engine expert :-(
>
> A'
>
>
> Message: 5
> > Date: Wed, 29 Jun 2011 18:19:10 +0200
> > From: Niels Hoogeveen
> > Subject: Re: [Neo4j] traversing densely populated nodes
> > To:
> > Message-ID:
> >
...
> I have suggested an (auto) indexing of relationship types / direction that
> is used by traversing frameworks,
> but I ain't no graphdb-engine expert :-(
>
> A'
>
>
> Message: 5
>> Date: Wed, 29 Jun 2011 18:19:10 +0200
>> From: Niels Hoogeveen
&
iels Hoogeveen
> Subject: Re: [Neo4j] traversing densely populated nodes
> To:
> Message-ID:
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Michael,
>
>
>
> The issue I am refering to does not pertain to traversing many relations at
> once
recent addition,
and that's what I use the timeline index for).
Niels
> From: michael.hun...@neotechnology.com
> Date: Wed, 29 Jun 2011 17:50:08 +0200
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] traversing densely populated nodes
>
> I think this is the same
hips with another type and/or
> direction take a lot of time too.
> Niels
>
>> Date: Wed, 29 Jun 2011 16:36:57 +0200
>> From: ntausc...@gmail.com
>> To: user@lists.neo4j.org
>> Subject: Re: [Neo4j] traversing densely populated nodes
>>
>> I focused the
Hi,
In situations where there is a high degree vertex [
http://en.wikipedia.org/wiki/Degree_(graph_theory) ], I tend to do graph
sampling. That is, I do not traverse everything outgoing/incoming from the
vertex. For example, in Gremlin:
rand = new Random();
highDegreeVertex.out
s a lot of time. It doesn't
make intuitive sense that relationships with another type and/or direction take
a lot of time too.
Niels
> Date: Wed, 29 Jun 2011 16:36:57 +0200
> From: ntausc...@gmail.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] traversing densely populat
I focused the same problem. Nodes with a lot of relationships are very
difficult (needs a lot of time) to be traversed. I solved the problem by
grouping the relationships using additional nodes. The dense node then
has only a few relationships to different 'group' nodes. Each 'group'
node then has
Recently I have worked on loading the content of DbPedia into my database and
run into a performance issue.
My application has a meta-layer; inspired by the meta model component, but
rewritten in Scala.
All DbPedia resources are said to be an instance of "topic",
creating a relationship from th
20 matches
Mail list logo
