Hi, On Thu, Oct 7, 2010 at 3:19 PM, Stefan Hagedorn <[email protected]> wrote: > ...I am pretty new to Jackrabbit and while thinking about how to organize my > content in the repo, I was > wondering if the structure/hierarchy of the nodes has an (significant) impact > on indexing and searching....
I don't have deep knowledge of performance issues, but I don't think so. The only limitation that I'm aware of is that a node should not have more than N child nodes, N being around 10'000 last time I checked. And much less than that helps when a human is looking at your tree ;-) OTOH the node hierarchy has a big impact on how self-explaining/hackable (in the noble sense) your system is. http://wiki.apache.org/jackrabbit/DavidsModel has a few pointers, for the rest I'd say think of what you would do in a unixish filesystem, on steroids. > > ...I was thinking about organizing my content in files and folders, because I > read somewhere that a deep > hierarchy is better than a flat one, where every content node is a direct > child of the root node.... File and folders can work well, and you might want to start with a few subdivisions under the root node, again something like a unixish filesystem (/libs for code, /content, /etc for configs, /tmp), etc. My basic benchmark for a node structure is "can someone figure out what this is by just looking at the tree of nodes and properties" - I think making this self-explaining and logical is the beauty of JCR. This includes self-explaining "local micro-trees" under your main pieces of content: pages, business objects, whatever. I also (shameless plug) wrote a blog post about this at http://dev.day.com/content/ddc/blog/2009/04/cq5tags.html, might help. > > ...In a simple benchmark test I wasn't able to figure out any differences of > execution time for xpath queries > between both variants.... Matches my experience. -Bertrand
