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 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
