[
https://issues.apache.org/jira/browse/HBASE-30305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-30305:
--------------------------------------
Description:
h3. Description
HBASE-30024 introduced BlockCacheBackedCacheEngine, allowing existing BlockCache
implementations to participate as CacheEngine instances.
HBASE-30025 added the construction path for creating a
TopologyBackedCacheAccessService
from existing L1 and L2 BlockCache instances using TieredExclusiveTopology.
The next step is to replace CombinedBlockCache as the primary L1/L2
orchestration object
used by CacheAccessService.
Today, the combined block cache path is assembled as:
LruBlockCache + BucketCache
-> CombinedBlockCache
-> BlockCacheBackedCacheAccessService
This ticket should change the CacheAccessService construction path to use:
LruBlockCache + BucketCache
-> BlockCacheBackedCacheEngine
-> TieredExclusiveTopology
-> TopologyBackedCacheAccessService
CombinedBlockCache should not be removed in this ticket. It should remain
available for
legacy APIs, diagnostics, tests, and any code paths that still require a
BlockCache instance.
However, new cache access should no longer depend on CombinedBlockCache for
tiered
orchestration.
The goal is to make TieredExclusiveTopology the primary orchestration model for
the
combined L1/L2 cache path while preserving existing behavior and keeping
CombinedBlockCache
as a compatibility object.
h3. Scope
* Change CacheConfig / BlockCacheFactory construction so CacheAccessService
for combined
L1/L2 cache uses TopologyBackedCacheAccessService.
* Reuse TopologyBackedCacheAccessServices.fromTieredExclusiveBlockCaches(...).
* Keep LruBlockCache and BucketCache as existing BlockCache implementations
underneath.
* Keep CombinedBlockCache class in the source tree.
* Keep any existing BlockCache-returning APIs working if they still need to
expose a
CombinedBlockCache or legacy BlockCache view.
* Add tests proving the CacheAccessService path no longer wraps
CombinedBlockCache when
L1/L2 combined cache is enabled.
* Add compatibility tests proving the old BlockCache view, if still exposed,
remains usable.
h3. Out of scope
* Do not delete CombinedBlockCache.
* Do not migrate LruBlockCache or BucketCache to implement CacheEngine
directly yet.
* Do not remove BlockCacheBackedCacheAccessService.
* Do not migrate JSP/admin diagnostics yet unless required by compilation.
* Do not remove CombinedBlockCache tests yet.
was:
h3. Description
HBASE-30024 introduced BlockCacheBackedCacheEngine, allowing existing BlockCache
implementations to participate as CacheEngine instances.
HBASE-30025 added the construction path for creating a
TopologyBackedCacheAccessService
from existing L1 and L2 BlockCache instances using TieredExclusiveTopology.
The next step is to replace CombinedBlockCache as the primary L1/L2
orchestration object
used by CacheAccessService.
Today, the combined block cache path is assembled as:
LruBlockCache + BucketCache
-> CombinedBlockCache
-> BlockCacheBackedCacheAccessService
This ticket should change the CacheAccessService construction path to use:
LruBlockCache + BucketCache
-> BlockCacheBackedCacheEngine
-> TieredExclusiveTopology
-> TopologyBackedCacheAccessService
CombinedBlockCache should not be removed in this ticket. It should remain
available for
legacy APIs, diagnostics, tests, and any code paths that still require a
BlockCache instance.
However, new cache access should no longer depend on CombinedBlockCache for
tiered
orchestration.
The goal is to make TieredExclusiveTopology the primary orchestration model for
the
combined L1/L2 cache path while preserving existing behavior and keeping
CombinedBlockCache
as a compatibility object.
h3. Scope
* Change CacheConfig / BlockCacheFactory construction so CacheAccessService for
combined
L1/L2 cache uses TopologyBackedCacheAccessService.
* Reuse TopologyBackedCacheAccessServices.fromTieredExclusiveBlockCaches(...).
* Keep LruBlockCache and BucketCache as existing BlockCache implementations
underneath.
* Keep CombinedBlockCache class in the source tree.
* Keep any existing BlockCache-returning APIs working if they still need to
expose a
CombinedBlockCache or legacy BlockCache view.
* Add tests proving the CacheAccessService path no longer wraps
CombinedBlockCache when
L1/L2 combined cache is enabled.
* Add compatibility tests proving the old BlockCache view, if still exposed,
remains usable.
h3. Out of scope
* Do not delete CombinedBlockCache.
* Do not migrate LruBlockCache or BucketCache to implement CacheEngine directly
yet.
* Do not remove BlockCacheBackedCacheAccessService.
* Do not migrate JSP/admin diagnostics yet unless required by compilation.
* Do not remove CombinedBlockCache tests yet.
> Replace CombinedBlockCache orchestration with TieredExclusiveTopology-backed
> CacheAccessService
> -----------------------------------------------------------------------------------------------
>
> Key: HBASE-30305
> URL: https://issues.apache.org/jira/browse/HBASE-30305
> Project: HBase
> Issue Type: New Feature
> Components: BlockCache, Performance
> Affects Versions: 4.0.0-alpha-1
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Priority: Major
>
> h3. Description
> HBASE-30024 introduced BlockCacheBackedCacheEngine, allowing existing
> BlockCache
> implementations to participate as CacheEngine instances.
> HBASE-30025 added the construction path for creating a
> TopologyBackedCacheAccessService
> from existing L1 and L2 BlockCache instances using TieredExclusiveTopology.
> The next step is to replace CombinedBlockCache as the primary L1/L2
> orchestration object
> used by CacheAccessService.
> Today, the combined block cache path is assembled as:
> LruBlockCache + BucketCache
> -> CombinedBlockCache
> -> BlockCacheBackedCacheAccessService
> This ticket should change the CacheAccessService construction path to use:
> LruBlockCache + BucketCache
> -> BlockCacheBackedCacheEngine
> -> TieredExclusiveTopology
> -> TopologyBackedCacheAccessService
> CombinedBlockCache should not be removed in this ticket. It should remain
> available for
> legacy APIs, diagnostics, tests, and any code paths that still require a
> BlockCache instance.
> However, new cache access should no longer depend on CombinedBlockCache for
> tiered
> orchestration.
> The goal is to make TieredExclusiveTopology the primary orchestration model
> for the
> combined L1/L2 cache path while preserving existing behavior and keeping
> CombinedBlockCache
> as a compatibility object.
> h3. Scope
> * Change CacheConfig / BlockCacheFactory construction so CacheAccessService
> for combined
> L1/L2 cache uses TopologyBackedCacheAccessService.
> * Reuse
> TopologyBackedCacheAccessServices.fromTieredExclusiveBlockCaches(...).
> * Keep LruBlockCache and BucketCache as existing BlockCache implementations
> underneath.
> * Keep CombinedBlockCache class in the source tree.
> * Keep any existing BlockCache-returning APIs working if they still need to
> expose a
> CombinedBlockCache or legacy BlockCache view.
> * Add tests proving the CacheAccessService path no longer wraps
> CombinedBlockCache when
> L1/L2 combined cache is enabled.
> * Add compatibility tests proving the old BlockCache view, if still exposed,
> remains usable.
> h3. Out of scope
> * Do not delete CombinedBlockCache.
> * Do not migrate LruBlockCache or BucketCache to implement CacheEngine
> directly yet.
> * Do not remove BlockCacheBackedCacheAccessService.
> * Do not migrate JSP/admin diagnostics yet unless required by compilation.
> * Do not remove CombinedBlockCache tests yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
