Hi Ajanta, I think you answered your own questions. Either use Filters or partition the index. The advantage of partitioning is that you can update them separately without affecting filters, cache, searcher, etc. for the other indices (i.e. no need to warm up with data from the other indices). If you are indeed working with the high QPS, partitioning also lets you scale indices separately (are all territories the same size document-wise? do they all get the same QPS?). The disadvantage is that you can't easily run queries that don't depend on a territory.
Otis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lucene Consulting -- http://lucene-consulting.com/ ----- Original Message ---- From: Ajanta <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Tuesday, May 15, 2007 11:35:13 AM Subject: system architecture question when using solr/lucene We are currently looking at large numbers of queries/sec and would like to optimize that as much as possible. The special need is that we would like to show specific results based on a specific field - territory field and depending on where in the world you're coming from we'd like to show you specific results. The index is very large (currently 2 million rows) and could grow even larger (2-3 times) in the future. How do we accomplish this given that we have some domain knowledge (the territory) to use to our advantage? Is there a way we can hint solr/lucene to use this information to provide better results? We could use filters on territory or we could use different indexes for different territories (individually or in a combination.) Are there any other ways to do this? How do we figure out the best case in this situation? -- View this message in context: http://www.nabble.com/system-architecture-question-when-using-solr-lucene-tf3759225.html#a10625155 Sent from the Solr - User mailing list archive at Nabble.com.
