@Walter Usually you have: client-app --> random-solr-node(mergerer) --> each other node that has a shard While what I want: client-app (mergerer is in same jvm) --> each other node that has a shard
Makes sense ? On Wed, Apr 19, 2017 at 4:50 PM, Walter Underwood <[email protected]> wrote: > Does not make sense to me. It would do more queries from the client to the > cluster, not fewer. And those HTTP request would probably be slower than > the intra-cluster requests. > > I expect the distributed portion of the query load is small compared to > other CPU usage. > > It adds complexity for no gain in performance. Maybe a slight loss. > > wunder > Walter Underwood > [email protected] > http://observer.wunderwood.org/ (my blog) > > > On Apr 19, 2017, at 6:32 AM, Mikhail Khludnev <[email protected]> wrote: > > Hello, Dorian. > I'm not sure about 1. But you can create EmbeddedSolrServer and add > "collection" parameter. It's what's done in > org.apache.solr.response.transform.SubQueryAugmenter > [subquery] > > On Wed, Apr 19, 2017 at 3:53 PM, Dorian Hoxha <[email protected]> > wrote: > >> Hi friends, >> >> Anybody has done this ? Reasons being: 1 less http-request when doing >> distributed search. But also not storing data itself (like a >> search-only-node). And the other nodes not caring about search-nodes. >> >> Makes sense ? >> >> Regards, >> Dorian >> > > > > -- > Sincerely yours > Mikhail Khludnev > > >
