hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Rodionov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9751) Excessive readpoints checks in StoreFileScanner
Date Sat, 12 Oct 2013 22:36:42 GMT

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

Vladimir Rodionov commented on HBASE-9751:

Still do not understand fully. Read points are necessary to filter out all changes (deletes,
updates) that have been done  *after* scanner creation time and if isolation level is READ_COMMITTED.
Read point MUST be the attribute of a scanner - not a handler thread in this case. Correct?

Sharing the same scanner instance between handler  threads is fine if: 
A. not at the same time 
B. read point is the same (from scanner)

If it is not the case - then it looks like a flaw in the design.

And even in this case there are some situations when scanner is opened/read/closed in the
same thread in one RPC call:

1. Get request
2. Short Scans (most of them)
3. Scanner inside coprocessor call. 

> Excessive  readpoints checks in StoreFileScanner
> ------------------------------------------------
>                 Key: HBASE-9751
>                 URL: https://issues.apache.org/jira/browse/HBASE-9751
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.98.0, 0.94.12, 0.96.0
>            Reporter: Vladimir Rodionov
>            Assignee: Lars Hofhansl
>             Fix For: 0.98.0, 0.94.13, 0.96.1
>         Attachments: 9751-0.94.txt, 9751-trunk.txt
> It seems that usage of skipKVsNewerThanReadpoint in StoreFileScanner can be greatly reduced
or even eliminated all together (HFiles are immutable and no new KVs can be inserted after
scanner instance is created). The same is true for MemStoreScanner which checks readpoint
on every next() and seek(). Each readpoint check is ThreadLocal.get() and it is quite expensive.

This message was sent by Atlassian JIRA

View raw message