[
https://issues.apache.org/jira/browse/CASSANDRA-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040659#comment-14040659
]
Benedict commented on CASSANDRA-6108:
-------------------------------------
I'm comfortable with that approach; sticking to 64-bit is certainly not
essential. Although it might require a bit of tweaking TimeUUID generation for
the fact that we can have multiple clients being created/terminated near in
time and on the same node (say, by using SecureRandom instead for the clock
value, or System.nanoTime()+System.currentTimeMillis()), esp. as makeNode() has
only 16-bits of uniqueness which is less collision-free for clients than for
nodes.
I'm not 100% sure it's better than the approach I suggested, however: storing a
lookup table inside of each sstable is unlikely to be expensive initially, but
since the universe of ids will grow linearly with cluster up time, this could
get out of hand before long. We could settle for a hybrid approach where we set
this value to zero for all repaired sstables though.
I'd still prefer not to have to perform a lookup each time I want to query the
timestamp, though, as this is an extra indirection and makes simple delta
encoding of timestamps trickier. But it may be the best overall solution for
implementation complexity vs functionality.
> Create timeid64 type
> --------------------
>
> Key: CASSANDRA-6108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6108
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 2.1.1
>
>
> As discussed in CASSANDRA-6106, we could create a 64-bit type with 48 bits of
> timestamp and 16 bites of unique coordinator id. This would give us a
> unique-per-cluster value that could be used as a more compact replacement for
> many TimeUUID uses.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
