hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10247) Client promises about timestamps
Date Tue, 12 Aug 2014 20:46:12 GMT

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

Andrew Purtell commented on HBASE-10247:
----------------------------------------

bq. Either we accept out of order timestamps at the slave (when we use the timestamps of the
primary)

Yes, but this can be acceptable for DR use cases. Also, if backups are handled through some
other means, such as snapshots+copy and replication is not active, having an option to restrict
timestamps to server generated stamps can still be useful. Until we're bridging clusters with
Raft etc.

> Client promises about timestamps
> --------------------------------
>
>                 Key: HBASE-10247
>                 URL: https://issues.apache.org/jira/browse/HBASE-10247
>             Project: HBase
>          Issue Type: Brainstorming
>            Reporter: Lars Hofhansl
>            Priority: Minor
>             Fix For: 0.99.0, 2.0.0
>
>         Attachments: 10247-do-not-try-may-eat-your-first-born-v2.txt, 10247.txt
>
>
> This is to start a discussion about timestamp promises declared per table of CF.
> For example if a client promises only monotonically increasing timestamps (or no custom
set timestamps) and VERSIONS=1, we can aggressively and easily remove old versions of the
same row/fam/col from the memstore before we flush, just by supplying a comparator that ignores
the timestamp (i.e. two KV just differing by TS would be considered equal).
> That would increase the performance of counters significantly.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message