[ https://issues.apache.org/jira/browse/HBASE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007868#comment-13007868 ]
Hudson commented on HBASE-3636: ------------------------------- Integrated in HBase-TRUNK #1792 (See [https://hudson.apache.org/hudson/job/HBase-TRUNK/1792/]) > 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 > Fix For: 0.90.2 > > Attachments: HBASE_3636[r1081520].patch > > > 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