You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2014/07/16 23:47:05 UTC

[jira] [Resolved] (HBASE-1263) Optimize for single-version families

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

Andrew Purtell resolved HBASE-1263.
-----------------------------------

    Resolution: Not a Problem

> Optimize for single-version families
> ------------------------------------
>
>                 Key: HBASE-1263
>                 URL: https://issues.apache.org/jira/browse/HBASE-1263
>             Project: HBase
>          Issue Type: New Feature
>          Components: regionserver
>            Reporter: Jonathan Gray
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)