Ideas for sanity checking in Solr

[tokee]

The meta-idea is to add a debug-option called "sanity". When enabled, sanity checking of options, index and general setup is performed and potential problems are reported. This Issue collects ideas for checks.

• rows > X
• maxdoc > X (X = 1.8 billion?)
• 1 huge segment, several small segments (full optimize has been issued on a non-static index)
• auto-hard/soft-commit < X ms, X correlated to index size
• facet.limit > X
• facet.limit=-1 and unique values in facet field > X
• facet.method=enum and unique values in facet field > X
• (filterCache_size * maxDoc/8) > (X * heap_size)
• facet.field=A and A is a StrField without DocValues
• Sort or group on Non-DocValued field
• Xmx > 31GB and < 40GB (32GB+ heaps uses large pointers)
• Xmx very large, relative to index size
• Xmx large and allocated memory < X * Xmx
• Xmx close to physical memory limit
• Huge auto-warm count
• Free disk space < 3x index size (minor warn)
• Free disk space < 2x index size (major warn)
• Fields with no terms
• Field with very long terms
• Single valued fields marked as multi-value
• String fields containing only numerics
• Queries with signs that should probably be other signs " vs. ” or ' vs. '
• maxWarmingSearchers > 2
• Small collections that are sharded
• Unique ID field not being stored (works standalone, not in cloud)
• q.op=AND and mm=100% should not both be set: https://issues.apache.org/jira/browse/SOLR-8812
• Search on a non-existing field: doesnotexist:anyvalue
• Searching or faceting on a field with indexed="false" docValues="true"

If each check has a telling identifier, maybe it should be possible to disable specific tests as they can be very heavy to run (such as checking whether a multi-valued field contains only single values).

[ufukyilmaz-esen]

faceting on a field with indexed="false" docValues="true"

what kind of penalty does this one have?

[tokee]

@ufukyilmaz-esen at least on the time of writing it had severe worst-case penalties with multiple shards because filtering (i.e. "Clicking on a facet") and lookups for fine counting when running multi shard required scanning through the DocValues.

Checking...

The documentation for Solr 8.8 states indexed=false" docValues="true" as a recommendation when the field is used for faceting only. That seems somewhat ambiguous: Does "faceting only" means that one only inspects the result, but never use it for filtering?

Anyway, I'm on an extended hiatus from Solr hacking so this is as far as I'm investigating now. But thanks for the interest and the critical question. Hopefully someone else can give you a better answer.

[ufukyilmaz-esen]

In our schema many fields are configured with indexed=false" docValues="true". I remember I did research for a long time before deciding to do that, but can't remember how I found relevant information.

Besides filtering (for filtering we'd use a companion copyField), field is queried in refinement phase. But afaik refinement is optional, unless you pass refine: true in facet query.

Anyways this kind of critical configs should have clear explanations in documentation. Someone may index terrabytes of data before realizing he/she had to set indexed=true for his/her use case.

[tokee]

The internals of classic Solr faceting are really messy and it does not help that both Streaming and JSON Faceting exists as alternatives. I can understand why the documentation is lacking and had I the energy, I would try and build a non-trivial multi-shard index to test indexed="false" docValues="true".

As for refine=true, I'm fairly sure it's a JSON Faceting parameter: https://issues.apache.org/jira/browse/SOLR-7452. Classic faceting always (maybe only per default in newer Solrs?) refines. Even with indexed="true" docValues="true" this comes with quite a penalty for some searches: https://sbdevel.wordpress.com/2014/09/11/even-sparse-faceting-is-limited/