[
https://issues.apache.org/jira/browse/CASSANDRA-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783169#comment-13783169
]
Sylvain Lebresne commented on CASSANDRA-6108:
---------------------------------------------
Haven't looked too closely at the details, but my initial idea was to try to
keep the association of all host<->assigned id, and to pick the lowest assigned
value when a new id is needed. That would be a tad slower than just doing a +1
on the last sequence number, but that has the advantage that if you
decommission/remove some node and add new ones you can reuse old id safely. I
mean, 65K possible ID is a reasonably big number but it would still buy me some
peace of mind to have a limitation to 65K nodes per-cluster rather than 65K
bootstrap in the lifetime of the cluster.
> 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
>
>
> 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.1#6144)
