[
https://issues.apache.org/jira/browse/OAK-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247696#comment-15247696
]
Davide Giannella commented on OAK-4233:
---------------------------------------
[~mreutegg]
{quote}
- 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
{quote}
I like the idea. It will require quite some changes on the query
engine side. It sounds a more generic approach we could take anyhow
regardless of this actual issue or not.
[~catholicon]
{quote}
...
CoR would get a copy on each node locally
...
{quote}
I'm actually wondering if we should not investigate the option of
getting rid of CoW/R and going towards a pure file system approach for
lucene getting rid of {{OakDirectory}}.
> 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)
