Hi,
On Mon, Oct 28, 2013 at 12:13 AM, Thomas Mueller <[email protected]> wrote: > > Hi, > > >The SegmentMK addresses this issue by grouping related content into > >larger segments and thus reducing the number of network or disk > >accesses needed in most use cases. Perhaps the MongoMK could do > >something similar? > > Yes. What might work is to store a limited number of child nodes (a > subtree really) in the parent node (in the parent document), for a certain > revision. Kind of a cache, which is only used if there is no change below > the given subtree. The subtree cache would be built in a background > thread, and outdated subtree caches could be removed whenever a document > is changed (possibly also in a background thread). I think especially for "document like" structures, like nt:hierarchyNode+jcr:content (eg: cq:Page+cq:PageContent) it makes sense to store the subtree in one object, as such a document is usually treated as 1 entity and all its subnodes are usually traversed on read. IIRC, it was one of the initial design ideas of the MK to do a smart subtree collating in oder to reduce the number of json objects to be stored. > > Using MapDB [1] or the H2 MVStore [2] for caching: this might improve > startup time drastically, if we really load many nodes at startup. But I'm > a bit afraid of the added complexity to maintain a local storage. So far > we don't use local storage as far as I know. > > [1] http://www.mapdb.org/ > [2] http://h2database.com/html/mvstore.html > > > Regards, > Thomas > regards, toby
