I used the XML, I think using HTTP is important. No caching on the client yet, that is a good idea, however my personal goal is to have an index that is updated every 30 seconds or less and so am not sure about caching on the client. The caching can be handled by the Solr servers, that should be fine. If it works correctly then the architecture is very simple requiring 2 layers. The first is a Solr layer, the second is the client layer essentially running many threads in parallel per request. Seems like this would scale cheaply by adding more hardware on both layers.
> If you are using RMI you could either borrow from or subclass Lucene's MultiSearcher that implements this stuff. Yeah this is the real issue, if there are any general outlines of the best way to do this with Solr. Perhaps a separate Solr call for the docFreqs? Or could this be returned in the current /select call? I'm still trying to figure this part out. ----- Original Message ---- From: Yonik Seeley <[EMAIL PROTECTED]> To: solr-dev@lucene.apache.org Sent: Thursday, May 18, 2006 5:21:58 PM Subject: Re: Making RemoteSearchable like client for Solr On 5/18/06, jason rutherglen <[EMAIL PROTECTED]> wrote: > A solution to an index that requires 100s of millions of documents is to > distributed the documents over multiple servers. I thought I had the > RemoteSearchable like client for Solr pretty well done Great! Can you share what approach you followed? Is caching done on the subsearchers, and not the supersearcher? Are you using RMI, or XML/HTTP? > , however this normalized scoring with weights throws a bit of a kink. It certainly does... not easy stuff. If you are using RMI you could either borrow from or subclass Lucene's MultiSearcher that implements this stuff. -Yonik
