[jira] Commented: (HBASE-3636) a bug about deciding whether this key is a new key for the ROWCOL bloomfilter

["stack (JIRA)" <ji...@apache.org>]

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

stack commented on HBASE-3636:
------------------------------

Do you have patch please Liyin Tang?  Thanks.

> a bug about deciding whether this key is a new key for the ROWCOL bloomfilter
> -----------------------------------------------------------------------------
>
>                 Key: HBASE-3636
>                 URL: https://issues.apache.org/jira/browse/HBASE-3636
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: Liyin Tang
>
> When ROWCOL bloomfilter needs to decide whether this key is a new key or not,
> it will call the matchingRowColumn function, which will compare the timestamp offset between this kv and last kv.
> But when checking the timestamp offset, it didn't deduct the original offset of the keyvalue itself.
> For example, when 2 keyvalue objects have the same row key and col key, but from different storefiles. It is highly likely that these 2 keyvalue objects have different offset value. So the timestamp offset of these 2 objects are totally different. They will be regard as new keys to add into bloomfilters.
> So after compaction, the key count of bloomfilter will increase immediately, which is almost equal to the number of entries.
> The solution is straightforward. Just compare the relevant timestamp offset, which is the timestamp offset - key_value offset.
> This also may explain this jira: https://issues.apache.org/jira/browse/HBASE-3007

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira