hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5021) Enforce upper bound on timestamp
Date Thu, 15 Dec 2011 00:53:31 GMT

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

Phabricator commented on HBASE-5021:

Kannan has commented on the revision "[jira] [HBase-5021] Enforce upper bound on timestamp".

  src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:2147 a) Shouldn't updateKVTimestamps()
get called before checkTimestamps() because it is possible the put contains some HConstants.LATEST_TIMESTAMP
kvs-- in which case the intent of the application was to let HBase set the timestamp? We don't
want those kvs to be flagged as being too new.

  b) Same comment for the batched put case also.
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:458 could you add some documentation
here covering the units (e.g., milliseconds) and semantics. Some thing like:

  <<<this param allows HBase to enforce that application cannot insert values that
are these many milliseconds into the future with respect to current time>>>

  Also, perhaps the param name could be:



> Enforce upper bound on timestamp
> --------------------------------
>                 Key: HBASE-5021
>                 URL: https://issues.apache.org/jira/browse/HBASE-5021
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Nicolas Spiegelberg
>            Assignee: Nicolas Spiegelberg
>            Priority: Critical
>             Fix For: 0.94.0
>         Attachments: D849.1.patch
> We have been getting hit with performance problems on our time-series database due to
invalid timestamps being inserted by the timestamp.  We are working on adding proper checks
to app server, but production performance could be severely impacted with significant recovery
time if something slips past.  Since timestamps are considered a fundamental part of the HBase
schema & multiple optimizations use timestamp information, we should allow the option
to sanity check the upper bound on the server-side in HBase.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message