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