Some indices are primarily used for point lookups, such as the RDF ID2TERM index. In fact, the ID2TERM index is modeled as a B+Tree primarily because that is the hammer that we are using for everything -- bigdata btrees are designed to scale-out dynamically and incrementally over variable amounts of hardware. It is harder to do that with Distributed Hash Tables (DHTs).
Such indices can benefit from a hash map cache in front of the index to reduce key search time in the B+Tree. This should be an option in the IndexMetadata. When enabled, the B+Tree shard would maintain a local LRU/LIRS cache from the B+Tree key to the B+Tree value.
Ideally, cache evictions would be managed based on an approximate total cache access order shared with the LRUNexus such that evictions can be driven by heap usage. This will require some more generalization of the IGlobalLRU and the LRUNexus since different types of caches would now compete for the same heap resources.
Since indices such as ID2TERM are accessed from within JOINs (or will be once we have foreign key joins working) the cache really needs to be local to the B+Tree shard rather than in front of the bigdata federation.