[
https://issues.apache.org/jira/browse/HBASE-30025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-30025:
--------------------------------------
Description:
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.
was:
h2. Description
Add support for an explicit *TieredInclusiveTopology* as an alternative cache
topology for coordinating L1 and L2 cache tiers.
In an inclusive topology, blocks present in the upper tier (L1) are also
retained in the lower tier (L2). This differs from the existing exclusive
behavior (modeled by *TieredExclusiveTopology*), where a block resides in only
one tier at a time.
h3. Scope
* Introduce *TieredInclusiveTopology* implementing L1/L2 coordination with
inclusive semantics
* Implement lookup behavior:
** check L1 first, then L2 on miss
* Implement promotion behavior:
** on L2 hit, copy block into L1 while retaining it in L2
* Define eviction behavior:
** eviction from L1 does not affect L2
* Integrate with existing topology abstraction (*CacheTopology*)
h3. Notes
* No change to default behavior — *TieredExclusiveTopology* remains the default
configuration
* Existing cache implementations (*LruBlockCache*, *BucketCache*) remain
unchanged
* This topology is introduced primarily for flexibility and experimentation
* Enables evaluation of different trade-offs between:
** memory efficiency (exclusive)
** simplicity and stability (inclusive)
> 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
> 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)
