Web / Apache Solr Interview questions
Explain the internal working of Solr's caching layers?
Solr keeps three main caches per searcher instance, each targeting a different part of the query lifecycle.
| Cache | What it stores | Best for |
| Filter cache | Bitset of matching doc IDs per unique fq clause | Repeated filters (category, inStock) |
| Query result cache | Ordered doc ID list for a full query+sort+params combo | Identical repeated searches, e.g. popular queries |
| Document cache | Stored field values for a document, keyed by internal Lucene doc ID | Avoiding repeated disk reads for the same doc |
All three are tied to a specific IndexSearcher instance. When a commit opens a new searcher, the old caches are discarded, which is why frequent hard commits can hurt performance - every commit throws away warm caches and starts cold.
To soften that, solrconfig.xml supports autowarming: a configured number of top entries from the old cache are re-run against the new searcher before it's swapped in, so the first queries after a commit aren't all cache misses. Because document IDs are internal to a specific segment set, the document cache in particular is invalidated on every commit and can't be autowarmed the same way filter/query caches can.
More Related questions...
