You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2018/05/10 14:41:00 UTC

[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator

     [ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-20564:
--------------------------
    Summary: Tighter ByteBufferKeyValue Cell Comparator  (was: Tighter BB Cell Comparator)

> Tighter ByteBufferKeyValue Cell Comparator
> ------------------------------------------
>
>                 Key: HBASE-20564
>                 URL: https://issues.apache.org/jira/browse/HBASE-20564
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance
>            Reporter: stack
>            Priority: Major
>
> Comparing Cells in hbase2 takes almost 3x the CPU.
> In hbase1, its a keyValue backed by a byte array caching a few important values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the row/family/qualifier lengths repeatedly.
> I tried making a purposed comparator -- one that was not generic -- and it seemed to have a nicer profile coming close to hbase1 in percentage used (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts attached to HBASE-20483). It doesn't work when I try to run it on cluster. Let me run unit tests to see if it can figure what I have wrong.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)