You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "chenxu (Jira)" <ji...@apache.org> on 2020/05/26 09:49:00 UTC
[jira] [Comment Edited] (HBASE-23296) Add CompositeBucketCache to
support tiered BC
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116573#comment-17116573 ]
chenxu edited comment on HBASE-23296 at 5/26/20, 9:48 AM:
----------------------------------------------------------
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 patch do things like this.
was (Author: javaman_chen):
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)