[
https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094352#comment-14094352
]
Andrew Purtell commented on HBASE-10247:
----------------------------------------
bq. I suppose we could allow timestamp that are strictly older than the next
timestamp the server would hand out...
Right, for deleting or replacing specific versions, if using SERVER_TS treat
the timestamp as a logical value (as is it's nature). Allow the client to
specify on mutation ops specific version(s) that might refer to existing data.
bq. Disallow TTL with no wall clock type TSPOLICY
Just a note: With something like HLC
(http://www.cse.buffalo.edu/tech-reports/2014-04.pdf) timestamps would be in a
regime that allows continued use of wall-clock-like TTLs.
> 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)
