Optimized Persisted Cache for Cardinality Queries

[keski]

Description

To improve performance and scalability in cardinality queries, an optimized persisted cache with eviction policies will be implemented. Below follows the requirements that should be supported, along with a proposed order of implementation.

Requirements

• Persistence: It must be able to store cached data on disk to survive restarts.
• Concurrent access from multiple JVMs: It must be possible to execute queries in parallel using, e.g., hefquin-cli. This means that the solution cannot assume a single-JVM access pattern, since if multiple JVMs attempt to access the same file can lead to file corruption or locking issues.
• Eviction Policies: It must support eviction policies that apply if the cache reaches its maximum size, e.g., LRU, LFU, or FIFO.
• Time-Based Expiration (TTL, time-to-live): It must support time-based expiration that automatically invalidates cache entries after a given amount of time, as well as manual invalidation. Evicted items should be removed from both in-memory and persistent stores.

Approach

Following a review of possible approaches, the implementation will use a hybrid approach combining Chronicle Map (persistence) and Caffeine (in-memory). Chronicle Map supports persistence and access from multiple JVMs but does not support eviction policies och time-based expiration. Caffeine an efficient in-memory caching library with support for eviction and time-based invalidation policies.

Implementation steps

1. Persisted cache based onChronicleMap (no eviction policies, no time-based invalidation) + tests
2. In-memory cache on top of ChronicleMap based on Caffeine (eviction policy, time-based invalidation) + tests
3. Restore in-memory cache from ChronicleMap with timestamped keys + tests