[
https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000062#comment-14000062
]
Enis Soztutar commented on HBASE-10247:
---------------------------------------
Great.
bq. I think something like TS_POLICY => '<state>' would be best.
Agreed.
bq. We need at least two (ideally three) states
See my comments at
https://issues.apache.org/jira/browse/HBASE-9905?focusedCommentId=13815414&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13815414
We should think about HBASE-9905 and this together as a single configuration.
It seems that we need these capabilities:
- Know whether or not all timestamps are monotonically increasing (this will
allow a lot of nice perf improvements and semantic guarantees. This can be
either server side seqIds, or client side based ts oracle kind of setups. Both
should be allowed and differentiated. Maybe this is a different table property.
- Server side ts setting.
- Mixed mode, or something like that to support existing tables. This should
be deprecated.
> 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)
