Hey Nikolay,
So this is an interesting query: the thing that stands out the most to me
is that this query isn't doing anything with relationships - it's not
taking advantage of the graph. So all that's left for Neo4j to do is to
begrudgingly walk through every single Book and put them in order for you.
Over and over. That's not going to be very fun for it, and it's not going
to do it any better than a relational db (which loves these long, boring
walks).
If you want to really let the graph shine, consider ways you can use
relationships to relate nodes together - and then query on those. Then
you'll get some of that awesome graph speediness.
Cheers,
Chris
On Tuesday, March 4, 2014 12:02:38 PM UTC-8, Nikolay Artamonov wrote:
>
> Hi guys! )
>
> My graph consists nodes labeled as :Book. In application I have to present
> table of books in paged manner and with sorting capabilities by various
> properties, for example:
>
> MATCH (b:Book) RETURN b ORDER BY *b.isbn* SKIP {offset} LIMIT {
> booksPerPage}
> MATCH (b:Book) RETURN b ORDER BY *b.title* SKIP {offset} LIMIT {
> booksPerPage}
> MATCH (b:Book) RETURN b ORDER BY *b.pubDate* SKIP {offset} LIMIT {
> booksPerPage}
> // ... and so on...
>
>
> It is supposed to have very much books (100,000 and more).
>
> Questions:
>
> 1. Does execution of previous queries imply loading ALL books in memory
> and linear processing for further ordering?
> 2. What can I do to decrease memory consumption and performance of
> execution of such queries in Neo4j 2.0/2.1? (indexing or something else)
> 3. What is planned to improve this situation in future releases of Neo4j?
>
> I really loved Neo4j and graph databases and I don't want to switch back
> to RDBMS just to resolve data access pattern described above.
>
> Thanks!
>
--
You received this message because you are subscribed to the Google Groups
"Neo4j" 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.
