[
https://issues.apache.org/jira/browse/HBASE-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14537589#comment-14537589
]
stack commented on HBASE-13510:
-------------------------------
bq. The first benefit of this patch is that we are getting rid of compare(Cell,
byte[]) that comes with ROW_COL bloom so that removing such comparisons will
help us remove this compare(Cell, byte[]) API in CellComparator.
Sounds good. What we going to use instead?
bq. The ByteBloomFilter is not getting as a bloomfilter type making us remove
the dependency the bloom was having so that all the bloom types were operating
on byte[] though the ROW_COL was operating on the key part of a KV formed from
row and column.
Can you redo the above. I don't follow boss.
bq. So if we create a Cell any way to get the key byte[] we need to convert
that into a Keyvalue, hence instead of going with Cell and doing a typecast to
KV directly creating a KeyValue in this case is better.
We can't have Blooms use Cells? There'd be a copy of the row bytes if Cell or
something?
bq. Returning byte array of key-only portion?
bq. Yes. We have to do that.
Why is that when bloom is for row/column? We put whole key in there?
bq. This we are doing it every time to form the key part of the ROW_COL bloom
key. This is nothing new, just using a static method instead of an instance
method previously.
We have to do this? We only use the row and column portions? Or we hash whole
key part in bloom?
> 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)
