Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 12 Aug 2014 17:51:13 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12686507.1388129362344.65047.1407865873085@arcas>
In-Reply-To: <JIRA.12686507.1388129362344@arcas>
References: <JIRA.12686507.1388129362344@arcas>
Subject: [jira] [Commented] (HBASE-10247) Client promises about timestamps
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)