[
https://issues.apache.org/jira/browse/HBASE-30019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov resolved HBASE-30019.
---------------------------------------
Fix Version/s: 4.0.0-alpha-1
Resolution: Implemented
> Introduce CacheEngine and CacheTopology abstractions (no behavior change)
> -------------------------------------------------------------------------
>
> Key: HBASE-30019
> URL: https://issues.apache.org/jira/browse/HBASE-30019
> 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
>
>
> h2. Description
> Introduce core internal abstractions for a pluggable block cache architecture.
> The goal of this change is to establish clear separation of concerns between
> storage, orchestration, and future policy layers by introducing the following
> foundational abstractions:
> * *CacheEngine* — storage abstraction for cache backends (e.g.,
> LruBlockCache, BucketCache)
> * *CacheTopology* — L1/L2 orchestration and coordination layer
> * request/write context objects to support future decoupling of read/write
> paths from cache implementations
> This change is purely architectural and does not modify existing behavior.
> h3. Scope
> * Introduce *CacheEngine* interface defining core cache operations:
> ** block lookup
> ** block insertion
> ** invalidation
> ** capacity/usage reporting
> ** stats exposure
> * Introduce *CacheTopology* abstraction for coordinating multiple cache tiers:
> ** define topology interface (no functional changes yet)
> ** provide minimal/default implementation if needed
> * Introduce context objects to support future API evolution:
> ** request context (read path)
> ** write context (cache population)
> ** invalidation context (file lifecycle events)
> * Ensure new abstractions are not yet wired into existing call sites:
> ** no changes to HFileReaderImpl
> ** no changes to write path
> ** no changes to CombinedBlockCache logic
> h3. Notes
> * No behavior change intended
> * Existing cache implementations (*LruBlockCache*, *BucketCache*,
> *CombinedBlockCache*) remain unchanged
> * Current call paths continue to use *BlockCache* directly
> * This is a foundation step enabling future work:
> ** introduction of CacheAccessService
> ** migration of call sites
> ** extraction of topology from CombinedBlockCache
> ** introduction of placement/admission policy
> ** refactoring of cache implementations into CacheEngine
> * This ticket should remain minimal and low-risk to simplify review and
> establish the architectural baseline
--
This message was sent by Atlassian Jira
(v8.20.10#820010)