Can we still specify the cache implementation for the field cache? When this change occurred to faceting (uninverting reader vs field ) it prevented us from moving to 5.x but if we can get the 4.x functionality using that api we could look to port to the latest.
Jamie On Dec 17, 2015 9:18 AM, "Yonik Seeley" <ysee...@gmail.com> wrote: > On Wed, Dec 16, 2015 at 4:57 AM, Vincenzo D'Amore <v.dam...@gmail.com> > wrote: > > Hi all, > > > > given that solr 5.4 is finally released, is this what's more stable and > > efficient version of solrcloud ? > > > > I have a website which receives many search requests. It serve normally > > about 2000 concurrent requests, but sometime there are peak from 4000 to > > 10000 requests in few seconds. > > > > On January I'll have a chance to upgrade my old SolrCloud 4.8.1 cluster > to > > a new brand version, but following this thread I read about the problems > > that can occur upgrading to latest version. > > > > I have seen that issue SOLR-7730 "speed-up faceting on doc values fields" > > is fixed in 5.4. > > > > I'm using standard faceting without docValues. Should I add docValues in > > order to benefit of such fix? > > You'll have to try it I think... > DocValues have a lot of advantages (much less heap consumption, and > much smaller overhead when opening a new searcher), but they can often > be slower as well. > > Comparing 4x to 5x non-docvalues, top-level field caches were removed > by lucene, and while that benefits certain things like NRT (opening a > new searcher very often), it will hurt performance for other > configurations. > > The JSON Facet API currently allows you to pick your strategy via the > "method" param for multi-valued string fields without docvalues: > "uif" (UninvertedField) gets you the top-level strategy from Solr 4, > while "dv" (DocValues built on-the-fly) gets you the NRT-friendly > "per-segment" strategy. > > -Yonik >
