lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Meraj A. Khan" <mera...@gmail.com>
Subject Re: Customizing Solr; Where to draw the line?
Date Mon, 09 Jun 2014 05:56:25 GMT
Phanindra.


1. I had no such need , the index was built from scratch.
2. Yes , I created a new URL and mapped it to the customized search handler.
3. The only thing I modified was the SearchHandler and specified that as
the class for newly created URL in #2 above.

Hope this helps.


On Mon, Jun 9, 2014 at 12:22 AM, Phanindra R <phaninra@gmail.com> wrote:

> Thanks for the reply Meraj. It'd be great if you could share info on
> following as well.
>
> 1) Did you have to load any stuff from database? How did you do that?
>
> 2) Did you create new urls and map them to your custom handlers?
>
> 3) Did you declare any custom object types in the solr-config.xml i.e.
> other than <searchComponent>, <queryParser>, etc.
>
>
> On Sun, Jun 8, 2014 at 7:42 PM, Meraj A. Khan <merajak@gmail.com> wrote:
>
> > 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" <phaninra@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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message