Re: [Exist-open] Performance limits of eXist

[Michael C. <cle...@gm...>]

Thanks for your responses.  We would certainly be undertaking our own
performance testing before deciding to go this route - just hoping to
ascertain some theoretical limits before doing that.
In terms of the size and shape of our data, much of it is quite nested (down
to maybe 7 or 8 levels) documents of moderate size (avg 10-20K), but the
really high volume stuff tends to be quite flat and small.  We could of
course put the flat data into a relational store, leaving just the
hierarchical stuff in eXist - but ideally we'd want to be able to run
XPath/XQuery consistently across the whole data set.

We would also not be looking to do update-in-place, but rather implement
copy-on-write semantics, so that multiple versions of a document would exist
in the store at any one time. The ability therefore to run queries across
the latest versions of each document (or indeed at a given point in time) is
important without significant degradation in performance.  I did read in
your article that multiversion document support was proposed but gather this
has not yet been implemented - is this still on the cards?

It also looks as though it is not possible to distribute the data with eXist
- are there any future plans to support this?  Having all the data in one
place would, I imagine, impose a fundamental limit to scalability.

Michael


2009/5/22 Wolfgang <wol...@ex...>

> It is based on eXist 1.0, which was very different from eXist 1.2 or even
>> 1.3
>>
>
> I forgot to say: eXist 1.0 still used the old indexing scheme (described in
> my old article) which put a limit on the maximum document size to be
> indexed. There has been a radical switch in the core architecture between
> versions 1.0 and 1.1. The 1.1 release was the first one based on a dynamic
> numbering scheme, which does not limit the size of a document (at least
> theoretically). With the indexing scheme, the algorithms for most core
> operations have changed as well.
>
> Wolfgang
>