cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-6108) Create timeid64 type
Date Mon, 23 Jun 2014 11:56:25 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040659#comment-14040659
] 

Benedict edited comment on CASSANDRA-6108 at 6/23/14 11:55 AM:
---------------------------------------------------------------

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,
as this is an extra indirection and makes simple delta encoding of timestamps trickier, meaning
tables are unlikely to be as compact. But it may be the best overall solution for implementation
complexity vs functionality.


was (Author: benedict):
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)

Mime
View raw message