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