jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chetan Mehrotra (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-4412) Lucene hybrid index
Date Wed, 27 Jul 2016 07:43:20 GMT

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

Chetan Mehrotra commented on OAK-4412:
--------------------------------------

While implementing this we can also make use of Near Real Time search feature of Lucene [1]
[2]. The observer can keep the writer open and upon any writes (and with some minimum delay)
the reader can be obtained from that writer. This would ensure that we can reduce the overhead
of open->close->open cycle if content is changing frequently

[1] http://blog.mikemccandless.com/2011/06/lucenes-near-real-time-search-is-fast.html
[2] https://wiki.apache.org/lucene-java/NearRealtimeSearch

> Lucene hybrid 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
>            Assignee: Tomek Rękawek
>             Fix For: 1.6
>
>         Attachments: OAK-4412.patch
>
>
> 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)

Mime
View raw message