Best practices to debug Solr search in production without all fields stored

Hi everyone, I found it convenient to debug Solr search results if I mark all fields to be "stored=true" in schema. For example, given a document, I could check why it is not returned in a query with debug=true. But in production, most of the fields have "stored=false" for performance re

Re: Restarting SolrCloud that is taking realtime updates

ollections so you can manipulate the current cold one and, when you're satisfied, switch the alias. > > Best, Erick > > On Fri, Nov 25, 2016 at 1:40 PM, Jichi Guo wrote: > Hi, > > > > I am seeking for the best practice to restart a sharded SolrCloud

Restarting SolrCloud that is taking realtime updates

Hi, I am seeking for the best practice to restart a sharded SolrCloud that taking search traffic as well as realtime updates without downtime. When I deploy new customized Solr plugins,for example, it will require restarting the whole SolrCloud cluster. I am testing Solr 6.2.1 with 4 shards.

Re: How to speed up field collapsing on large number of groups

Hi everyone, Is it possible to optimize collapsing on large index through parallelization without sharding? Or can we conclude that sharding is currently the only approach to geometrically speedup slow collapsing queries? I tried manually parallelizing CollapsingQParserPlugin by diff

Re: How to speed up field collapsing on large number of groups

Thanks for the quick response, Joel! I am hoping to delay sharding if possible, which might involve more things to consider :) 1) What is the size of the result set before the collapse? When search with q=*:* for example, before collapse numFound is around 5 million, and that after col