[ 
https://issues.apache.org/jira/browse/OAK-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249938#comment-15249938
 ] 

Tomek Rękawek commented on OAK-4233:
------------------------------------

[~catholicon], thanks for the suggestion. If I understand correctly, your idea 
is to keep the separate, local SegmentMK (as in the original idea) but use 
Lucene index rather than property index. Lucene would write data to the 
SegmentMK using the OakDirectory wrapper, as it does right now.

bq. Pure file system would not get the MVCC truth-ness...

Could you elaborate on this? Replacing the SegmentMK+OakDirectory+Lucene with 
FS+Lucene seems like a simpler solution here.

> 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)

Reply via email to