[
https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095152#comment-14095152
]
Lars Hofhansl commented on HBASE-10247:
---------------------------------------
I agree that unless replication is used server TS can work.
I don't see a way to make it work for replication (to rephrase above: either we
have to allow client set timestamps for the local inserts into the slave
defeating the purpose of this, or accept incorrect data at the slave - neither
seem appealing).
This can only be solved, really, when replication never sends edits out of
order.
Could block this if any CF has REPLICATION_SCOPE=1.
Needless to say I am much less enthused about this idea now... if we cannot
generally use it.
And CLIENT_MONOTONIC makes no sense under scrutiny.
> 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)
