On 18 Feb 2010, at 13:04, Stefan Guggisberg wrote: > On Wed, Feb 17, 2010 at 5:17 PM, Jukka Zitting <jukka.zitt...@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 Ian > > 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 >>
