[ 
https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124834#comment-17124834
 ] 

Anoop Sam John commented on HBASE-23296:
----------------------------------------

The way we can introduce that can be this way (I believe that is what mostly 
the patch is doing).  
1. We can have a combined cache as that of today - No change.
   There will be on heap LRU cache for which size is defined as % of Xmx. Then 
there can be Bucket Cache on either offheap or file. Here all index and bloom 
goes to on heap cache and data goes to bucket cache.
2. Allow 2 tier in Bucket Cache itself. I would recommend not using the term L1 
and L2 here (even in configs) so that it is clear what it does. The tier 1 can 
be off heap (will be mostly) and tier 2 will be file based. Now if this is 
configured, nothing will go to the on heap cache. In fact user should be able 
to config the on heap block cache size % as 0. Even if configured a value, 
there is no usage. We at least need to log that very clearly.  And here the 
index and bloom will go to tier 1 and data to tier 2.   I believe right now if 
we have block cache % as 0, we will not even create the bucket cache.  The RS 
can not have a bucket cache alone thing.  This we need to change in code.

This 2 types might be enough for this jira. But I would like to see a 3rd type 
where the tiered Bucket cache can be configured as L1, L2 way. (Like what we 
have in 1.x with CombinedCache)  The tier 1 will become L1 and tier 2 will be 
L2 cache for all types of blocks. 

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

Reply via email to