Perhaps this could be a custom SearchComponent that's run before the usual QueryComponent? This component would be responsible for loading queries, executing them, caching results, and for returning those results when these queries are encountered later on.
Otis ---- Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm >________________________________ > From: Aaron Daubman <daub...@gmail.com> >To: solr-user@lucene.apache.org >Sent: Wednesday, May 23, 2012 12:00 PM >Subject: Tips on creating a custom QueryCache? > >Greetings, > >I'm looking for pointers on where to start when creating a >custom QueryCache. >Our usage patterns are possibly a bit unique, so let me explain the desired >use case: > >Our Solr index is read-only except for dedicated periods where it is >updated and re-optimized. > >On startup, I would like to create a specific QueryCache that would cache >the top ~20,000 (arbitrary but large) queries. This cache should never >evict entries, and, after the "warming process" to populate, should never >be added to either. > >The warming process would be to run through the (externally determined) >list of anticipated top X (say 20,000) queries and cache these results. > >This cache would then be used for the duration of the solr run-time (until >the period, perhaps daily, where the index is updated and re-optimized, at >which point the cache would be re-created) > >Where should I begin looking to implement such a cache? > >The reason for this somewhat different approach to caching is that we may >get any number of odd queries throughout the day for which performance >isn't important, and we don't want any of these being added to the cache or >evicting other entries from the cache. We need to ensure high performance >for this pre-determined list of queries only (while still handling other >arbitrary queries, if not as quickly) > >Thanks, > Aaron > > >
