You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Vladimir Rodionov (Jira)" <ji...@apache.org> on 2026/03/25 19:18:00 UTC
[jira] [Updated] (HBASE-30018) Pluggable HBase Block Cache System
[ https://issues.apache.org/jira/browse/HBASE-30018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vladimir Rodionov updated HBASE-30018:
--------------------------------------
Description:
This umbrella tracks work to refactor the HBase block cache into a pluggable architecture with clear separation of:
• cache storage (engine)
• cache topology (L1/L2 orchestration)
• placement and admission policy
The current design tightly couples these concerns (BlockCache, CombinedBlockCache, BucketCache), making it difficult to introduce new cache implementations and evolve cache behavior.
In addition, existing implementations (e.g., BucketCache) incur significant metadata overhead at large scale (e.g., ~9GB for ~1.6TB cache with 64KB blocks), reducing effective cache capacity.
This effort introduces:
• BlockCacheEngine (storage abstraction)
• CacheTopology (tier orchestration)
• CachePlacementPolicy (admission, placement, promotion)
• explicit cache admission control on write/put path
• CacheAccessService for read/write path integration
The work will be implemented incrementally:
• Phase 1: introduce internal APIs (no behavior change)
• Phase 2: refactor existing topology (CombinedBlockCache)
• Phase 3: adapt BucketCache to new interfaces
• Phase 4: enable new engines (e.g., CarrotCache, EHCache)
This umbrella groups the individual tasks required to deliver this functionality.
RFC design doc: https://docs.google.com/document/d/1DOoRfqdDzC-Nz9zfCzSed8vbhRe5BMz8/edit?usp=sharing&ouid=107898024699489289958&rtpof=true&sd=true
was:
This umbrella tracks work to refactor the HBase block cache into a pluggable architecture with clear separation of:
• cache storage (engine)
• cache topology (L1/L2 orchestration)
• placement and admission policy
The current design tightly couples these concerns (BlockCache, CombinedBlockCache, BucketCache), making it difficult to introduce new cache implementations and evolve cache behavior.
In addition, existing implementations (e.g., BucketCache) incur significant metadata overhead at large scale (e.g., ~9GB for ~1.6TB cache with 64KB blocks), reducing effective cache capacity.
This effort introduces:
• BlockCacheEngine (storage abstraction)
• CacheTopology (tier orchestration)
• CachePlacementPolicy (admission, placement, promotion)
• explicit cache admission control on write/put path
• CacheAccessService for read/write path integration
The work will be implemented incrementally:
• Phase 1: introduce internal APIs (no behavior change)
• Phase 2: refactor existing topology (CombinedBlockCache)
• Phase 3: adapt BucketCache to new interfaces
• Phase 4: enable new engines (e.g., CarrotCache)
This umbrella groups the individual tasks required to deliver this functionality.
RFC design doc: https://docs.google.com/document/d/1DOoRfqdDzC-Nz9zfCzSed8vbhRe5BMz8/edit?usp=sharing&ouid=107898024699489289958&rtpof=true&sd=true
> Pluggable HBase Block Cache System
> ----------------------------------
>
> Key: HBASE-30018
> URL: https://issues.apache.org/jira/browse/HBASE-30018
> Project: HBase
> Issue Type: Umbrella
> Components: BlockCache
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Priority: Major
>
> This umbrella tracks work to refactor the HBase block cache into a pluggable architecture with clear separation of:
> • cache storage (engine)
> • cache topology (L1/L2 orchestration)
> • placement and admission policy
> The current design tightly couples these concerns (BlockCache, CombinedBlockCache, BucketCache), making it difficult to introduce new cache implementations and evolve cache behavior.
> In addition, existing implementations (e.g., BucketCache) incur significant metadata overhead at large scale (e.g., ~9GB for ~1.6TB cache with 64KB blocks), reducing effective cache capacity.
> This effort introduces:
> • BlockCacheEngine (storage abstraction)
> • CacheTopology (tier orchestration)
> • CachePlacementPolicy (admission, placement, promotion)
> • explicit cache admission control on write/put path
> • CacheAccessService for read/write path integration
> The work will be implemented incrementally:
> • Phase 1: introduce internal APIs (no behavior change)
> • Phase 2: refactor existing topology (CombinedBlockCache)
> • Phase 3: adapt BucketCache to new interfaces
> • Phase 4: enable new engines (e.g., CarrotCache, EHCache)
> This umbrella groups the individual tasks required to deliver this functionality.
> RFC design doc: https://docs.google.com/document/d/1DOoRfqdDzC-Nz9zfCzSed8vbhRe5BMz8/edit?usp=sharing&ouid=107898024699489289958&rtpof=true&sd=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)