lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson" <erickerick...@gmail.com>
Subject Re: IndexSearcher - architecture - shortest possible latency between update of index (via IndexWriter/IndexReader) and querying the same using IndexSearcher
Date Thu, 08 Jan 2009 18:10:36 GMT
This topic has been discussed *very* extensively, so I'd recommend you
search the mail archive (see
http://wiki.apache.org/lucene-java/MailingListArchives )
since there are more good ideas there than I can remember. But the short
answer is that you must open a new searcher for modifications to be seen.

There are schemes for real-time updating, (see the archive) but they all
take work. There are no out-of-the-box solutions that I know of.

I don't understand your last paragraph at all.

Best
Erick

On Thu, Jan 8, 2009 at 12:27 PM, Kay Kay <kaykay.unique@gmail.com> wrote:

> Hi-
>  For one of our apps - we are doing a lot of additions and deletions (high
> frequency) at any given time.  Assuming the same index directory under
> discussion between the  writers ( IndexWriter and IndexReader, the latter
> for deletions) and the readers (IndexSearcher to begin with) - we want the
> IndexSearcher to retrieve the most updated index at the shortest possible
> time (with more priority on the most updated data).  So when a IndexWriter
> and IndexReader updates a particular index directory (with proper locking
> between themselves) and when we search using IndexSearcher (that could have
> been initialized / warmed up in the past )- will another search query
> initiated from the same IndexSearcher instance consider the updated index in
> real time.
>  Are the IndexSearcher instances  'watching' the index directories for
> changes and updating their data structures internally.
>
>  What would be the best / fastest way to make sure that IndexSearcher
> instances return data that are semantically data ( assuming the sequential
> order of data). What are the trade-offs that we can make here - when it
> comes to design decisions of a Lucene-based application. Thanks.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message