Depending on the size, I'd go for (a). IOW, I wouldn't change the sharding to use (a), but if you have the same shard setup in that case, it's easier.
You'd index a type field with each doc indicating the source of your document. Then use the grouping feature to return the top N from each of the groups you care about. Then a single request will return some docs from each of your doc types, and it's again up to the application layer to combine them intelligently. I'm sure you're aware that the scores aren't comparable in this scenario, so.... Of course you can use filter queries (fq) clauses to restrict to a single type of doc as appropriate. Best, Erick On Mon, Sep 22, 2014 at 4:54 AM, Clemens Wyss DEV <clemens...@mysign.ch> wrote: > As mentioned in antoher post we (already) have a (Lucene-based) generic > indexing framework which allows any source/entity to provide > indexable/searchable data. > Sources may be: > pages > events > products > customers > ... > As their names imply they have nothing in common ;) Never the less we'd like > to search across them, getting one resultset with the top hits > (searching across sources is also required for (auto)suggesting search terms) > > In our current Lucene-approach we create a Lucene index per source (and > language) and then search across the indexs with a MultiIndexReader. > Switching to Solr we'd like to rethink the design decision whether to > a) put all data into one core(Lucene index) > or to > b) split them into seperate cores > > if b) how can I search across the cores (in SolrJ)? > > Thx > Clemens
