lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Dauncey <>
Subject A question on caching filters and architecture
Date Fri, 02 Jun 2006 09:42:39 GMT
Hi everyone, just wondered if I could get peoples opinions on a design issue.

I am designing a system that uses broker / search server pattern.  Each search server will
be responsible for searching a particular application that will consist of multiple indexes.
 Initially, these "servers" will reside on the same JVM as the broker, but will at some point
be distributed.  

Each search server exposes a parallelmultisearcher, which is held in a collection in the broker.
 When a query is sent to the broker, it assess which content type is to be searched, and executes
it against the relevant searchable - if multiple content types are to be searched simultaenously,
it will construct a multisearcher on the fly across several search servers - so far so good.

However, I want to build filters around specific topics (e.g. category = "chemistry") across
all content. Is this best done at the broker level, using a multisearcher that covers all
search servers?  

Initially I imagined each search server having its own cache of filters, but this won't work
if the query involves multiple content types.  If I cache at the broker level, against a multisearcher,
this will be lost every time I need to refresh an individual searcher.  The other option is
not to apply filters on searches that involve multiple servers - but not sure if this will
be performant.

Also, would like some advice on how much overhead wrapping multisearchers in other multisearchers
will add!

Has anyone done anything similar to this?  (and yes, i know Solr does all of this, and its
an excellent app, but our requirements differ in some ways)

Hope this all makes sense, going round in circles a bit at the moment :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message