[
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)
