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 Fri, 16 May 2014 11:18:29 GMT

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

Lars Hofhansl commented on HBASE-10247:

I'd like to pick this up again. At least we start to allow to mark tables this way before
1.0 even if we don't do any optimizations based on this.

I think something like TS_POLICY => '<state>' would be best.

We need at least two (ideally three) states:
* CLIENT_OK, this would allow a client to set timestamps freely
* SERVER_ONLY - RegionServer sets timestamps, attempts to set TS from a client would result
in an Exception
* CLIENT_MONOTONIC (maybe) - client can set timestamp, but promises to do so monotonically.
For experts, we basically have to trust the client would do the right thing.
The reason for the last state is to allow clients to control TSs (for things like transactions,
etc), but still allow HBase to do optimizations based on monotonically increasing TSs. Maybe
we could do that one later.

We can add other states as we need them.

Let's first implement the table option and enforce the restrictions. Then we can add optimizations
based on these settings.

* can you switch states? From SERVER_ONLY to CLIENT_OK, or CLIENT_MONOTONIC is OK. From CLIENT_MONOTONIC
to CLIENT_OK is also OK. All other transitions would be disallowed (or somehow only take effect
after the whole table was major_compacted). We could order the states by how restrictive they
are and allow from less restrictive to more.

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