jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: workspace / repository scalability
Date Thu, 24 May 2007 09:14:32 GMT
On 5/23/07, Tako Schotanus <quintesse@gmail.com> wrote:
> On 5/23/07, David Nuescheler <david.nuescheler@gmail.com> wrote:
> > hi cris,
> >
> > > I'm expecting that we will have about 10-15 nodes per "document" in most
> > > cases, though some could have 35-50.
> > sounds good.
> >
> > > When you say adequate hierarchical structure, does this imply that we should
> > > try to keep our tree "bushy"? Really, because we rely on the external search
>
> Sorry for butting in, but depending on the OS I definitely wouldn't
> hesitate storing many thousands of files in a folder on a file system.
> We've done so on Linux/Unix systems where many tens of thousands of
> files were being stored in the same folder without any problems.
>
> Of course I wouldn't do the same on Windows (neither would I try to
> use the Gnome file manager on Linux to take a look at that folder, it
> doesn't seem to handle it very gracefully).
>
> Anyway, what you're saying is that we should try to do the same with
> Jackrabbit? Several hundreds is okay, but many more and you'd better
> use some kind of hierarchy?

jackrabbit's internal state model is optimized for, let's say, small to
medium sized child node sets. the child node id's are stored in the
parent node's state which helps read performance. however, it has
a negative impact on write performance, noticeable with large number
child nodes.

i'd say that hierarchies with up to ~10k child nodes per node are
perfectly fine and you won't notice any significant negative performance
impact.

cheers
stefan



>
> Cheers,
>  -Tako
>

Mime
View raw message