jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: [jr3] Flat hierarchy
Date Mon, 22 Feb 2010 22:28:17 GMT

On 18 Feb 2010, at 13:04, Stefan Guggisberg wrote:

> On Wed, Feb 17, 2010 at 5:17 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> Hi,
>> This one's a quite frequently asked feature. Currently we store the
>> full list of child nodes in the same bundle or node state record with
>> the parent node. This makes it expensive to support nodes with large
>> amounts (>>1k) of child nodes.
> in my experience notable write-performance impacts start with >>10-20k
> child nodes ;)
> 10-20k is quite a lot IMO, most applications probably won't ever hit
> this 'limit'.

I am not arguing for flat hierarchies but I spend a lot of time persuading UX designers and
management that 100k or more child nodes in not acceptable in a hierarchical content system.

With an instance supporting 4M identified users with a unique user name, it hard to argue
that /home/<uid> is not acceptable when there are so many other systems that support
this. (we have modified the UserManager to scale)

> i agree that flat hierarchies is an important feature, however we
> shouldn't compromise
> the performance for the 'standard' case with less than 1k child nodes
> just for the sake
> of supporting flat hierarchies. after all, the JCR api is inherently
> hierarchic.
> maybe we should provide separate node types or node type attributes to
> indicate that
> instances of  that type may have a large number of child nodes. nodes
> of that node
> type would be represented/handled differently in the persistence layer.

This is the approach that we have taken, however its not without problems when trying to discover
whats in /home


> cheers
> stefan
>> The obvious solution to this problem is to use a data structure like a
>> B-tree to keep track of the child node entries. Doing this efficiently
>> while still supporting both orderable nodes and same-name-siblings
>> (i.e. nt:unstructured) probably requires some deeper thought. An added
>> benefit would be the ability to do this on top of an append-only
>> storage model.
>> Any other ideas on how we could do this?
>> BR,
>> Jukka Zitting

View raw message