jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: MongoMK^2 design proposal
Date Tue, 29 Jan 2013 10:53:13 GMT
On 29.01.2013, at 11:01, Marcel Reutegger <mreutegg@adobe.com> wrote:
> What is not yet clear to me is, how do you decide what the size of a segment
> should be? This can be quite delicate. On the one hand you want to avoid
> small segments because they are inefficient with all the UUID lookups. But
> larger segments are also not ideal, because they increase the cost of a write.
> I understand the complete segments needs to be re-written in this case,
> or do you have a design in mind where a segment can overlay another one?
> however, this leads to fragmentation.

What instantly comes to my mind: represent hierarchy nodes as segments. I.e. anything below
jcr:content is seen as one segment.

This might often be rather small, but usually separates quite well the lifecycles, units of
modification and gives a natural limit of the segment size in many applications. This should
at least optimize the cacheability of those segments in memory.

And maybe segment definition is configurable. The above case would be a rule like "jcr:content/*".

View raw message