[
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:
-----------------------------------
bq.
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
(v6.3.4#6332)
