lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rutherglen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-1313) Realtime Search
Date Fri, 17 Apr 2009 20:28:15 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jason Rutherglen updated LUCENE-1313:
-------------------------------------

    Attachment: LUCENE-1313.patch

I added an IndexWriter.getRAMIndex method that returns a
RAMIndex object that can be updated and flushed to the
underlying writer. I think this is better than adding more
methods to IndexWriter and it separates out the logic of the RAM
based near realtime index and the rest of IW.

Package protected IW.addIndexesNoOptimize(DirectoryIndexReader[]
readers) is added which is used by RAMIndex.flush. I thought
this functionality could work for LUCENE-1589 as a public
method, however because of the way IndexWriter performs merges
using segment infos, handling generic IndexReader classes (which
may not use segmentinfos) would then be difficult in the
addIndexesNoOptimize case.

I think RAMIndex.flush to the underlying writer is not
synchronized. If the IW is using ConcurrentMergeScheduler then
the heavy lifting is performed in the background and so should
not delay adding more documents to the RAMIndex.

IW.getReader returns the normal IW reader and the RAMIndex
reader if there is one.

The RAMIndex writer can be obtained and modified directly as
opposed to duplicating the setter methods of IndexWriter such as
setMergeScheduler.

> Realtime Search
> ---------------
>
>                 Key: LUCENE-1313
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1313
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index
>    Affects Versions: 2.4.1
>            Reporter: Jason Rutherglen
>            Priority: Minor
>             Fix For: 2.9
>
>         Attachments: LUCENE-1313.jar, LUCENE-1313.patch, LUCENE-1313.patch, LUCENE-1313.patch,
lucene-1313.patch, lucene-1313.patch, lucene-1313.patch, lucene-1313.patch
>
>
> Realtime search with transactional semantics.  
> Possible future directions:
>   * Optimistic concurrency
>   * Replication
> Encoding each transaction into a set of bytes by writing to a RAMDirectory enables replication.
 It is difficult to replicate using other methods because while the document may easily be
serialized, the analyzer cannot.
> I think this issue can hold realtime benchmarks which include indexing and searching
concurrently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message