lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jason rutherglen <jasonhus...@yahoo.com>
Subject Re: GData Server - Lucene storage
Date Fri, 02 Jun 2006 17:35:41 GMT
Yonik,

It might be interesting to merge using BDB into Solr, as an option to provide better realtime
updates.  Perhaps the replication could be used as well in place of rsync?  I don't have any
experience with BDB replication, anyone have thoughts on the matter?

Jason

----- Original Message ----
From: Simon Willnauer <simon.willnauer@googlemail.com>
To: Yonik Seeley <yseeley@gmail.com>
Cc: java-dev@lucene.apache.org
Sent: Friday, June 2, 2006 9:56:24 AM
Subject: Re: GData Server - Lucene storage

On 6/2/06, Yonik Seeley <yseeley@gmail.com> wrote:
>
> On 6/2/06, Simon Willnauer <simon.willnauer@googlemail.com> wrote:
>
>
> > 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.


So that's actually what I expected. You can't have everything with this
approach. I always have to lower one's sights. But I wan't to be prepared to
serv a high volume of inserts and updates. I used lucene a couple of times
with version 1.4 and  concurrent write access hasn't change. I will use the
Berkley DB for Java as the default storage, I still can implement a lucene
based storage if there is enough time. I had a look at the licence of the
sleepycat BerkleyDB for Java dist. and in my opinion it is alright to use
and distribute it with the gdata server.
Are there any experts on licencing? Is it ok for the ASF to use that?

simon





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