lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Mannix <>
Subject Re: Realtime search best practices
Date Mon, 12 Oct 2009 17:28:27 GMT
Hi Cedric,

  I don't know of anyone with a substantial throughput production system who
is doing realtime search with the 2.9 improvements yet (and in fact, no
serious performance analysis has been done on these even "in the lab" so to
speak: follow to track
on this), so some experimentation will be necessary to know how well it fits
in your environment.

  Your approach has the basic components of how to do 2.9 NRT search,
but it's missing the point when you're making your commit() calls.  Your
here depend on some tradeoffs, as lucene provides ACID-like transactional
semantics whereby if you decide to commit() after every add(), then yes,
getReader() will be up-to-date with the most recent commit(), but at a cost
of indexing throughput (and much more frequent segment merges), at least
in comparison to only calling commit() at a slower rate (but calling
less frequently means, of course, that you only have readers as fresh as
your most recent commit).

  Also, you have to be aware that there are no guarantees as far as
realtimeliness is concerned with 2.9 NRT - if there is an addIndexes() going

on in anther thread on your IndexWriter, this is another instance where your

getReader() call won't block, but also won't necessarily get access to the
all of these new segments if the addIndexes() hasn't completed yet.

  Please post here any results you find with this - this is a very new
and seeing how it works in the wild would be very helpful to everyone else
who is interested.


On Mon, Oct 12, 2009 at 2:24 AM, melix <> wrote:

> Hi,
> I'm going to replace an old reader/writer synchronization mechanism we had
> implemented with the new near realtime search facilities in Lucene 2.9.
> However, it's still a bit unclear on how to efficiently do it.
> Is the following implementation the good way to do achieve it ? The context
> is concurrent read/writes on an index :
> 1. create a Directory instance
> 2. create a writer on this directory
> 3. on each write request, add document to the writer
> 4. on each read request,
>  a. use writer.getReader() to obtain an up-to-date reader
>  b. create an IndexSearcher with that reader
>  c. perform Query
>  d. close IndexSearcher
> 5. on application close
>  a. close writer
>  b. close directory
> While this seems to be ok, I'm really wondering about the performance of
> opening a searcher for each request. I could introduce some kind of delay
> and cache a searcher for some seconds, but I'm not sure it's the best thing
> to do.
> Thanks,
> Cedric
> --
> View this message in context:
> Sent from the Lucene - Java Users mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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