hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13510) Refactor Bloom filters to make use of Cell Comparators in case of ROW_COL
Date Mon, 11 May 2015 16:59:00 GMT

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

stack commented on HBASE-13510:

bq. Just avoid this API from interface/class?

Sounds good.

I haven't dug in but it is a hash that goes into the bloom filter, not actual bytes, right?
Could we not hash against the actual Cell rather than make copies (pardon if this is a dumb

bq. Can we avoid it fully ? (An [~anoop.hbase]) comment

I like Anoops's review/comments. Can we do as he suggests?  In particular, fix this observation
of his:

bq. We have 2 impls for BloomFilter interface. ie. CompoundBloomFilter and ByteBloomFilter.

bq. Now this patch tries to deal only with CompoundBloomFilter with ROW and ROW_COL as the
type and the ROW_COL depends on the CellComparator whereas the ROW depends on Bytes.Byte_RAWCOMPARATOR.

This sounds good. Suggest you reedit the subject and the original description once we have
arrived at final patch because it seems like you are doing nicer work than the subject and
description currently allow.

> 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

This message was sent by Atlassian JIRA

View raw message