Op woensdag 4 juni 2014 16:02:21 UTC+2 schreef Lvc@:
>
>
> On 4 June 2014 14:17, Wouter de Vaal <[email protected] <javascript:>>
> wrote:
>
>> So that is already much better (result is about 500 edges), but when
>> counting on more hits, things are still not fast:
>>
>> orientdb {petshop}> select
>> in('SUPP_COUNTRY').in('ARTICLE_SUPP_NR')[email protected]() from COUNTRY where _id
>> = 'NL'
>>
>> ----+-----+-----
>> # |@RID |in
>> ----+-----+-----
>> 0 |#-2:1|79918
>> ----+-----+-----
>>
>> 1 item(s) found. Query executed in 1.873 sec(s).
>>
>> Running a second time gives 0.558 sec, is there a warmup or something?
>>
>> 2nd time is faster because some records are already in cache. Why did you
> select @rid? Can you try:
>
>
> *select in('SUPP_COUNTRY').in('ARTICLE_SUPP_NR').size() from COUNTRY where
> _id = 'NL' *
>
When I do that, the result is somehow incorrect:
select in('SUPP_COUNTRY').in('ARTICLE_SUPP_NR').size() from COUNTRY where
_id = 'NL'
----+-----+----
# |@RID |in
----+-----+----
0 |#-2:1|4787
----+-----+----
1 item(s) found. Query executed in 0.033 sec(s).
Another use case we have is that we now also want to sort the result, which I
tried with:
>>
>> select from (select expand(in('SUPP_COUNTRY').in('ARTICLE_SUPP_NR')) from
>> COUNTRY where _id = 'NL') order by ARTICLE_WEIGHT desc
>> 20 item(s) found. Query executed in 2.243 sec(s).
>>
>> So this is again slow, are there any hints on how a query like this
>> should be formed to be fast?
>>
>
> In this case al the items are retrieved, then ordered, so the limit
> applies at the end. How many fields have the Article records?
>
In my current test setup I mostly have relations, and only a few fields,
but this case should become about 50 fields:
orientdb {petshop}> select from (select
expand(in('SUPP_COUNTRY').in('ARTICLE_SUPP_NR')) from COUNTRY where _id =
'NL') order by ARTICLE_WEIGHT desc
----+--------+------------+-------------+---------------+----------------+----------------+----------------+----------------+----------------
# |@RID
|ARTICLE_WEIG|out_ARTICLE_V|out_ARTICLE_BRA|out_ARTICLE_ARTG|out_ARTICLE_ARTS|CREATED_BY
|out_ARTICLE_ARTS|out_ARTICLE_SUPP
----+--------+------------+-------------+---------------+----------------+----------------+----------------+----------------+----------------
0 |#9:27827|4.0165986...|#12:1 |#17:91 |#10:17
|#18:13 |admin@vrm... |#19:32 |#13:123
1 |#9:16145|171647.0 |#12:1 |#17:95 |#10:15
|#18:7 |admin@vrm... |#19:19 |#13:19
The number of records it needs to go through is about 80K, so it is
understandable it is slow, so that's why I am wondering if there is another
way to do some combining query for sorting and querying/traversing.
>
>
>> Thanks,
>> Wouter
>>
>>
>> Op maandag 2 juni 2014 14:03:12 UTC+2 schreef Wouter de Vaal:
>>
>>> Hi,
>>>
>>> I am evaluating OrientDB for use in our product to see if our specific
>>> requirements fit the performance of OrientDB.
>>>
>>> In general we have tables with potential quite a lot record with per row
>>> possibly a few relations to other records in another class, which can have
>>> relations to another class etc. Simply put a classical SQL style table, but
>>> customizable by our users, so we cannot exactly predict how the structure
>>> will be, be we have some ideas.
>>>
>>> For now I have created a class ARTICLE, SUPP and COUNTRY. Goal is to
>>> find articles with a supplier from a specific country. The query I used was
>>> very fast (nice!):
>>>
>>> select * from ARTICLE where out_ARTICLE_SUPP_NR.out_SUPP_COUNTRY._id =
>>> 'GB'
>>> ...
>>> 20 item(s) found. Query executed in 0.14 sec(s).
>>>
>>> But when I want the total count (which I need to calculated the number
>>> of pages for this query), the count is very slow:
>>>
>>> select count(*) from article where out_ARTICLE_SUPP_NR.out_SUPP_COUNTRY._id
>>> = 'GB'
>>> ...
>>> 1 item(s) found. Query executed in 4.084 sec(s).
>>>
>>> Our article table has approx 90000 records, suppliers have 528 and
>>> countries has 9.
>>> I have not yet created any indexes.
>>>
>>> Is there a way to speed up the count query?
>>>
>>> Regards,
>>> Wouter
>>>
>> --
>>
>> ---
>> 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.
