Re: [orientdb] Traversal Response Times

[Luigi Dell'Aquila]

Hi Eric,

In a schemaless/mixed schema it's hard to make assumptions, but something
can be optimized of course.
Probably the big part of the difference is due to the number of traversed
edges (N at the first level, NxN at the second, probably), but part of that
can also be due to internal mechanisms of the ODocument structure (eg.
management of reference trees for save) that in this case could be avoided.
We'll do some profiling on this, I'll let you know

Thanks

Luigi


2016-11-30 16:05 GMT+01:00 Eric24 :

> @Luigi--
> Hmmm. If the difference between traverse out('MyEdge') and
> out('MyEdge').out('MyEdge') is 100X, that sounds like an opportunity for an
> internal optimization. Unless there are dozens of other edges beyond the
> first level in this schema, it seems that the query optimizer could figure
> this out up-front. Thoughts?
> --Eric
>
> On Tuesday, November 29, 2016 at 12:39:37 PM UTC-6, Tomas Aftalion wrote:
>>
>>
>> Thank you Luigi, it did help. Also, when using directly, for example,
>> out('MyEdge').out('MyEdge') speeds things up considerably ~100x.
>>
>> Best,
>> Tomas
>>
>>>
>>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Traversal Response Times

[Eric24]

@Luigi--
Hmmm. If the difference between traverse out('MyEdge') and 
out('MyEdge').out('MyEdge') is 100X, that sounds like an opportunity for an 
internal optimization. Unless there are dozens of other edges beyond the 
first level in this schema, it seems that the query optimizer could figure 
this out up-front. Thoughts?
--Eric

On Tuesday, November 29, 2016 at 12:39:37 PM UTC-6, Tomas Aftalion wrote:
>
>
> Thank you Luigi, it did help. Also, when using directly, for example, 
> out('MyEdge').out('MyEdge') speeds things up considerably ~100x.
>
> Best,
> Tomas
>
>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Traversal Response Times

[Tomas Aftalion]

Thank you Luigi, it did help. Also, when using directly, for example, 
out('MyEdge').out('MyEdge') speeds things up considerably ~100x.

Best,
Tomas

On Monday, November 28, 2016 at 11:05:39 PM UTC-8, Luigi Dell'Aquila wrote:
>
> Hi Tomas,
>
> Try to replace WHILE $depth <= 2 with MAXDEPTH 2
> You should see an important improvement. The difference is that with WHILE 
> condition the TRAVERSE also does the 3rd level traversal and then checks 
> the condition, while with a MAXDEPTH it just stops at the specified level.
>
> Thanks
>
> Luigi
>
> 2016-11-28 21:25 GMT+01:00 Tomas Aftalion  >:
>
>> Hi,
>>
>> I've recently set up a db with 500K nodes and 16M edges (distributed, 2 
>> instances on aws, ubuntu 16, java 8, version 2.2.13). I'm running:
>>
>> select count(*) from (traverse out('MyEdge') from (SELECT FROM MyVertex 
>> WHERE id =  ) while $depth <= 2) where $depth >= 1
>>
>> and can take anywhere in the 1-60 second range, average around 10 
>> seconds. This coincides with a power law social graph structure ranging 
>> from 0-500 edges per node.
>>
>> Roughly speaking, what performance would you expect from this sort of 
>> graph? Is there something definitely wrong in my configuration that would 
>> cause these response times or is it a not so unexpected behavior?
>> I will be fetching and aggregating data from nodes at 1,2 and 3 degrees 
>> (to generate ego network features, for example average/max/min age at 2nd 
>> degree) and was hoping to have responses within a 0-5 second response time. 
>> Any help/suggestions?
>>
>> Thanks in advance,
>> Tomas
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OrientDB" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to orient-databa...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Traversal Response Times

[Luigi Dell'Aquila]

Hi Tomas,

Try to replace WHILE $depth <= 2 with MAXDEPTH 2
You should see an important improvement. The difference is that with WHILE
condition the TRAVERSE also does the 3rd level traversal and then checks
the condition, while with a MAXDEPTH it just stops at the specified level.

Thanks

Luigi

2016-11-28 21:25 GMT+01:00 Tomas Aftalion :

> Hi,
>
> I've recently set up a db with 500K nodes and 16M edges (distributed, 2
> instances on aws, ubuntu 16, java 8, version 2.2.13). I'm running:
>
> select count(*) from (traverse out('MyEdge') from (SELECT FROM MyVertex
> WHERE id =  ) while $depth <= 2) where $depth >= 1
>
> and can take anywhere in the 1-60 second range, average around 10 seconds.
> This coincides with a power law social graph structure ranging from 0-500
> edges per node.
>
> Roughly speaking, what performance would you expect from this sort of
> graph? Is there something definitely wrong in my configuration that would
> cause these response times or is it a not so unexpected behavior?
> I will be fetching and aggregating data from nodes at 1,2 and 3 degrees
> (to generate ego network features, for example average/max/min age at 2nd
> degree) and was hoping to have responses within a 0-5 second response time.
> Any help/suggestions?
>
> Thanks in advance,
> Tomas
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Traversal Response Times

[Tomas Aftalion]

Hi,

I've recently set up a db with 500K nodes and 16M edges (distributed, 2 
instances on aws, ubuntu 16, java 8, version 2.2.13). I'm running:

select count(*) from (traverse out('MyEdge') from (SELECT FROM MyVertex 
WHERE id =  ) while $depth <= 2) where $depth >= 1

and can take anywhere in the 1-60 second range, average around 10 seconds. 
This coincides with a power law social graph structure ranging from 0-500 
edges per node.

Roughly speaking, what performance would you expect from this sort of 
graph? Is there something definitely wrong in my configuration that would 
cause these response times or is it a not so unexpected behavior?
I will be fetching and aggregating data from nodes at 1,2 and 3 degrees (to 
generate ego network features, for example average/max/min age at 2nd 
degree) and was hoping to have responses within a 0-5 second response time. 
Any help/suggestions?

Thanks in advance,
Tomas

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.