What about field1:01 ..... field:100 being used as separate filters (that would then get ANDed) -- doable?
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Development Team <dev.and...@gmail.com> > To: solr-user@lucene.apache.org; yo...@lucidimagination.com > Sent: Tuesday, May 26, 2009 4:54:34 PM > Subject: Re: Solr query performance issue > > Yes, those terms are important in calculating the relevancy scores so they > are not in the filter queries. I was hoping if I can cache everything about > a field, any combinations on the field values will be read from cache. Then > it does not matter if I query for field1:(02 04 05), or field1:(01 02) or > field1:03 the response time is equally quick. Is there anyway to achieve > that? > Yeah, the range queries are also a bottleneck too, I will give the TrieRange > fields a try. Thanks for you advice. > > Best Regards, > Shi Quan He > > On Tue, May 26, 2009 at 3:55 PM, Yonik Seeley wrote: > > > On Tue, May 26, 2009 at 3:42 PM, Larry He wrote: > > > We have about 100 different fields and 1 million documents we indexed > > with > > > Solr. Many of the fields are multi-valued, and some are numbers (for > > range > > > search). We are expecting to perform solr queries contains over 30 terms > > > and often the response time is well over a second. I found that the > > caches > > > in Solr such as QueryResultCache and FilterCache does not help us much in > > > this case as most of the queries have combinations of terms that are > > > unlikely to repeat. An example of our query would look like: > > > > > > field1:(02 04 05) field2:(01 02 03) field2:(01 02 03) ... > > > > > > My question is how can we improve performance of these queries? > > > > filters are independently cached... but they are currently only "AND" > > filters, so you could only split it up like so: > > > > fq=field1:(02 04 05)&fq=field2:(01 02 03)&fq=field2:(01 02 03) > > But that won't help unless any of the individual fq params are > > repeated across different queries. > > > > Range search can also be sped up a lot via the use of the new > > TrieRange fields, or via the frange (function range query) > > capabilities in Solr 1.4.... it's not clear if the range queries or > > the term queries are your current bottleneck. > > > > If the range queries aren't your bottleneck and separate filters don't > > work, then a query type could be developed that would help your > > situation by caching matches on term queries. Are relevancy scores > > important for the clauses like field1:(02 04 05), or do you sort by > > some other criteria? > > > > -Yonik > > http://www.lucidimagination.com > >
