hbase-issues mailing list archives

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

    [ 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

View raw message