Hi, by using the graph api you always have edges as bidirectional links. And in your case you can cross from Author to Posts that is the opposite direction you're creating with such "create link" command.
If you create: create link posts from BlogPost.authorID to Author.login inverse You could execute select login, posts.size() from Author where sex = "m" Lvc@ On 21 February 2014 18:41, Nicolas Clairon <[email protected]> wrote: > Thanks Lvc@ for your replay > > Actually, in my example, blog wasn't really needed (my bad) : it is a > single relation between Author and BlogPost. So here, the edge is not the > BlogPost but just an 'edge'. > > By the way, I used your example and I get an error: > > Error: > com.orientechnologies.orient.enterprise.channel.binary.OResponseProcessingException: > Exception during response processing. > > Error: com.orientechnologies.orient.core.exception.ODatabaseException: > Error during query execution > > Error: com.orientechnologies.orient.core.exception.ODatabaseException: > Error on saving record in cluster #11 > > Error: java.lang.NullPointerException > > I'll see what's going on and try to load the whole graph to see how it > goes... > > But I'd like to come back with the document storage.Why should I use graph > instead of document ? I was told that Document storage are faster than > graph. Is there any advices to speed up the query ? I thought that LINK > are fast. I created them via the command: > > create link author from BlogPost.authorID to Author.login > > Did I made a mistake ? > > Thanks a lot. > > On Friday, February 21, 2014 12:46:37 PM UTC+1, Lvc@ wrote: > >> Hi Nicolas, >> you've used a "Relational approach". My suggestion is to use the Graph >> Design in this way: >> >> create class Author extends V >> create class Blog extends V >> create class BlogPost extends E >> >> Author and Blog are vertices while BlogPost is an Edge >> >> Then populate your database using some API or direct SQL like: >> >> create vertex Author set login = 'luca', sex = 'm' >> ... >> create vertex Blog set id = 'lucasblog', title = "Luca's Blog" >> ... >> create edge BlogPost from ( select from Author where login = 'luca' ) to >> ( select from Blog where id = 'lucasblog' ) set id = 'test', title = 'Super >> Test' >> >> Then this would be the query: >> >> select login, out('BlogPost').size() from Author where sex = "m" >> >> To have more performance you could create an index against sex: >> >> create property Author.sex string >> create index Author.sex notunique >> >> And retry the same query: >> >> select login, out('BlogPost').size() from Author where sex = "m" >> >> Lvc@ >> >> >> >> >> On 21 February 2014 12:11, Nicolas Clairon <[email protected]> wrote: >> >>> Hi, >>> >>> I made a little benchmark of OrientDB with the following data: >>> >>> 1000 authors >>> 10000 blogs >>> 100000 blogposts >>> >>> the data made for the bench was loaded in the documents database. >>> >>> Here's the schema: >>> >>> author: { >>> '@class':'Author' >>> login: string >>> sex: string // 'f' or 'm' >>> } >>> >>> blog: { >>> '@class':'Blog' >>> id: string >>> title: string >>> } >>> >>> blogpost: { >>> '@class':'BlogPost' >>> id: string >>> title: string >>> authorID: string >>> blogID: string >>> } >>> >>> blogpost has a LINK to author and blog. >>> >>> The query is simple: >>> >>> 'select author.login, count(*) from BlogPost where author.sex = "m" >>> group by author.login' >>> >>> but it takes 3.782 seconds to complete on a MacBook air 2013 (SSD and >>> 8Go of RAM). >>> >>> In comparison, the triplestore Virtuoso performs the same query in 34ms >>> (!) on the same machine. >>> >>> I made some indexes in Author.login (unique) and Author.sex (not unique) >>> without luck... >>> >>> Is there any hints to know to make OrientDB faster for aggregation ? >>> >>> Thanks. >>> >>> N. >>> >>> -- >>> >>> --- >>> 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/groups/opt_out. >>> >> >> -- > > --- > 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/groups/opt_out. > -- --- 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/groups/opt_out.
