I’ve certainly go for the 2nd option. Depending of what you need you won’t need to modify Solr itself but extend it using different plugins for what you need. You’ll need to write different components depending on your specific requirements. I definitely recommend the talks from Trey Grainger, from CareerBuilder. I remember seeing in some of the talks they have A/B testing built into Solr, and a lot of other “crazy” things, so it would be a good starting point, and it will provide a look on what you could accomplish by extending Solr.
Of course you’ll need to update your source between big releases of Solr, and perhaps between some minor ones, but this way you don’t need to worry about the latency or maintain a new search layer between the client and Solr. I hope it helps, On Jun 8, 2014, at 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. VII Escuela Internacional de Verano en la UCI del 30 de junio al 11 de julio de 2014. Ver www.uci.cu
