question

The three caches you are most likely to interact w/ in Solr are the field cache, the document cache, and the filter cache. The field cache has been made more or less obsolete by docValues, and the document cache is disabled explicitly in DSE Search, since field values (with a couple esoteric exceptions) come from a backing Cassandra table and not Lucene. What about the filter cache?

OSS Solr's filter cache is attached to the active index searcher. When a searcher is replaced (for instance, on soft commit), the cache is cleared along with it. DSE Search uses its own filter cache implementation (called SolrFilterCache) that manages cached filters on a Lucene segment level. When a new searcher is opened on soft-commit, those segment-specific filters are preserved, and new filters must only be built for newly flushed segments.

Having said that, it's still possible to churn even the segment filter cache more than you would like. The first reason this might happen is the queries themselves. If you're going to use fq, you should be using it for things that are heavily reused and expensive to calculate. A common example here, in a retail context, would be something like a product category. Assuming reasonable query selection, it's also possible that the filter cache is simply too small to fit the desired set of filters (See https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/search/searchIndexConfig.html).

Finally, DSE Search uses the filter cache in distributed queries to limit sub-queries to individual shards/nodes to particular Cassandra token ranges, given that its Solr cores are not physically separated along those boundaries. This has, over the course of the product's lifetime, led to filter cache pollution when combined with vnodes, especially on larger clusters. (vnodes translate to more token ranges, and this means more possible token range filters.) To address this, we reworked the algorithm that selects shards during distributed queries in DSE 5.1.15, 6.0.8, and 6.7.4, introducing the STATIC set cover finder, which improves query balance across nodes and reduces the total number of token range filters that might pollute the cache by relying on client-level load balancing virtually guaranteed to already be in place (see https://docs.datastax.com/en/dse/6.7/dse-admin/datastax_enterprise/search/searchLoadBalancing.html). Essentially, if you use one of those versions or later, you should be using the STATIC set cover finder.

For general reference material on how to monitor the filter cache, see https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/mgmtServices/searchPerformance/filterCacheStatistics.html.

I hope that helps shed some light on the situation.