[
https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116573#comment-17116573
]
chenxu commented on HBASE-23296:
--------------------------------
Hi, [~anoop.hbase] [~ram_krish], thanks for your review about the doc.
{quote}Are we proposing doing this? Or just the above one?
{quote}
Currently, we implement the above only. Not sure if it’s valuable for the below
diagram.
{quote}Or should we even allow this model to act like today's CombinedCache
model?
{quote}
I’d like this model, in our case we want warmup all the index and blooms, even
the data cache miss, just one seek is enough.
But if the index and bloom miss, we may need three seeks. So only index/bloom
go to L1 may be suitable. The current path do things like this.
> Add CompositeBucketCache to support tiered BC
> ---------------------------------------------
>
> Key: HBASE-23296
> URL: https://issues.apache.org/jira/browse/HBASE-23296
> Project: HBase
> Issue Type: New Feature
> Components: BlockCache
> Reporter: chenxu
> Assignee: chenxu
> Priority: Major
>
> LruBlockCache is not suitable in the following scenarios:
> (1) cache size too large (will take too much heap memory, and
> evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned)
> (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are
> enabled.
> Since block‘s data is reclaimed by GC, this may affect GC performance.
> So how about enabling a Bucket based L1 Cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
