I'm not reindexing the entire index. I'm just commiting the updated. But I'm not sure how it would affect performance to commit in real time. I think right now I have like 10 updated per minute.
On 8/22/07, Erick Erickson <[EMAIL PROTECTED]> wrote: > > There are several approaches. First, is your index small > enough to fit in RAM? You might consider just putting it all in > RAM and searching that. > > A more complex solution would be to keep the increments > in a separate RAMDir AND your FSDir, search both and > keep things coordinated. Something like > > open FSDIr > create RAMDir > while (whatever) { > get request > if (modification) { > write to FSDir and RAMDir > } > if (search) { > search FSDir > open RAMDir reader > search RAMDir > close RAMDir reader (but not writer!) > } > } > > close FSDIr > close RAMDir > start again from the top. > > > > Warning: I haven't done this, but it *should* work. The sticky > part seems to me to be coordinating deletes since the > open FSDir may contain documents also in the RAMDir, > but that's "an exercise for the reader"<G>, > > You could also define the problem away and just live > with a 5 minute latency. > > Best > Erick > > On 8/22/07, Jonathan Ariel <[EMAIL PROTECTED]> wrote: > > > > Hi, > > I'm new to this list. So first of all Hello to everyone! > > > > So right now I have a little issue I would like to discuss with you. > > Suppose that your are in a really big application where the data in your > > database is updated really fast. I reindex lucene every 5 min but since > my > > application lists everything from lucene there are like 5 minutes (in > the > > worse case) where I don't see new staff. > > What do you think would be the best aproach to this problem? > > > > Thanks! > > > > Jonathan > > >