hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17339) Scan-Memory-First Optimization for Get Operation
Date Tue, 27 Dec 2016 16:44:58 GMT

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

Phil Yang commented on HBASE-17339:

In particular, replication support was deemed to be a blocker at the time.

Now we have HBASE-9465, the order can be guaranteed. But if clients also Put Cells into peer
cluster, we have two region servers generating timestamp. Unless we change the TS in entries
to local TS when peer cluster's RS receives the Cells, we still can not keep monotonicity.
But replication is asynchronous which means maybe delay a lot time. So the only solution is
synchronous replication or prevent writing to peer cluster. And we may need to distinguish
normal client writing and ReplicationSink client writing. The second one can contains a TS
while the first one can't.

> 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