Hi Alberto. I'll try to give you some help.
First of all a index doesn't require the uniqueness of the property (
http://orientdb.com/docs/last/Indexes.html ). In your case I'd suggest
a NOTUNIQUE_HASH_INDEX.
I used this script to test some queries:
CREATE DATABASE memory:temp admin admin memory graph
INSERT INTO V set name = '21', tag = "Project1"
INSERT INTO V set name = '22', tag = "Project2"
INSERT INTO V set name = '23', tag = "Project3"
INSERT INTO V set name = '11', tag = "Component1"
INSERT INTO V set name = '12', tag = "Component1"
INSERT INTO V set name = '13', tag = "Component2"
CREATE CLASS Contains EXTENDS E
CREATE EDGE Contains FROM (SELECT FROM V WHERE name='21') TO (SELECT FROM V
WHERE name='11') SET type = 'partially'
CREATE EDGE Contains FROM (SELECT FROM V WHERE name='22') TO (SELECT FROM V
WHERE name='12') SET type = 'totally'
CREATE EDGE Contains FROM (SELECT FROM V WHERE name='23') TO (SELECT FROM V
WHERE name='11') SET type = 'totally'
CREATE EDGE Contains FROM (SELECT FROM V WHERE name='21') TO (SELECT FROM V
WHERE name='13') SET type = 'partially'
Starting from this, which is very similar to your case, the query you ask
is something like:
SELECT expand(inE('Contains')[type='partially'].outV())
FROM V
WHERE name = '11'
But if you have the @rid of vertex with name 11 (in my case #9:3) it's
simpler:
SELECT expand(inE('Contains')[type='partially'].outV())
FROM #9:3
Anyway I would also try to suggest you another model, which I think should
be more performant with Orient.
I think Orient works very well with classes and subclasses so everytime I'm
creating some attribute which reminds me a class (type, tag, ...) I ask
myself if it wouldn't be better creating a new class.
In your case can you create two subclass of Contains, for example:
ContainsPartially and ContainsTotally?
If you can reason in this way the query I proposed becomes easier:
SELECT expand(in('ContainsPartially'))
FROM #9:3
Please note that you can always write the query:
SELECT expand(in('Contains'))
FROM #9:3
Since class inheritance will do the magic for you.
Regarding efficiency this approach is very good, for two reasons:
- you can enable lightweight edges, which makes your database lighter
- you don't need indexes
Please note that lightweight edges require to avoid any property on edges,
if you need them you could always consider the edge subclassing solution.
Cheers,
Riccardo
P.S. I noticed you're from Trento as me. If you need more help we can meet
us in Povo. I'm also interested in real applications of OrientDB.
Il giorno lunedì 15 giugno 2015 18:28:30 UTC+2, Maverick ha scritto:
>
> 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]> 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].
>>> 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.
