[
https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932319#comment-15932319
]
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:
{code}
if (isLazy) {
for (KeyValueScanner scanner : scanners) {
scanner.requestSeek(seekKey, false, true);
}
} else {
if (!isParallelSeek) {
for (KeyValueScanner scanner : scanners) {
...
scanner.seek(seekKey);
...
} else {
parallelSeek(scanners, seekKey);
}
}
{code}
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
(v6.3.15#6346)
