Nearly 100ms? If any netizen ever complained about that, I'd 'round-file' the complaint. Internal to a single process's execution, well, mabye it's an issue. Not too hard to handle.
Good job to the team that made it! From: Michael McCandless <luc...@mikemccandless.com> To: solr-user@lucene.apache.org; bing...@asu.edu Cc: Bing Li <lbl...@gmail.com> Sent: Fri, March 4, 2011 10:45:05 AM Subject: Re: When Index is Updated Frequently On Fri, Mar 4, 2011 at 10:09 AM, Bing Li <lbl...@gmail.com> wrote: > According to my experiences, when the Lucene index updated frequently, its > performance must become low. Is it correct? In fact Lucene can gracefully handle a high rate of updates with low latency turnaround on the readers, using the near-real-time (NRT) API -- IndexWriter.getReader() (or in soon-to-be 31, IndexReader.open(IndexWriter)). NRT is really something a hybrid of "eventual consistency" and "immediate consistency", because it lets your app have full control over how quickly changes must be visible by controlling when you pull a new NRT reader. That said, Lucene can't offer true immediate consistency at a high update rate -- the time to open a new NRT reader is usually too costly to do, eg, for every search. But eg every 100 msec (say) is reasonable (depending on many variables...). So... for your app you should run some tests and see. And please report back. (But, unfortunately, NRT hasn't been exposed in Solr yet...). -- Mike http://blog.mikemccandless.com
