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 Mon, 20 Apr 2009 21:10:47 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

* The RAMIndex deletes approach changed to be like IndexWriter.
The deletes are queued in lists, then applied on RI.flush. 

* There is redundancy between IW.delete* and RI.delete*, perhaps
we don't need RI.delete*?

* We need more multithreaded tests, probably based on
TestIndexWriter to see if we can trigger issues in regards to
deletes that occur while RI is calling IW.addIndexesNoOptimize.

* If RI.delete* is removed, do we need a separate RAMIndex class
to add documents to or is there a more transparent way for NRT
ramdir to work? Perhaps we can add an IW.flushToRamDir (whereas
IW.flush writes to the IW directory) method that flushes the
rambuffer to the RAMIndex? Some of the the issues are around
swapping out the RAMDir once it's segments are flushed to IW. If
we took this approach would we need a IW.getReaderRAM method
that instead of flushing to disk flushes to the ramdir? The
other problem with the IW.flushToRamDir system is the loss of
concurrency where a large rambuffer may be flushing to disk
while the user really wants to small incremental NRT RI based
updates at the same time. 

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