SOLR-16667: LTR Add feature vector caching for ranking

[aruggero]

https://issues.apache.org/jira/browse/SOLR-16667

Description

The current definition and usage of the QUERY_DOC_FV feature cache has been modified to support both reranking and logging.

Solution

• The cache has been defined in the SolrConfig as the filter cache, the query result cache etc..
• Lookups and insertions in the cache have been integrated in both reranking and logging phases.

Tests

Tests have been added in the solr/modules/ltr/src/test/org/apache/solr/ltr/TestFeatureVectorCache.java file.
The tests check for the correct cache usage and response in different scenarios, considering the ltr parameters: logAll, store, efis... and their defaults.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[alessandrobenedetti]

There are some changes and some discussions to do, then I'll review the tests!

[aruggero]

We have finished the review iterations, and the code is open to further suggestions and revisions. In the meantime, I am running a benchmark to report the performance of the new contribution compared to the current implementation.

[alessandrobenedetti]

Aside some minors, we are ready to merge, just waiting for main to be stable

[aruggero]

As mentioned, I report here the results of the benchmark that has been done:

We compared the current main branch containing the FV_cache for LTR with our contributed cache. We have also done a test in both situations with all caches with zero size to be sure not to slow down the query execution when not using caches at all.

The first column represents the difference in milliseconds between the first query (no cache hit - miss than insert) and the second query (cache hit). The higher, the better, since it means that the cache has a great impact on reducing the query execution time.

The second column represents the average time taken to execute the first query in milliseconds (the one that does not find any entry - miss than insert).

The third column represents the average time taken to execute the second query in milliseconds (the one that finds an entry - hit).

Finally, the last columns are the cache statistics from the Solr UI.

We executed 10 pairs of queries (the first having a miss, the second a hit in the cache), each retrieving 10000 documents.
We uploaded a feature store of 200 features and use a linear model that exploits these 200 features.

All the results are positive. We obtain a slightly slower result when doing the "miss" query during pure reranking, but we still have a comparable query execution time.

A detailed blog post about this will follow on sease.io