lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: QueryFilter vs CachingWrapperFilter vs RangeQuery
Date Tue, 07 Dec 2004 21:59:03 GMT
If you run the same query again, the IndexSearcher will go all the way
to the index again - no caching.  Some caching will be done by your
file system, possibly, but that's it.  Lucene is fast, so don't
optimize early.

Otis


--- Ben Rooney <ben.rooney@blastradius.com> wrote:

> thanks chris,
> 
> you are correct that i'm not sure if i need the caching ability.  it
> is
> more to understand right now so that if we do need to implement it, i
> am
> able to.
> 
> the reason for the caching is that we will have listing pages for
> certain content types.  for example a listing page of articles.  this
> listing will be generated against lucene engine using a basic query.
> the page will also have the ability to filter the articles based on
> date
> range as one example.  so caching those results could be beneficial.
> 
> however, we will also potentially want to cache the basic query so
> that
> subsequent queries will hit a cache.  when new content is published
> or
> content is removed from the site, the caches will need to be
> invalidated
> so new results are created.
> 
> for the basic query, is there any caching mechanism built into the
> SearchIndexer or do we need to build our own caching mechanism?
> 
> thanks
> ben
> 
> On Tue, 2004-07-12 at 12:29 -0800, Chris Hostetter wrote:
> 
> > : > executes the search, i would keep a static reference to
> SearchIndexer
> > : > and then when i want to invalidate the cache, set it to null or
> create
> > 
> > : design of your system.  But, yes, you do need to keep a reference
> to it
> > : for the cache to work properly.  If you use a new IndexSearcher
> > : instance (I'm simplifying here, you could have an IndexReader
> instance
> > : yourself too, but I'm ignoring that possibility) then the
> filtering
> > : process occurs for each search rather than using the cache.
> > 
> > Assuming you have a finite number of Filters, and assuming those
> Filters
> > are expensive enough to be worth it...
> > 
> > Another approach you can take to "share" the cache among multiple
> > IndexReaders is to explicitly call the bits method on your
> filter(s) once,
> > and then cache the resulting BitSet anywhere you want (ie:
> serialize it to
> > disk if you so choose).  and then impliment a "BitsFilter" class
> that you
> > can construct directly from a BitSet regardless of the IndexReader.
>  The
> > down side of this approach is that it will *ONLY* work if you
> arecertain
> > that the index is never being modified.  If any documents get
> added, or
> > the index gets re-optimized you must regenerate all of the BitSets.
> > 
> > (That's why the CachingWrapperFilter's cache is keyed off of hte
> > IndexReader ... as long as you're re-using the same IndexReader, it
> know's
> > that the cached BitSet must still be valid, because an IndexReader
> > allways sees the same index as when it was opened, even if another
> > thread/process modifies it.)
> > 
> > 
> > 	class BitsFilter {
> >            BitSet bits;
> >            public BitsFilter(BitSet bits) {
> >              this.bits=bits;
> >            }
> >            public BitSet bigs(IndexReader r) {
> >              return bits.clone();
> >            }
> >         }
> > 
> > 
> > 
> > 
> > -Hoss
> > 
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> lucene-user-help@jakarta.apache.org
> > 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message