hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1263) Optimize for single-version families
Date Thu, 19 Mar 2009 20:57:50 GMT

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

stack commented on HBASE-1263:
------------------------------

We already have notion of comparator that ignores timestamps -- needed to count versions --
and a comparator that ignores type so we can see if something has been deleted (though type
in the key is different).  Would be easy enough to specify comparator with no timestamp on
a family.

Descending sort ain't going to happen.  Whole hbase system has to have same basic comparator
else fhit hits the san when regions split and get entries in .META. (Can't have the .META.
order sometimes lexographically and then at other times reverse lexicographically all in the
one table).

> Optimize for single-version families
> ------------------------------------
>
>                 Key: HBASE-1263
>                 URL: https://issues.apache.org/jira/browse/HBASE-1263
>             Project: Hadoop HBase
>          Issue Type: New Feature
>          Components: regionserver
>            Reporter: Jonathan Gray
>             Fix For: 0.20.0
>
>
> As some of us have been discussing, allowing the client to manually set the timestamp
of a put breaks the general semantics of versioning and I'd like to see it removed as part
of HBASE-880 (a more appropriate place to debate that).
> However, one trick being used when you don't want the overhead of versions on a frequently
updated column (which are only cleared on compactions even if set to 1), was to use the same
timestamp.  Since that would create an identical key it would just overwrite the value not
create a new version.
> It's a very common use-case, and this hack is being used as part of the committed increment
ops from HBASE-868/HBASE-1252.  Rather than making a special optimization for counters, an
optimization on single-version families that never stores more than one version of a column.

-- 
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