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 20:30:15 GMT

    [ https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094614#comment-14094614
] 

Lars Hofhansl commented on HBASE-10247:
---------------------------------------

Yep, the current semantics are sound.

Actually the issue is not that both cluster need to be active... We'll have the issue above
even with a single writer cluster only: Either we accept out of order timestamps at the slave
(when we use the timestamps of the primary) or we accept out of order edits at the slave (when
we use the slave to assign local server TSs). The former goes against what I want to achieve
the latter leads to incorrect data.

A way around this would be to strictly order *all* edit as they are replicated, which is very
difficult as replication is decentralized (which is especially an issue when RSs die and other
take over their replication work).  Synchronous replication would by definition do that.


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

Mime
View raw message