hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Gray (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-1252) Make atomic increment perform a binary increment
Date Tue, 10 Mar 2009 21:25:50 GMT

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

Jonathan Gray updated HBASE-1252:
---------------------------------

    Attachment:     (was: hbase-1252-v2.patch)

> Make atomic increment perform a binary increment
> ------------------------------------------------
>
>                 Key: HBASE-1252
>                 URL: https://issues.apache.org/jira/browse/HBASE-1252
>             Project: Hadoop HBase
>          Issue Type: Improvement
>    Affects Versions: 0.19.0
>            Reporter: Jonathan Gray
>            Assignee: Jonathan Gray
>            Priority: Minor
>             Fix For: 0.19.1, 0.20.0
>
>         Attachments: hbase-1252-v1.patch, hbase-1252-v2.patch
>
>
> A few issues related to recently committed HBASE-803
> - The HTable api still takes an integer amount rather than long, mismatching HRI.
> - Binary increments are 10 times faster for small amounts than going Bytes.toLong, +=
amount, Bytes.toBytes.  Twice as fast for large amounts (binary incrementor just loops a bunch
of single increments, though there is plenty of room for optimizations in my current implementation)
> - Using a binary increment means we don't have to worry about the size of the value.
 If someone wants a 16 byte value they can have it, just have to initialize as such.  If no
existing value exists, will default to long/8 bytes.  Only odd behavior will be what happens
when you are at the max value, currently will just stay at all 11111 binary.  Could actually
grow the byte[] but then we can't do things in place. I'm okay with leaving it like that,
not exactly sure what the current implementation would do, throw an exception or wrap?
> - Using binary incrementing, we can directly manipulate values in the memcache rather
than sending updates with the same timestamp.  I think we should hold off on doing this until
HBASE-1234 goes in.  We'll then have to deal directly with hlog.  (this issue is not going
to address this)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message