lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <paul.elsc...@xs4all.nl>
Subject Re: PrefixQuery,WildcardQuery,RangeQuery and FuzzyQuery PROBLEM
Date Wed, 13 Jul 2005 18:00:39 GMT
On Wednesday 13 July 2005 12:53, Erik Hatcher wrote:
> 
> On Jul 13, 2005, at 6:21 AM, MariLuz Elola wrote:
> >     I have been readed about "Too many clauses"...........   If the  
> > max was set too high, the inefficiency would make the search unsable.
> >     I am testing the performance of Lucene and the time that spend  
> > Lucene in searching is too high. Moreover I´ve got OutOfMemory  
> > error several times.....
> >     I am speaking about an index with 250.000 documents more or  
> > less, but in the future will be necessary an index with millions of  
> > documents.
> >
> > These are the kinds of queries:
> >
> > 1. Greater than or lower than request
> > RangeQuery with Integer.MAX_VALUE for greater than or  
> > Integer.MIN_VALUE for lower than
> >
> > 2. RangeQuery
> >
> > Example:
> >
> >         Field:[minValue to maxValue]
> 
> Keep in mind that dealing with numeric information requires some  
> adjustments both at how you index and how RangeQuerys are formed.   
> For example, if you index "1" through "10" doing a RangeQuery of [1  
> TO 5] will also find "10" unless you account for it with a special  
> QueryParser subclass.
> 
> > 3.WildcardQuery
> >
> > Example:
> >
> >     Field:value*
> >
> > ect....
> >
> > The problem is that PrefixQuery,WildcardQuery,RangeQuery and  
> > FuzzyQuery all expand to a series of OR'ed boolean queries.
> >
> > I have read about BitSetQuery, FilteringQuery,  
> > ConstrantScoreQuery.......... I am confused!!!!!!
> 
> There certainly are lots of options.  The Query classes you mention,  
> though, are not currently exposed via QueryParser, so you would need  
> to subclass QueryParser to have them created instead, or create your  
> own parser, or mix and match some query expression parsing and join  
> it with some API created Querys via BooleanQuery.
> 
> >  I can´t use a Filter (DateFilter, QueryFilter ect...) because the  
> > client wants to search for all the documents without filter for  
> > anything.
> 
> This doesn't make sense to me.  Implicitly the user is "filtering"  
> documents by adding constraints to a query expression using  
> Field:value* or Field:[min TO max].
> 
> > I can´t divide a field in subfields to do the query more specific.  
> > For example, the user wants the date with format YYYMMDDHHMMSS, not  
> > 6 fields, one with the year, one with the month, one with the day,  
> > one with de hour ect....
> 
> The index structure needs to be a bit more abstracted from the user  
> in your case, it seems.  The user does not need to know explicitly  
> that the index is split into multiple fields for dates in order to  
> make searching more efficient.  If the user is not doing queries down  
> to the second level, but rather always at the day level, then  you  
> can build the index to account for that type of usage and improve the  
> experience.

One can also index all of these (or even more) and hide them from the user:

YYY
YYYMM
YYYMMDD
YYYMMDDHH
YYYMMDDHHMM
YYYMMDDHHMMSS

With this, searching ranges would require subclassing the QueryParser
with classes that implement the range search using as few terms as possible.
That should bring down the number of terms used to a some logarithm
of the total range size.

Regards,
Paul Elschot


Mime
View raw message