Live data from Hacker News

Nanosecond timestamp collisions are common

evanjones.ca

31–40 of 291 posts

Re: Nanosecond timestamp collisions are common

#31
post #23
post #21

If you want unique identifiers, use version 4 (random) UUIDs. Problem solved. The probability of a collision is roughly the same as the probability of a fully grown dinosaur spontaneously manifesting in your bedroom due to quantum fluctuations.

I will take my chance :-) More seriously, If you can use them, good old increments are probably best. They are fast and cheap. Especially in a database. They can have privacy/security issues (you could guess things by the values of ids of stuff). UUIDs are better in those case or when you deal with a distributed system.

> They can have privacy/security issues (you could guess things by the values of ids of stuff).

Push them through a secure hash function, and that problem is solved too (assuming you can keep the base counter private).

Re: Nanosecond timestamp collisions are common

#32
post #21

If you want unique identifiers, use version 4 (random) UUIDs. Problem solved. The probability of a collision is roughly the same as the probability of a fully grown dinosaur spontaneously manifesting in your bedroom due to quantum fluctuations.

v7 looks nicer since it solves v4's locality issue and you're still a gazillion times more likely to win the lottery than generate a collision.

Re: Nanosecond timestamp collisions are common

#33
post #14

Earlier quoted context omitted.

If you do that, just take some redis server and increment an integer every time you need a new number?

or y'know, use the thing that was designed specifically for this case: UUID's

UUIDs are designed to solve a slightly different, albeit related, problem: where you don’t have synchronisation of the system as a whole. The solution the GP is solving is for systems that are synchronised and therefore generating a UUID is additional and unnecessary overhead.

Re: Nanosecond timestamp collisions are common

#34
post #8

I 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?

[deleted]

Re: Nanosecond timestamp collisions are common

#35

This 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…

Isn’t it simpler to use sequence keys then?

Re: Nanosecond timestamp collisions are common

#36

I 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.

Only v6 and v7, v8 is "whatever you want".

Re: Nanosecond timestamp collisions are common

#37
post #32
post #21

If you want unique identifiers, use version 4 (random) UUIDs. Problem solved. The probability of a collision is roughly the same as the probability of a fully grown dinosaur spontaneously manifesting in your bedroom due to quantum fluctuations.

v7 looks nicer since it solves v4's locality issue and you're still a gazillion times more likely to win the lottery than generate a collision.

Unfortunately, many libraries don't implement it yet.

Re: Nanosecond timestamp collisions are common

#38

A lot of mention of UUDv7 in this thread which is good. But I also wonder what the collision rate for Ulids are.

I frankly don't understand how it's good. UUID originally was intended as something you use very sparingly, to name, say, a product SKU maybe, an organization, something like that. Not literally content that collides commonly at the same nanosecond, in the same application, in the same platform/org. At some point we have to question the sanity of using one single flat address space for everything from the tiniest ide…

> I frankly don't understand how it's good. UUID originally was intended as something you use very sparingly, to name, say, a product SKU maybe, an organization, something like that. Not literally content that collides commonly at the same nanosecond, in the same application, in the same platform/org.

Wikipedia gives a different history, that it was originally for networked computers - https://en.wikipedia.org/wiki/Universally_unique_identifier#...

Re: Nanosecond timestamp collisions are common

#39

A lot of mention of UUDv7 in this thread which is good. But I also wonder what the collision rate for Ulids are.

I frankly don't understand how it's good. UUID originally was intended as something you use very sparingly, to name, say, a product SKU maybe, an organization, something like that. Not literally content that collides commonly at the same nanosecond, in the same application, in the same platform/org. At some point we have to question the sanity of using one single flat address space for everything from the tiniest ide…

> So why aren't we doing this?

isn't IPv6 is basically that? just restricted to internet addresses

Re: Nanosecond timestamp collisions are common

#40

This 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…

Isn’t it simpler to use sequence keys then?

Yes, but only on single machines, UUID and co are intended for distributed systems.

Although now I wonder if / how UUID v7 can do sequential keys on distributed systems. Mind you, on those systems "close enough" will probably be good enough, and sorting will be done by date instead of incremental ID.

Post reply on HN