Perhaps as a concrete example of what Chris is describing here, I can
comment further.
The original example had three properties to order on, isbn, titel,
pubDate. The text 'and so on' implies more, but let's assume there are not
too many more. If there are indeed a limited number of predictable
parameters, then you can order once (in memory) during graph creation, and
create relationships to persist the order. For example, the ordered books
by isbn could have a structure like
(a)-[:next_by_isbn]->(b)-[:next_by_isbm]->(c)...
Paginating through this might be somewhat different than before, since you
would be searching along a chain. I tested this with a dataset I had, and
it works with a syntax like:
MATCH (n:Device {key:{value}}), p=(n)-[:next*]->(x) RETURN x,length(p) SKIP
{skip} LIMIT {limit}
The column 'x' contains the nodes in order. I returned length(p) also just
for interest, as it represents the global position in the chain.
Of course, a better option would be to remember the ID of the last entry,
and pass that as a starting node for the next, so the traversal does not
have to start at the beginning. Then each page would not need the skip
setting:
START n=node({prev_id}) MATCH p=(n)-[:next*]->(x) RETURN x,length(p) LIMIT
{limit}
This should perform better for long chains, like yours.
On Wed, Mar 5, 2014 at 7:19 PM, Chris Leishman <[email protected]> wrote:
> 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.
>
--
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.
