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

stack commented on HBASE-13510:
-------------------------------

I asked this already I'm sure, but why not Cell in below from StoreFile:

                  KeyValue bloomKeyKV = null;

Why we have to do this:

bloomKeyKV = BloomFilterUtil.createBloomKeyValue

What is this doing:

                    bloomKey = bloomKeyKV.getKey();

Returning byte array of key-only portion?

We have to do that?

I asked this before too.. .how many itimes we creating new keys here?

                  kvKey = BloomFilterUtil.createBloomKeyValue(row, rowOffset, 
rowLen, col,

or here... 0                KeyValue rowBloomKey = 
BloomFilterUtil.createBloomKeyValue(row, rowOffset, rowLen,
1319                    null, 0, 0);    1321                    null, 0, 0);

We are just going to check for the row portion here, right?

          boolean contains(KeyValue kvKey, ByteBuffer bloom);

The javadoc on this one is not clear. Its just the row we are comparing?


We have to do this?

 public Writable getMetaWriter() {

i.e. preserve Writable?

We have to add this to Interface? 55      boolean contains(KeyValue kvKey, 
ByteBuffer bloom);

Can't add Cell version?

What is benefit of this patch?

Thanks.






> Refactor Bloom filters to make use of Cell Comparators in case of ROW_COL
> -------------------------------------------------------------------------
>
>                 Key: HBASE-13510
>                 URL: https://issues.apache.org/jira/browse/HBASE-13510
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 2.0.0
>
>         Attachments: HBASE-13510_1.patch, HBASE-13510_2.patch
>
>
> In order to address the comments over in HBASE-10800 related to comparing 
> Cell with a serialized KV's key we had some need for that in Bloom filters.  
> After discussing with Anoop, we found that it may be possible to 
> remove/modify some of the APIs in the BloomFilter interfaces and for doing 
> that we can purge ByteBloomFilter.  
> I read the code and found that ByteBloomFilter was getting used in V1 version 
> only.  Now as it is obsolete we can remove this code and move some of the 
> static APIs in ByteBloomFilter to some other util class or bloom related 
> classes which will help us in refactoring the code too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to