See this issue (https://github.com/orientechnologies/orientdb/issues/4105) and the associated code (https://github.com/wcraigtrader/ogp/tree/indexes) for examples of performance with and without indexing edges.
In short, if you're not using indexes on edges, then attempting to find a specific edge from a given node will involve a linear search through all of the edges attached to the node. - Craig - On Tue, May 12, 2015 at 10:45 AM, <[email protected]> wrote: > Hi, > > Can you please elaborate on this. > > As far as I know the edges can not be indexed based on > outgoing-vertex-properties. > In this case the edges have no properties and could be light weight. > > Regards, > -Stefan > > Regards, > -Stefán > > On Tuesday, 12 May 2015 13:14:12 UTC, l.garulli wrote: >> >> Hi all, >> I confirm that indexing the edges is the only way to have a O(1)-O(LogN) >> time. Once indexed you can start from edges and get in/out vertices. >> >> >> Best Regards, >> >> Luca Garulli >> CEO at Orient Technologies LTD >> the Company behind OrientDB >> http://about.me/luca.garulli >> >> >> On 12 May 2015 at 12:47, <[email protected]> wrote: >> >>> Hi, >>> >>> That is not applicable. Any "where clause" would demand the graph to >>> visit all edges-vertexes even when looking for the newest 100 (to look up >>> for the remote property). >>> When there are 1 million+ edges that takes a very long time and is not >>> acceptable. >>> >>> Thanks for playing! >>> >>> regards, >>> -Stefan >>> >>> >>> On Tuesday, 12 May 2015 07:54:03 UTC, Izzet Pembeci wrote: >>>> >>>> select out('ACTOR')[79220,79221,79222,79223,79224,79225,79226,79227, >>>> 79228,79229,79230] from #140:0 >>>> >>>> Can you transform the above query to something like: >>>> >>>> select out('ACTOR') from #140:0 WHERE ... >>>> >>>> >>>> If this works in a faster way, one may conclude that implementation of >>>> [] has some performance problems. I also think that with your reasonable >>>> bumps you earned yourself the right to open an issue on this one. >>>> >>>> iZzeT >>>> >>>> >>>> On Monday, May 11, 2015 at 2:21:27 AM UTC+3, [email protected] >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I do believe that in this case neither are applicable. >>>>> I think the ridbag offers only traversal (not fetching by positions >>>>> directly) and the edge has not property to index by (it's on the outgoing >>>>> vertex). >>>>> >>>>> Regards, >>>>> -Stefan >>>>> >>>>> On Sunday, 10 May 2015 15:25:18 UTC, Ziink A wrote: >>>>>> >>>>>> I'm still evaluating OrientDB so I might be totally off but I would >>>>>> index the edge class (SOME_LABEL). >>>>>> >>>>>> Also take a look at http://orientdb.com/docs/last/RidBag.html >>>>>> >>>>>> >>>>>> On Thursday, April 30, 2015 at 4:27:40 AM UTC-7, >>>>>> [email protected] wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have very dense graph that contains vertexes with a lot of edges >>>>>>> and I need to fetch the X last edges added to the Vertex. >>>>>>> >>>>>>> Orient SQL allows me to do it like this: >>>>>>> >>>>>>> - select out('SOME_LABEL')[80000] from #1:0 >>>>>>> - please note that this is single direction (out) and a single >>>>>>> link type / label ('SOME_LABEL') >>>>>>> >>>>>>> I have several questions regarding this: >>>>>>> >>>>>>> - Are the edges in a consistent order? >>>>>>> - Assuming append-only operations and no deletions >>>>>>> >>>>>>> - Can anything be done to speed this up? >>>>>>> - I ask because this query is very slow (0.7 sec.) >>>>>>> - Asking for a list "select >>>>>>> >>>>>>> out('ACTOR')[79220,79221,79222,79223,79224,79225,79226,79227,79228,79229,79230] >>>>>>> from #140:0" takes almost n*req_time longer >>>>>>> >>>>>>> - What happens underneath (is the whole list iterated from top >>>>>>> to get to this) >>>>>>> >>>>>>> - Can this be achieved using the Java API? >>>>>>> >>>>>>> Assistance is highly appreciated. >>>>>>> >>>>>>> Best regards, >>>>>>> -Stefan >>>>>>> >>>>>> -- >>> >>> --- >>> 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
