[
https://issues.apache.org/jira/browse/OAK-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249950#comment-15249950
]
Vikas Saurabh commented on OAK-4233:
------------------------------------
I was just suggesting to sort of automate what can be done manually even today
-> transform all non-required-sync-prop-index to use lucene.
As currently lucene based indexing already provides us with:
* less node store data churn (async, single-instance-indexing, mostly based on
binary blobs)
* utilize CoR to have fast access to indexed binaries
So, I was wondering if index-type='new-async-prop-index', which otherwise looks
like our current property definitions, but internally it creates an nt:base
based lucene's IndexDefinition for the said property. Could this be an
easier/tested approach?
bq. Could you elaborate on this? Replacing the SegmentMK+OakDirectory+Lucene
with FS+Lucene seems like a simpler solution here.
That was wrt to Davide's point of removing OakDirectory. What I meant was that
a simple local FS directory containing lucene binaries (copied over or indexed
locally) would represent indexed-data at last checkpoint that's indexed. That's
definitely acceptable for a query on session which is newer than that
checkpoint. But, it'd not be the correct way to handle query from a session
which is on older rev wrt the indexed-checkpoint. That problem is already
solved in lucene impl via interplay of Tracker, IndexDef and OakDirectory. I
was just pointing out that to assert MVCC-ness, we'd to need some wrapper over
direct fs based lucene indices.
> 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)
