[
https://issues.apache.org/jira/browse/HBASE-30025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated HBASE-30025:
-----------------------------------
Labels: pull-request-available (was: )
> Wire TieredExclusiveTopology as a CombinedBlockCache-compatible
> CacheAccessService
> ----------------------------------------------------------------------------------
>
> Key: HBASE-30025
> URL: https://issues.apache.org/jira/browse/HBASE-30025
> Project: HBase
> Issue Type: New Feature
> Components: BlockCache, Performance
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Priority: Major
> Labels: pull-request-available
> Fix For: 4.0.0-alpha-1
>
>
> Wire TieredExclusiveTopology as a CombinedBlockCache-compatible
> CacheAccessService
> The pluggable block cache architecture now has the core abstractions needed
> for topology-backed cache access:
> * CacheAccessService
> * CacheTopology
> * CacheEngine
> * CachePlacementAdmissionPolicy
> * TieredExclusiveTopology
> * TopologyBackedCacheAccessService
> * BlockCacheBackedCacheEngine
> The next step is to make the topology-backed path constructible as a
> CombinedBlockCache-compatible CacheAccessService.
> Today, CombinedBlockCache coordinates an L1/L2 cache layout, typically using
> LruBlockCache as the on-heap L1 cache and BucketCache as the L2 cache. This
> behavior corresponds to an exclusive tiered topology, where a block normally
> belongs to one tier and promotion from L2 to L1 is modeled as a move.
> TieredExclusiveTopology is the intended topology model for this behavior, and
> BlockCacheBackedCacheEngine now allows existing BlockCache implementations to
> participate as CacheEngine instances before built-in caches are migrated to
> CacheEngine directly.
> This ticket should add the construction/wiring layer needed to assemble a
> topology-backed CacheAccessService from existing L1/L2 BlockCache instances.
> Proposed approach:
> * Add a helper/factory method for constructing a
> TopologyBackedCacheAccessService from existing L1 and L2 BlockCache instances.
> * Adapt the supplied BlockCache instances using BlockCacheBackedCacheEngine.
> * Assemble those engines into a TieredExclusiveTopology.
> * Use the existing/default CachePlacementAdmissionPolicy suitable for
> CombinedBlockCache-compatible behavior.
> * Add tests proving that the constructed service has the expected topology,
> engines, and policy wiring.
> * Add focused behavior tests for CombinedBlockCache-like exclusive L1/L2
> behavior, including lookup, insertion, promotion, eviction, and shutdown.
>
> Example conceptual wiring:
> {code:java}
> LruBlockCache
> -> BlockCacheBackedCacheEngine
> -> CacheEngine L1
> BucketCache
> -> BlockCacheBackedCacheEngine
> -> CacheEngine L2
> TieredExclusiveTopology(L1, L2)
> -> TopologyBackedCacheAccessService
> {code}
>
> This ticket is still a compatibility step. It should make the new
> topology-backed path available and testable, but it should not replace the
> default production CombinedBlockCache wiring unless behavior equivalence is
> explicitly proven and agreed on.
> Out of scope:
> * Do not remove CombinedBlockCache.
> * Do not remove BlockCacheFactory.
> * Do not make topology-backed service the default runtime path.
> * Do not migrate LruBlockCache, BucketCache, TinyLfuBlockCache, or
> LruAdaptiveBlockCache to implement CacheEngine directly.
> * Do not migrate diagnostics, iterator(), JSP/admin pages, or metrics.
> * Do not change existing cache placement, eviction, promotion, or runtime
> behavior.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
