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] <javascript:>
> > 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] <javascript:>.
>> 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.
