[
https://issues.apache.org/jira/browse/HBASE-14144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694945#comment-14694945
]
ramkrishna.s.vasudevan commented on HBASE-14144:
------------------------------------------------
bq.Here we are creating a KV by copy and later down in
checkGeneralBloomFilter(byte[] key, Cell kvKey, BloomFilter bloomFilter) we
again create
Cell rowBloomKey = CellUtil.createFirstOnRow(kvKey);
Can we avoid? Some sort of refactoring may be needed. Any chance to use
CellUtil instead of KeyValueUtil and avoid a copy?
The rowBloomKey is needed here for the Deletefamily bloom cases. So the kvKey
is a cell created out of row and col and in this rowBloomKey case we only need
the row part of the Cell. Also the
{code}
exists =
bloomFilter.contains(kvKey, bloom) ||
bloomFilter.contains(rowBloomKey, bloom);
{code}
Will expect a Cell and that is why converted the rowBloomKey to a new Cell.
bq.FirstOnRowBBFakeCell -> Better we can name it as FirstOnRowFakeBBCell
Yes changed.
bq.We may have to change Hash function to work with BB also? Later in another
jira may be
Ya this needs a bigger change and it is not straight forward. The Hash needs a
continuous byte[] to work with. So we need to have the key part of the Cell.
If we try to operate as Cell it is going to be difficult with that algo design.
So anyway we need to do a copy - better we can have it byte[] for now.
> Bloomfilter path to work with Byte buffered cells
> -------------------------------------------------
>
> Key: HBASE-14144
> URL: https://issues.apache.org/jira/browse/HBASE-14144
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14144.patch, HBASE-14144_1.patch,
> HBASE-14144_2.patch, HBASE-14144_3.patch, HBASE-14144_4.patch
>
>
> This JIRA is to check if there will be a need to make the bloom filters to
> work with ByteBuffer cells. During POC this path created lot of duplicated
> code but considering other refactorings done in this path may lead to less
> duplication. This JIRA is a placeholder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
