> Do you mean that we have current Index as it is and have a separate core > which has only the user-id ,product-id relation and at while querying ,do a > join between the two cores based on the user-id. Exactly. You can index user-id, product-id relation either to the same core or to different core on the same Solr instance.
> This would involve us to Index/delete the product as and when the user > subscription for a product changes ,This would involve some amount of > latency if the Indexing (we have a queue system for Indexing across the > various instances) or deletion is delayed Right, but I'm not sure if it's possible to achieve good performance requiring zero latency. > IF we want to go ahead with this solution ,We currently are using solr 1.3 > , so is this functionality available as a patch for solr 1.3? No. AFAIK it's in trunk only. > Would it be > possible to do with a separate Index instead of a core ,then I can create > only one Index common for all our instances and then use this instance to > do the join. No, I don't think that's possible with join feature. I guess that would require network request per search req and number of mapped ids could be huge, so it could affect performance significantly. > You'll need to be a bit careful using joins, as the performance hit > can be significant if you have lots of cross-referencing to do, which > I believe you would given your scenario. As far as I understand join query would build bitset filter which can be cached in filterCache, etc. The only performance impact I can think of is that user-product relations table could be too big to fit into single instance.
