Thanks Chris.
http://wiki.apache.org/solr/FederatedSearch
Thats useful & I might be getting close to that size soon.
The issue is best described with an example:
search for canon - matches multiple categories, which will have very
different schemas
http://cnet.search.com/search?chkpt=astg.cnet.fd.search.cnet&q=canon&tag=srch
While this might vary with applications.
2 options that come to my mind:
1. Have 1 index that has ALL categories of products. Possibly 1
generic index with all searchable text, and separate indices when you
know the categroy user is looking for. But with this ranking products
well becomes very difficult.
2. Have separate indices for each category of products. Query them &
merge the results from them. Merging across indices is a difficult
issue. I can draw some learning from the federated search, but this
would more likely be business logic.
Thanks,
mekin
On 1/4/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
Mekin: Yonik has done some brainstorming on ways of supporting "Feterated"
searching across multiple instances of Solr - but the main motivation
there is to deal with homogeneous indexes which are too big to fit on a
single host efficiently...
http://wiki.apache.org/solr/FederatedSearch
..if you've got seperate schemas for each of your indexes, then you have
to query then in different ways, so how could you meaningfully merge the
scores?
-Hoss
--
My company - http://ugenie.com
My Blog - http://mekin.livejournal.com/
<a href="http://www.linkedin.com/in/mekin";>My linkedIn URL</a>
