I tried using BTreeManager but I don't think it will work well for my
case. Instead I am going to introduce some artificial structure to my
data - build a structure N levels deep, fill it up with N number of
nodes, and then move up the tree as the nodes fill up.
On 11/14/2015 12:17 PM, Robert Munteanu wrote:
Hi Clay,
On Sat, Nov 14, 2015 at 5:46 PM, Clay Ferguson <[email protected]> wrote:
Robert, I don't think any of us, including myself, had a misunderstanding
about the fact that the limitation is for a large number of child nodes
under SAME parent. No one said 50K in the entire repository was causing
problems, but 50K children under same parent IS a problem if it's slow.
It's a very significant issue for actual application developers trying to
build something, because everything looks like its performing great but
will fail miserably when you scale it up. It's hard to call JCR 'enterprise
scale' with such a silly limitation staring is all right in the face
defying any solution.
That may or may not be true - the original post said that 'after 50K
plus child nodes retrieval is taking ~15 seconds'. I obviously added a
note that this - with the current JCR implementations - is expected.
What you consider a limitation is something that I personally consider
an implementation constraint - if you want to use JCR it's something
that you need to take into account.
That being said, Oak is expected to perform much better with flat
hierarchies, as long as the child nodes are not sortable. So you might
want to try this as well. Just be careful since nt:unstructured does
have orderable child nodes so you're better off using something like
oak:unstructured.
Thanks,
Robert
