Nanosecond timestamp collisions are common
evanjones.ca
Nanosecond timestamp collisions are common
1–10 of 291 posts
Re: Nanosecond timestamp collisions are common
#2Timestamps should probably never be used as a "unique" id.
Re: Nanosecond timestamp collisions are common
#3If you need unique nanosecond, keep track of the previously generated one and increase it if necessary. Would require global lock or atomic stuff, but should be good enough for practical uses.
Re: Nanosecond timestamp collisions are common
#4I was going to post about "use a UUID", but I was surprised to learn that no UUID uses both timestamp + a random component. You can either get fully random with UUID4, or have a time + MAC based UUID with UUID1. Strange, I would have thought there would exist a UUID that uses time + random to minimize collisions like described in the post.
Re: Nanosecond timestamp collisions are common
#5This is why you should use ids that combine both a time component and a sequence.
Eg UUIDv7 has a milliseconds time component and then a field that increments for each event in the same millisecond, and then enough random bits to make collisions between ids generated on different machines astronomically unlikely.
Of course there are only so many bits so you might generate too many events in the same time slice so the sequence overflows, and you might actually get collisions between machines, and you are limiting your event generation speed by forcing your cpu to sync on the increment etc.
But in practice UUIDv7 works great at scale.
Re: Nanosecond timestamp collisions are common
#6If you need unique nanosecond, keep track of the previously generated one and increase it if necessary. Would require global lock or atomic stuff, but should be good enough for practical uses.
One benefit of UUID is that you don't need coordination. In coordinated systems, unique IDs are a non-issue.
Re: Nanosecond timestamp collisions are common
#7I was going to post about "use a UUID", but I was surprised to learn that no UUID uses both timestamp + a random component. You can either get fully random with UUID4, or have a time + MAC based UUID with UUID1. Strange, I would have thought there would exist a UUID that uses time + random to minimize collisions like described in the post.
the new UUIDv6, 7 and 8 work the way you deacribe.
Re: Nanosecond timestamp collisions are common
#8I was going to post about "use a UUID", but I was surprised to learn that no UUID uses both timestamp + a random component. You can either get fully random with UUID4, or have a time + MAC based UUID with UUID1. Strange, I would have thought there would exist a UUID that uses time + random to minimize collisions like described in the post.
Can't find much info about it but is this UUID v7?
Re: Nanosecond timestamp collisions are common
#9I was going to post about "use a UUID", but I was surprised to learn that no UUID uses both timestamp + a random component. You can either get fully random with UUID4, or have a time + MAC based UUID with UUID1. Strange, I would have thought there would exist a UUID that uses time + random to minimize collisions like described in the post.
someone else in the thread mentioned UUIDv7
Re: Nanosecond timestamp collisions are common
#10I was going to post about "use a UUID", but I was surprised to learn that no UUID uses both timestamp + a random component. You can either get fully random with UUID4, or have a time + MAC based UUID with UUID1. Strange, I would have thought there would exist a UUID that uses time + random to minimize collisions like described in the post.
I believe the proposed UUIDv7 standard uses this.
https://datatracker.ietf.org/doc/html/draft-peabody-dispatch...
It's a draft but there's a lot of implementations out there.