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 <[EMAIL PROTECTED]> To: Yonik Seeley <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On 6/2/06, Simon Willnauer <[EMAIL PROTECTED]> 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