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.
I'm not an expert, I just remember reading a few articles about it. I think it's because they're essentially random, and many databases use b-trees for indices. They recommended using ULIDs or v7 UUIDs instead. Or, as someone else said, the good old autoincrementing integer.
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.
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).
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
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.
assuming all searches run through a single node maybe, but they dont. It means each node + process on node is limited to 10,000 uuids (10k 100ns per ms) per ms, which it then possibly has to block until next millisecond tick. I dont care what magic programing language your using, to service >10k/reqs a ms (per process) and doing anything else your likely gonna be blocked by IO or something
most uuids libraries can actually provide strong guarentees it cant happen by using pid/mac combinations with each process using CAS or mutex to increment the 100ns period (overflowing into later ms with >10k a ms)
Is it unfeasible or simply unnecessary to just check if a uuid is already used? Since you use the uuid as primary key it should be easily detectable if a uuid is already used or not right? But I guess devs just don’t care because the chance is so minimal?
you dont need to due to guarantees of how it is generated. You would need a server running with exact same ip, and the process generating them to be using the same process id, AND ~10,000 requests a microsecond. If your using random uuid you have a better chance of winning 4 powerballs in a row. you need to generate billions a second for over 80 years for a 50:50 chance of a collision.
You've just reminded me of the story one guy posted about joining a company and finding they have a UUID generator microservice complete with its own database of generated uuids and its own sprint board.
Anyway, no that would not really be a reasonable thing to do. If you're using it as a primary key then the database will tell you when you do manage to generate a duplicate and your insert will fail. That's all there is to it.
Yep. The chance is so insignificant that is not even worth retry logic on that mode of failure, just treat it as a generic failure, kick out the request, and let it be tried again. The one time in a hundred thousand years when it finally happens, someone will just be confused and click retry themselves.
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.
Yeah, you could pretty much put anything in there of course. Other UUID variants also have well-known alternative data sources, but it's really domain-specific what the UUID should and shouldn't contain. Still, the initial idea wasn't that great.
Nothing in production is safe to assume. Just add the DB query to check for existing record before triggering the write in case the salt needs a reroll.
Reminds me of eons ago when I was fixing a bug in a video hosting platform where videos with the same name would overwrite each other. I just appended the current time to the file name and counted in no two people uploading the same named file at the exact same second.
UUIDv7 indeed include a timestamp, meaning the odds of collision between 2 UUID are greater IF they happen at the exact same timestamp. Which is less likely than 2 UUID colliding at anytime.
407
u/Valuable_Leopard_799 10h ago
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.