hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Bortnikov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17339) Scan-Memory-First Optimization for Get Operation
Date Wed, 28 Dec 2016 07:46:58 GMT

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

Edward Bortnikov commented on HBASE-17339:

[~davelatham], [~yangzhe1991] - thanks for pointing out the historical context. Indeed, the
idea will not work in peer clusters with concurrent updates. However, it seems that there
are enough interesting use cases that deserve treatment. 

This optimization is complementary to in-memory flush & compaction (see HBASE-14918).
The latter brings its own value, but in conjunction the two produce very impressive reduction
in read latency. [~eshcar], maybe you could attach some perf results? Thanks.  

> Scan-Memory-First Optimization for Get Operation
> ------------------------------------------------
>                 Key: HBASE-17339
>                 URL: https://issues.apache.org/jira/browse/HBASE-17339
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Eshcar Hillel
>         Attachments: HBASE-17339-V01.patch
> 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

View raw message