[
https://issues.apache.org/jira/browse/HBASE-9905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13816464#comment-13816464
]
Sergey Shelukhin commented on HBASE-9905:
-----------------------------------------
My 2c. I think relying on clock for any notion of consistency and versioning is
an extremely bad idea, unless you are Spanner :). We already have loads of
potential timing issues in HBase with the ts that we are using. System clock
can move backwards, and skew between servers when region is moved/fails over
can be significant, leading to all kinds of weird behavior.
So I agree with Enis we should deprecate it. I don't think we need so many
modes though.
There are 3 ts sources - system-always, user-always, mixed.
For system-always (rejecting client timestamps), I am +1 on seqNum-mode, as
discussed in the meetup, and above. Maybe make it default for new tables in
98-1.0? And migrate meta to it, probably out of bounds with upgrade via a
script, so it would be optional.
For the others, I think /server/ should *never* use clock for ts. Never-ever.
For user-always, it's not a problem by definition; for mixed mode, we /could
use/ seqNum-as-ts (client can make derived ts-es that [~jmspaggi] mentions
based on seqNum-ts, just as well as based on clock-ts; if client wants to store
time as data (not version), a column is a proper place for it), but
unfortunately due to backward compat it is not viable to make a complete switch.
So what we should do imho is have client library, instead of server, generate
TS if user doesn't supply one (there'd have to be some relatively easy backward
compat). That way, the semantics are the same, but if the user screws up
clocks, it's no longer an HBase consistency problem - if you want bulletproof
clock-based versions (ts-es), manage your own, or manage your clock sync. For
user-always vs mixed in this case, there's no need for special flag, from
server point of view they look the same.
Optionally we might want to create mixed mode with seqNums; or a special mode
that would enforce user-always and reject requests without ts, but I don't
think this is strictly necessary.
If this is contentious I am +1 on just adding seqNum mode and not doing
anything else also :)
> Enable using seqId as timestamp
> --------------------------------
>
> Key: HBASE-9905
> URL: https://issues.apache.org/jira/browse/HBASE-9905
> Project: HBase
> Issue Type: New Feature
> Reporter: Enis Soztutar
> Fix For: 0.98.0
>
>
> This has been discussed previously, and Lars H. was mentioning an idea from
> the client to declare whether timestamps are used or not explicitly.
> The problem is that, for data models not using timestamps, we are still
> relying on clocks to order the updates. Clock skew, same milisecond puts
> after deletes, etc can cause unexpected behavior and data not being visible.
> We should have a table descriptor / family property, which would declare that
> the data model does not use timestamps. Then we can populate this dimension
> with the seqId, so that global ordering of edits are not effected by wall
> clock.
> For example, META will use this.
> Once we have something like this, we can think of making it default for new
> tables, so that the unknowing user will not shoot herself in the foot.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
