[
https://issues.apache.org/jira/browse/CASSANDRA-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040682#comment-14040682
]
Sylvain Lebresne commented on CASSANDRA-6108:
---------------------------------------------
bq. since the universe of ids will grow linearly with cluster up time
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.
Anyway, I'm definitively not contesting that in term of compactness we might do
somewhat better with something custom. But reusing and optimizing timeuuid has
enough advantages (in particular I'd *much* rather not have to say to users
"remember when we told you to use timeuuids, well that has changed. Oh, you're
using timeuuid all over the place already. Well, though luck") that it's
probably worth settling a bit on compactness. Imo at least.
> 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)
