[
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.
Questions:
* 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
(v6.2#6252)
