[
https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094389#comment-14094389
]
Lars Hofhansl commented on HBASE-10247:
---------------------------------------
Turns out there are a bunch of other problems with this:
# I envised CLIENT_MONOTONIC for use cases where we have an external
transaction id oracle. The idea is that each transaction gets a write TS and
writes all changes with that TS. That won't work with multiple transactions in
parallel, we'd be back to getting timestamps out of order and can no longer
guarantee that the ordering of the HFiles by time implies the ordering of any
version of KVs inside (say T2 writes something, then a flush happens, and then
T1 writes something). So I think there is no point in having this policy
(unless there is another use case where this is valid), as there is no
advantage over MIXED.
# More importantly. Server-side-only TSs *cannot* work with replication! When
region servers fail in a source cluster edit may reach the slave cluster out of
order. Now we can (a) assign TSs again by a slave server and we'd have
different ordering of the KVs and hence different data, or we can (b) allow
using the TSs from KVs and we're back to where we were, edits can be back and
future dated.
I do not see a way out of the dilemma in #2.
> 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)
