Hi Luca Yes the project will be released as open source; I'll keep you updated of it if you like (and of any publication citing OrientDB).
Concerning my problem, I'm not sure whether your suggestion matches my case; I thinks there are a couple of more problems: - the tag property is not unique - I have to filter by an attribute of the edge (in my post I wrote "vertices of type X" but actually I should have written "vertices, that are source of edges of type X") In practice, the structure of the database is like this: Node(tag="Project1")#2:1 ---Contains(type="partially")---> Node(tag="Component1")#1:1 Node(tag="Project2")#2:2 ---Contains(type="totally")---> Node(tag="Component1")#1:2 Node(tag="Project3")#2:3 ---Contains(type="totally")---> Node(tag="Component1")#1:1 Node(tag="Project1")#2:1 ---Contains(type="partially")---> Node(tag="Component2")#1:3 What I have is: - a reference to #1:1 - the type "partially" - the edge class "Contains" and I need to select "Project1" and any other Node which "Contains" "partially" #1:1 So considering all of this, 50 millis could be good, I don't know how others db would behave in the same condition; but if there is a magic solution to do it faster it would be better for me :-) Alberto On Monday, June 15, 2015 at 4:58:22 PM UTC+2, l.garulli wrote: > > Hi Maverick, > Cool. Does the project will be open source? > > About your query, the proper way is to query the vertex by property > (assure an index is on "tag") and then start crossing the graph. Example > (assuming the Vertex class was N): > > select expand( in() ) from (select from N where tag='ras') > Let me know the new times ;-) > > > Best Regards, > > Luca Garulli > CEO at Orient Technologies LTD > the Company behind OrientDB <http://orientdb.com> > > On 15 June 2015 at 16:32, Maverick <[email protected] <javascript:>> > wrote: > >> Hi >> >> >> I'm using an OrientDB graph database in an EU-funded FP7 project to >> support data-based AI risk analysis algorithms. >> >> >> In each algorithm, I frequently (e.g., 40-50 times in a single algorithm) >> need to get "all the vertices of type X, outgoing from N", or "all the >> vertices of type X, incoming into N" >> >> >> To do this, I use queries such as these: >> >> >> select expand( inV() ) from (select from ChildOf where #11:0=out and >> in.tag='ras') >> >> select expand( outV() ) from (select from Link where #12:1898=in and >> name='layer-entity') >> >> >> The problem is that a single query like this takes ~0.5 seconds (50 >> millis), and this means that when in the database there are a few tens of >> records, the time of some algorithms goes quickly to the tens of seconds, >> which makes them unusable. >> >> >> I've pushed to adopt OrientDB for its "conceptual" beauty, but I never >> ran into this kind of hard speed requirements. >> >> Is this time normal for what I'm doing? What should I check and what >> could I do differently (apart from changing the whole logic behind the >> algorithms)? >> >> >> Thank you for any suggestion >> >> -- >> >> --- >> 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] <javascript:>. >> 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.
