Alexey , We are not planning to upgrade our solr version at the moment as all is fine with the current version so far and hence would not be able to try this solution .
Regards Sujatha On Fri, Jun 17, 2011 at 3:47 PM, Alexey Serba <ase...@gmail.com> wrote: > > 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. >
