[
https://issues.apache.org/jira/browse/HBASE-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295821#comment-15295821
]
stack commented on HBASE-15554:
-------------------------------
bq. Infact if we accept HasKey we can avoid the KeyOnlyKV and BufferedKeyonlyKV
concepts.
I think the new Key Interface can come in if we can remove a few Interfaces
that have not been released yet and that are not as pretty as Key.
bq. I don't think Cells need to have a key.
Sounds good. I like this. Better than my attempt at entangling the two notions.
bq. But remember this Key interface is going to be private and will not be
exposed to the user or in clients.
Good. So, yeah, just throw exception if used inconsistently.
bq. But to construct the index that we have now how do we create it without
copying them every time? Can you say more on what you think here. May be am not
getting your bigger idea.
You can ask a Cell for its family and its timestamp. I am asking if you will
want to do this against a Key. Seems like you would. If so, the Key methods for
doing this should be the same as the Cell ones?
I think it would be cool replacing a few Interfaces such as KeyOnlyKV with Key;
that'd be a nice improvement.
> StoreFile$Writer.appendGeneralBloomFilter generates extra KV
> ------------------------------------------------------------
>
> Key: HBASE-15554
> URL: https://issues.apache.org/jira/browse/HBASE-15554
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Reporter: Vladimir Rodionov
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-15554.patch, HBASE-15554_3.patch,
> HBASE-15554_4.patch
>
>
> Accounts for 10% memory allocation in compaction thread when BloomFilterType
> is ROWCOL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
