lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: GData Server - Lucene storage
Date Fri, 02 Jun 2006 16:30:52 GMT
On 6/2/06, Simon Willnauer <> wrote:
> The problem here is that there is no action comparable to commit. The entry
> comes in and will be added to the storage. The delete will be queued but
> when should the delete operation start. Waiting for the writer to idle?! We
> could do it that way. but if a search request comes in the old entries will
> be found an can be retrieved from the storage. In that case I have to hold
> the already added but not yet deleted entries in a storage cache to prefent
> the storage from retrieving outdated and updated entries because they have
> the same ID.
> You use multiple indexSearcher instances to serve searches right?

There is normally only a single searcher open at a time (except when warming).
A main "registered" searcher handles all live requests.  When a new
searcher is opened, it is warmed up (requests run against it in the
background, caches pre-populated, etc) and then it is registered.

> so when
> all the deletes are done you have to reopen all indexsearchers again right?!

Just one.

> So this would happen quiet often due to updates and inserts.
> Hmm it is more and more a bad idea to use a lucene index as a storage.
> Rather go straight to a Database.

Yes, if you need to be able to *instantly* retrieve (but not search)
updates you just inserted, and you need to support a high volume of
updates and queries.

You could also do that in-memory by supporting retrieval by id from
your "batch" of documents not yet "committed" in Lucene.  Only
downside is it's volatile.

-Yonik Solr, the open-source Lucene search server

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message