hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rutherglen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4018) Attach memcached as secondary block cache to regionserver
Date Thu, 23 Jun 2011 23:44:47 GMT

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

Jason Rutherglen commented on HBASE-4018:
-----------------------------------------

bq. Some applications can also be CPU bound

The main user of CPU with HBase should be [de]compression?  In just browsing the BigTable
paper, they mention caching individual key-values for applications that require random reads.
 If an application is more scan oriented, then the block cache makes sense for the duration
of the scan of that block.  The paper also goes on to describe compression per-row vs. per-block.

bq. That's one of the major motivations for an hbase-specific "prefix" compression algorithm

However that's only for keys which is a separate discussion.

> Attach memcached as secondary block cache to regionserver
> ---------------------------------------------------------
>
>                 Key: HBASE-4018
>                 URL: https://issues.apache.org/jira/browse/HBASE-4018
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: Li Pi
>            Assignee: Li Pi
>
> Currently, block caches are limited by heap size, which is limited by garbage collection
times in Java.
> We can get around this by using memcached w/JNI as a secondary block cache. This should
be faster than the linux file system's caching, and allow us to very quickly gain access to
a high quality slab allocated cache.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message