[
https://issues.apache.org/jira/browse/OAK-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249726#comment-15249726
]
Tomek Rękawek commented on OAK-4233:
------------------------------------
Thanks for the new idea! A few questions:
-in this approach we don't extract the property index from the main node store
(as in the original proposition), right?
-does the index editor mentioned in the point 3 look for all index changes or
just regarding the indices used in the query?
-when do we update the persisted index / merge the in-memory branch? can we do
this asynchronously after executing the query?
-how should we resolve potential conflicts if there's a few queries / branches
at the same time?
> 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)
