[
https://issues.apache.org/jira/browse/CASSANDRA-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132928#comment-14132928
]
Sylvain Lebresne commented on CASSANDRA-7919:
---------------------------------------------
To recall the context a bit here, we want globally unique timestamps for 2
reasons: 1) to fix CASSANDRA-6123 and 2) because it's a requirement for RAMP
transactions (CASSANDRA-7056). An additional constraint being that whatever we
come up with for that must support client-side provided timestamps.
Timeuuids are a standardize way to generate such globally unique timestamp, and
as it happens, it's already what we tell people to use for their time series.
Using them has a number of advantages: it's very simple (a very good property),
every client driver already has code to generate them, and whatever effort we
might put in optimizing their storage could be reused for the CQL timeuuid type.
I don't think timeuuids are broken by design. There is certainly sub-optimal
implementations currently (like CASSANDRA-7925) but it's not that hard to fix
and it needs to be fixed anyway whether or not we use them here.
Storage-wise, it's definitively true that timeuuid are not the most compact
thing ever, but we can optimize their storage somewhat. At the very least, we
can store the time part separatly from the lsb and offset encode it. Regarding
the lsb, a given client shouldn't really change it during it's lifetime (per
the timeuuid spec) so in general the cardinality of lsb shouldn't be huge and
I'm sure we can use that to our advantage (and while we can't guarantee that
all clients will be reasonable, it's ok to say that you should use a reasonable
client to get the best performance imo).
More importantly, the alternatives that have been suggested so far are complex,
adhoc and full of gotchas. We need to fix CASSANDRA-6123 at some point, and
blocking CASSANDRA-7056 on this is not ideal either, so unless someones comes
up with a more compact alternative that is not overly complex (both for C* and
for clients), I personally think we should go with timeuuids.
> Change timestamp representation to timeuuid
> -------------------------------------------
>
> Key: CASSANDRA-7919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7919
> Project: Cassandra
> Issue Type: Improvement
> Reporter: T Jake Luciani
> Priority: Minor
> Fix For: 3.0
>
>
> In order to overcome some of the issues with timestamps (CASSANDRA-6123) we
> need to migrate to a better timestamp representation for cells.
> Since drivers already support timeuuid it makes sense to migrate to this
> internally (see CASSANDRA-7056)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
