[
https://issues.apache.org/jira/browse/OAK-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247617#comment-15247617
]
Marcel Reutegger commented on OAK-4233:
---------------------------------------
In general I like the idea to decouple the index update from regular content
changes. With the MVCC model we can easily update an index later when needed. I
think it would be good to come up with a more general design that also works
with the SegmentMK and recent research done by [~egli] on building a TarMK
cluster.
An alternative design I had in mind for non-unique indexes works like this:
- Indexes are all updated asynchronously
- When a query comes in, the currently available persisted index is used as a
base
- The diff between the checkpoint associated with the persisted index and the
current state of the repository runs through the index editor and creates a
branch (preferably in-memory) off the base of the persisted index
- The branched async index, now up-to-date with the current state, is then used
by the query engine
Above steps would only be needed for the index used in a query. Cost
calculation could still happen on the slightly outdated async index data.
> Property index stored locally
> -----------------------------
>
> Key: OAK-4233
> URL: https://issues.apache.org/jira/browse/OAK-4233
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, query
> Reporter: Tomek Rękawek
> Priority: Minor
> Fix For: 1.6
>
>
> When running Oak in a cluster, each write operation is expensive. After
> performing some stress-tests with a geo-distributed Mongo cluster, we've
> found out that updating property indexes is a large part of the overall
> traffic. Let's try to create a new property-local index, that will save the
> indexed data locally, without sharing it.
> Assumptions:
> -there's a new {{property-local}} index type for which the data are saved in
> the local SegmentNodeStore instance created specifically for this purpose,
> -local changes are indexed using a new editor, based on the
> {{PropertyIndexEditor}},
> -remote changes are extracted from the JournalEntries fetched in the
> background read operation and indexed as well,
> -the new index type won't support uniqueness restriction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
