[
https://issues.apache.org/jira/browse/HBASE-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943102#comment-15943102
]
Eshcar Hillel commented on HBASE-17339:
---------------------------------------
Yes, sure I can run with your patch [~ben.manes] :)
I just wonder if you have any insight on wether or not tinyLFU *can* help
before testing it.
So far memstore was considered the write cache and block cache the read cache.
The optimization makes memstore a first tier read cache and block cache a
second tier read cache. So with zipfian distribution the head of the
distribution is found in memstore and the tail is searched in the block cache.
With the current LRU cache we see the same number of eviction from the cache
with and without the optimization.
Do you think tinyLFU can do a better job in managing the blocks with smarter
admission-eviction so the hit rate is increased? Or since this is dealing with
the "torso" and not the head of the distribution can't do better job?
> Scan-Memory-First Optimization for Get Operations
> -------------------------------------------------
>
> Key: HBASE-17339
> URL: https://issues.apache.org/jira/browse/HBASE-17339
> Project: HBase
> Issue Type: Improvement
> Reporter: Eshcar Hillel
> Assignee: Eshcar Hillel
> Attachments: HBASE-17339-V01.patch, HBASE-17339-V02.patch,
> HBASE-17339-V03.patch, HBASE-17339-V03.patch, HBASE-17339-V04.patch,
> HBASE-17339-V05.patch, HBASE-17339-V06.patch, read-latency-mixed-workload.jpg
>
>
> The current implementation of a get operation (to retrieve values for a
> specific key) scans through all relevant stores of the region; for each store
> both memory components (memstores segments) and disk components (hfiles) are
> scanned in parallel.
> We suggest to apply an optimization that speculatively scans memory-only
> components first and only if the result is incomplete scans both memory and
> disk.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
