Eshcar Hillel commented on HBASE-16417:

bq. I don't get why reading from multiple indices ups our latency, unless the 
lookups are serial (i.e. why we need the merge).

Yes the lookups are serial. The constructor of StoreScanner invokes 
seekScanners. There are several options here depending on 2 boolean flags:
    if (isLazy) {
      for (KeyValueScanner scanner : scanners) {
        scanner.requestSeek(seekKey, false, true);
    } else {
      if (!isParallelSeek) {
        for (KeyValueScanner scanner : scanners) {
      } else {
        parallelSeek(scanners, seekKey);
So parallel seek happens only if isLazy is off and isParallelSeek is on.
However, since in the current master the memstore scanners are encapsulated in 
a single scanner (MemStoreScanner) even when the seek is parallel the seek of 
the MemStoreScanner is translated into serial seeks (actually series of peek() 
operations) of all the segment scanners when initializing the KeyValueHeap 
inside the MemStoreScanner.

This is one more reason to applying the refactoring of HBASE-17655 for removing 
the MemStoreScanner.

> In-Memory MemStore Policy for Flattening and Compactions
> --------------------------------------------------------
>                 Key: HBASE-16417
>                 URL: https://issues.apache.org/jira/browse/HBASE-16417
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Anastasia Braginsky
>            Assignee: Eshcar Hillel
>             Fix For: 2.0.0
>         Attachments: HBASE-16417-benchmarkresults-20161101.pdf, 
> HBASE-16417-benchmarkresults-20161110.pdf, 
> HBASE-16417-benchmarkresults-20161123.pdf, 
> HBASE-16417-benchmarkresults-20161205.pdf, 
> HBASE-16417-benchmarkresults-20170309.pdf, 
> HBASE-16417-benchmarkresults-20170317.pdf

This message was sent by Atlassian JIRA

Reply via email to