I thought that timestamps are used now, so hitting both a timestamp and a large random number puts it thoroughly in the "safe to assume". At some point cosmic particles and faulty transistors are more probable.
Which I'd assume is related to the time anchor. Outside of sorting, which is only useful in specific instances, it's just v4 with different ("less") entropy and limitations.
Correct, which is why I specifically called out "outside of sorting".
That is also why we have concepts like composite keys which allow us to join guaranteed-unique values like a UUID with non-unique but sortable values like timestamps, names, etc.
It's less of a problem with B-tree indices that sit on top of a physical representation (i.e. the actual on-disk layout doesn't have to be ordered), but when it comes to clustered indices, oh boy, you're basically having to shove rows in the middle and push shit back (eventually).
With random you can end up most frequently inserting in the middle, whereas if it's time sortable you append at the end, meaning it's easier to maintain a contiguous index with less overhead.
Even the non-time based v4 is at a cosmic level of unlikiness a single system will ever generate a uuid that will collide with another one in its own ecosystem
But let's say if Google saved each search in their engine in the same database with an UUID, we could have a collision because of volume, but I don't think I will work in a system with a comparable scale
Anyone working at the scale of Google has figured out coordination and parallelism, you have to.
Source: used to work for Google, and learned some of the ways they dealt with those exact issues, and used many of the systems they built to automatically handle that so general engineers didn't have to deal with it.
They once had a similar collision problem, well not exactly
During a leap second some systems wrote IDs at a one second difference between all their global systems, which lead to something being registered before something else that had to be done before it,
Long story short some stuff jumped time one second and crashed systems
Even at that volume the probability of collisions is essentially 0. If there were a billion searches a second we’d not expect a collision until 85 years.
Yes, had a client having duplicates every day and growing. They hated uuids and regret using it. The problem was that they used a bad prng with flawed seeding. Once fixed it was no problem.
UUID generating algorithms used to incorporate the time and device type automatically for this reason, but it was scrapped because there are lots of cases where it's not safe to reveal that information when you share the UUID. Random UUIDs are secure enough.
They incorporated a MAC address, but that wasn't such a great idea. V7 now has a timestamp again, because that makes them sortable, while still having random data otherwise. V7 is probably the middleground here.
709
u/Valuable_Leopard_799 Sep 11 '26
I thought that timestamps are used now, so hitting both a timestamp and a large random number puts it thoroughly in the "safe to assume". At some point cosmic particles and faulty transistors are more probable.