lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Rutherglen <jason.rutherg...@gmail.com>
Subject Re: caching an indexreader
Date Fri, 19 Jun 2009 19:06:13 GMT
> As I understand it, the user won't see any changes to the
index until a new Searcher is created.

Correct.

> How much memory will caching the searcher cost? Are there
other tradeoff's I need to consider?

If you're updating the index frequently (every N seconds) and
the searcher/reader is closed reasonably quickly (under 5
minutes) then it should work. There will be files left around a
little longer than usual, which depends on their size and your
disk capacity (usually won't matter).

With things like LUCENE-1313 coming up, the incoming updates
wouldn't be creating small segments on disk, meaning only larger
segments are written to disk and keeping a searcher open (while
eating more RAM, under the specified limit) will happen, extra
largish disk files hanging around won't happen.

When doing distributed search in something like SOLR I wonder
how this solution would work. Maybe it would simply use HTTP
sessions ids as well.

On Fri, Jun 19, 2009 at 11:40 AM, Scott Smith <ssmith@mainstreamdata.com>wrote:

> In my environment, one of the concerns is that new documents are
> constantly being added (and some documents may be deleted).  This means
> that when a user does a search and pages through results, it is possible
> that there are new items coming in which affect the search-thus changing
> where items are in relation to the pages displayed to the user.
>
>
>
> It seems to me that one solution would be to cache the Searcher for the
> duration of the user's search session so that the user's view of the
> available documents doesn't change.  As I understand it, the user won't
> see any changes to the index until a new Searcher is created.  However,
> I'm very sensitive to the amount of session context memory that caching
> the searcher might take up.  How much memory will caching the searcher
> cost?  Are there other tradeoff's I need to consider?
>
>
>
> Is this a viable option or does anyone have an alternative suggestion?
>
>

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