On 5/23/07, Tako Schotanus <[EMAIL PROTECTED]> wrote:
On 5/23/07, David Nuescheler <[EMAIL PROTECTED]> 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
