cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7919) Change timestamp representation to timeuuid
Date Sat, 13 Sep 2014 20:22:34 GMT

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

Mime
View raw message