[
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
