[ https://issues.apache.org/jira/browse/OAK-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307635#comment-15307635 ]
Tomek Rękawek commented on OAK-4412: ------------------------------------ Branch: https://github.com/trekawek/jackrabbit-oak/tree/OAK-4412 A somehow working PoC: [LuceneMemoryClusterTest|https://github.com/trekawek/jackrabbit-oak/blob/ef427db94b6122e737b6f61602ae1c97d9b5e397/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneMemoryClusterTest.java#L157] > Lucene-memory property index > ---------------------------- > > Key: OAK-4412 > URL: https://issues.apache.org/jira/browse/OAK-4412 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene > Reporter: Tomek Rękawek > 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. > The asynchronous index would be an answer here (as the index update won't be > made in the client request thread), but the AEM requires the updates to be > visible immediately in order to work properly. > The idea here is to enhance the existing asynchronous Lucene index with a > synchronous, locally-stored counterpart that will persist only the data since > the last Lucene background reindexing job. > The new index can be stored in memory or (if necessary) in MMAPed local > files. Once the "main" Lucene index is being updated, the local index will be > purged. > Queries will use an union of results from the {{lucene}} and > {{lucene-memory}} indexes. > The {{lucene-memory}} index, as a local stored entity, will be updated using > an observer, so it'll get both local and remote changes. > The original idea has been suggested by [~chetanm] in the discussion for the > OAK-4233. -- This message was sent by Atlassian JIRA (v6.3.4#6332)