[
https://issues.apache.org/jira/browse/HBASE-8894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783370#comment-13783370
]
Alex Feinberg commented on HBASE-8894:
--------------------------------------
Keep in mind that this is itself based on HBASE-7404. Since I wanted to get
this out the door quickly, I kept some of the package/class names similar to
original HBase-7404 -- so we'd want to rename them.
The big differences is that I've removed any kind of SerDe and changed the
flow. Now the flow is:
Read:
1. Check if item is in smaller L1 block cache (traditional BlockCache in JVM
heap)
2. If not, check if it's in L2 cache
3. Otherwise, go to disk
Flush:
1. Write the already compressed and serialized data to L2 cache along with disk.
Basically, here L2 cache replaces the OS page cache and allows for a smaller L1
cache. This should help performance in several ways:
1. Compared to page-cache, there's ability (using an map I keep) to evict all
the blocks associated with a given file when it's compacted. There's also no
page cache pollution as a result of compaction reads, or HDFS replication
traffic (already a 3X gain in efficiency). The latter, however, is also true
for HBASE-7404.
2. Compared to HBASE-7404, there's ability to keep very hot blocks (both data
and meta blocks) in the regular BlockCache, which becomes the L1 cache. That
avoids serialization costs for those blocks, unlike only keeping
meta-blocks/keeping all blocks in the compressed/serialized cache
Basically this gives you a "better page cache" (potentially persistent if other
IO engines are introduced, finer grained evictions/control than fadvise,
etc...). The proper ratio of L1 to L2 cache (including the direct memory
available for JVM's use vs. JVM GC'd heap size) is still to be determined, but
there's some math that can be done on this based on things like expected cache
hit ratios and costs of hits/misses to different caches.
There's also few other low hanging fruits that could be changed in my diff:
* Sending blocks evicted from L1 directly to L2
* Evicting blocks from the L2 cache upon promotion to the L1 cache
* Porting and testing the file based IO engine (e.g., for fusionIO cards)
Thanks!
- af
> Forward port compressed l2 cache from 0.89fb
> --------------------------------------------
>
> Key: HBASE-8894
> URL: https://issues.apache.org/jira/browse/HBASE-8894
> Project: HBase
> Issue Type: New Feature
> Reporter: stack
> Assignee: Liang Xie
> Priority: Critical
> Fix For: 0.98.0
>
>
> Forward port Alex's improvement on hbase-7407 from 0.89-fb branch:
> {code}
> 1 r1492797 | liyin | 2013-06-13 11:18:20 -0700 (Thu, 13 Jun 2013) | 43 lines
> 2
> 3 [master] Implements a secondary compressed cache (L2 cache)
> 4
> 5 Author: avf
> 6
> 7 Summary:
> 8 This revision implements compressed and encoded second-level cache with
> off-heap
> 9 (and optionally on-heap) storage and a bucket-allocator based on
> HBASE-7404.
> 10
> 11 BucketCache from HBASE-7404 is extensively modified to:
> 12
> 13 * Only handle byte arrays (i.e., no more serialization/deserialization
> within)
> 14 * Remove persistence support for the time being
> 15 * Keep an index of hfilename to blocks for efficient eviction on close
> 16
> 17 A new interface (L2Cache) is introduced in order to separate it from the
> current
> 18 implementation. The L2 cache is then integrated into the classes that
> handle
> 19 reading from and writing to HFiles to allow cache-on-write as well as
> 20 cache-on-read. Metrics for the L2 cache are integrated into
> RegionServerMetrics
> 21 much in the same fashion as metrics for the existing (L2) BlockCache.
> 22
> 23 Additionally, CacheConfig class is re-refactored to configure the L2
> cache,
> 24 replace multile constructors with a Builder, as well as replace static
> methods
> 25 for instantiating the caches with abstract factories (with singleton
> 26 implementations for both the existing LruBlockCache and the newly
> introduced
> 27 BucketCache based L2 cache)
> 28
> 29 Test Plan:
> 30 1) Additional unit tests
> 31 2) Stress test on a single devserver
> 32 3) Test on a single-node in shadow cluster
> 33 4) Test on a whole shadow cluster
> 34
> 35 Revert Plan:
> 36
> 37 Reviewers: liyintang, aaiyer, rshroff, manukranthk, adela
> 38
> 39 Reviewed By: liyintang
> 40
> 41 CC: gqchen, hbase-eng@
> 42
> 43 Differential Revision: https://phabricator.fb.com/D837264
> 44
> 45 Task ID: 2325295
> 7 ------------------------------------------------------------------------
> 6 r1492340 | liyin | 2013-06-12 11:36:03 -0700 (Wed, 12 Jun 2013) | 21 lines
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
