[jira] [Comment Edited] (HBASE-17339) Scan-Memory-First Optimization for Get Operation

2016-12-28 Thread Eshcar Hillel (JIRA)

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

Eshcar Hillel edited comment on HBASE-17339 at 12/28/16 7:19 PM:
-

We can use existing TRT, no need for a new one. Only need to remember the 
maximal flushed TS so far and make sure the range in TRT is beyond this TS.

The protocol including step-0 is for each operation:

{code}
 0. check monotonicity in all relevant stores
if monotonicity is maintained and the optimization is applicable (given list of 
columns) then
 1. open all relevant  *memory* scanners
 2. get results
 ONLY if result is not complete then
  3. open all scanners
  4. get results
else
 5. open all scanners
 6. get results
{code}

possible executions are 0-1-2, 0-1-2-3-4, 0-5-6, the operation returns the 
result of step 2 (access only memory) or steps 4/6 (access memory and HFiles)


was (Author: eshcar):
We can use existing TRT, no need for a new one. Only need to remember the 
maximal flushed TS so far and make sure the range in TRT is beyond this TS.

The protocol including step-0 is for each step:

{code}
 0. check monotonicity in all relevant stores
if monotonicity is maintained and the optimization is applicable (given list of 
columns) then
 1. open all relevant  *memory* scanners
 2. get results
 ONLY if result is not complete then
  3. open all scanners
  4. get results
else
 5. open all scanners
 6. get results
{code}

possible executions are 0-1-2, 0-1-2-3-4, 0-5-6, the operation returns the 
result of step 2 (access only memory) or steps 4/6 (access memory and HFiles)

> 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)


[jira] [Comment Edited] (HBASE-17339) Scan-Memory-First Optimization for Get Operation

2016-12-27 Thread Phil Yang (JIRA)

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

Phil Yang edited comment on HBASE-17339 at 12/27/16 4:44 PM:
-

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.


was (Author: yangzhe1991):
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)