[
https://issues.apache.org/jira/browse/HBASE-30019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-30019:
--------------------------------------
Description:
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
was:
h2. Description
Introduce core internal abstractions for a pluggable block cache architecture:
* *CacheEngine* — storage abstraction for cache backends
* *CacheTopology* — L1/L2 orchestration and coordination layer
* request/write context objects
This change is strictly architectural and introduces new APIs without altering
existing behavior.
h3. Notes
* No behavior change intended
* Existing cache implementations (*LruBlockCache*, *BucketCache*) continue to
work as-is
* No changes to current call sites (*BlockCache* usage remains unchanged)
* Serves as the foundation for subsequent refactoring and migration steps
> 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
>
> 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)
