I hane gone with approach #2 to avoid latency issues as well, specifically for spellcheck related functionality.I have not gone onto to SolrCloud yet ,so I cannot comment on the distributed search part. On Jun 8, 2014 10:38 PM, "Phanindra R" <phani...@gmail.com> wrote:
> Hi, > > We have decided to migrate from Lucene 3.x to latest Solr. A lot of > architectural discussions are going on. There are two possible approaches. > > Please note that our customer-facing app (or any client) and Search are > hosted on different machines. > > *1) Have a clean architecture* > - Solr takes care of customized search only. > > - We certainly have to override some filtering, scoring,etc. > > - There will be an intermediary search-app that > > - receives queries > - does a/b testing assignments, and other non-search stuff. > - does query expansion / rewriting (to avoid every Solr shard doing > that) > - transforms query into Solr syntax and uses Solr's http API to > consume it. > - returns the response to customer-facing app or whatever the client > is. > > The problem with this approach is the additional layer and the latency > between search-app and solr. The client of search has to make an API call, > across the network, to the intermediary search-app which in turns makes > another Http API call to Solr. > > *2) Customize Solr to the full extent* > > - Do all the crazy stuff within Solr. > - We can literally create a new url and register a handler class to > process that. With some limitations, we should be able to do almost > anything. > > The benefit of this approach is that it obviates the additional layer > and the latency. However, I see a lot of long-term problems like hard to > upgrade Solr's version, Dev flexibility (usage of Spring, Hib, etc.). > > How about a distributed search? Where do above approaches stand? > > I understand that this is a subjective question. It'd be helpful if you > could share your thoughts and experiences. > > Thanks. >
