jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [jr3] Flat hierarchy
Date Thu, 18 Feb 2010 13:04:29 GMT
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 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

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.


> 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