On 29.01.2013, at 11:01, Marcel Reutegger <[email protected]> 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/*". Cheers, Alex
