Op woensdag 4 juni 2014 16:10:26 UTC+2 schreef Wouter de Vaal: > > > > Op woensdag 4 juni 2014 16:02:21 UTC+2 schreef Lvc@: >> >> >> On 4 June 2014 14:17, Wouter de Vaal <[email protected]> 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. > > Somebody any ideas? I guess what I am after is: is it possible that when traversing from the Country class via the Supplier class into the Article class, that it then uses the Article index for sorting or filtering Article data. Is this possible? Other options to have such queries with a good speed?
> >> >> >>> 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]. >>> 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.
