cassandra-commits mailing list archives

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

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

Benedict commented on CASSANDRA-6108:
-------------------------------------

bq. True, though at least for the 'node' part of the timeuuid, that's not suppose to change
for a given client host, so in most installations, their might not be much growth over time.

True, but not sure I'd like to rely on that. 2^14 * unique client ids is still a lot of ids.
We could decompose into unique client ids + 14 bits and hope the unique client id set is relatively
static, but this is kind of ugly to persist, and further limits possibilities for compressing,
as we probably have to store a short for every timestamp without question. If anybody ever
deploys clients internet-wide, this would break badly. Also, our client-id probably needs
to have some extra random salt to the IP at startup in case clients could be connecting over
NAT.

> 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