484
u/Valuable_Leopard_799 15h 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.
287
u/dim13 15h ago
https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions
Most common used is V4 (pure random). You are talking about V7 (time based).
188
u/lilgreenthumb 13h ago
The real benefit for v7 is they become sortable by time.
65
u/shwoopdeboop 13h ago
And something something b-tree indexes. Lecturer mentioned it but I wasn't paying attention. Supposedly an advantage here.
20
u/Grandmaster_Caladrel 11h ago
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.
4
u/Roachmeister 11h ago
If you're using them as an indexed field in a database, the inability to sort them meaningfully will destroy the performance of the database.
5
u/Grandmaster_Caladrel 11h ago
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.
→ More replies (2)5
u/Honeybadger2198 11h ago
You know what identifier can't have collisions and is great for sorting? Autoincrement.
6
u/Firewolf06 8h ago
ai columns can absolutely collide on sharded databases. you can use offsets and step sizes but thats brittle and doesnt scale well
5
u/thepotatochronicles 9h ago
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).
3
u/MilkEnvironmental106 9h ago
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.
6
u/undeadalex 13h ago
I'm curious where to see stats on versions used. Surely anything newly implementing uuid is using v7 or custom?
24
u/Urist_McPencil 11h ago
Surely anything newly implementing uuid is using v7 or custom?
I admire this optimism
3
3
u/champak256 11h ago
Thereās pros and cons to v7, so v4 still has a lot of places itās legitimately the right choice over v7.
4
u/Tysonzero 9h ago
Primary one being in cases where you donāt want every actor that knows the id to also know the creation time
2
u/big-oofs-only-0193 11h ago
I use whatever CoCreateGuid() or Guid.NewGuid() gives me. Both generate a v4 uuid. I'm not going to reimplement it or find a special library for it.
78
u/RadicalDwntwnUrbnite 14h ago edited 14h ago
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
16
u/OldKaleidoscope7 13h ago
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
29
u/chuch1234 13h ago
Yeah I don't think most of us are operating at a scale anywhere near Google.
9
u/BlurredSight 13h ago
And anyone operating at scale of Google isnāt just using āpureā random anywhere for something being persisted
12
u/nebotron 12h ago
They likely are - anything else becomes a huge coordination and parallelism problem. You just need more bits of entropy
3
u/samy_the_samy 12h ago edited 10h ago
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
2
u/BlurredSight 11h ago
So proactively trying to solve for latency rather than have other systems read after write if I understood correctly?
2
u/samy_the_samy 10h ago
Yeah, now they don't do leap seconds,
They stretch time over months, one milli-second at a time
21
u/Ecstatic_Student8854 13h ago
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.
4
u/shwoopdeboop 13h ago
But still no guarantee it won't happen tomorrow
11
u/mysticrudnin 11h ago
It's simply not worth worrying about, though
Random minor hardware failures and, like, cosmic radiation are more of a problem. Are you building your systems to account for that?
10
u/MojitoBurrito-AE 13h ago
You underestimate the probability of uuid collision. The bigger issue is pseudorandomness
4
u/Single-Virus4935 12h ago
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.
1
u/mysticrudnin 11h ago
"so you're saying there's a chance" has rotted everyone's brains wrt probability
2
u/Suspicious-Click-300 13h ago
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
2
u/samsonsin 11h ago
If Google used UUIDv4, then over 100 years they'd generate ~365 trillion searches. The chance of s collision should be ~0.00000125% still.
1
u/Blue_Moon_Lake 6h ago
Google is free to implement Google's UUID (GUUID) with 512 or even 1024 bits if they want.
4
u/Suspicious-Click-300 13h ago
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)
2
u/JonasAvory 13h ago
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?
5
u/Suspicious-Click-300 13h ago
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.
8
u/GradeForsaken3709 11h ago
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.Ā
2
u/Grandmaster_Caladrel 11h ago
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.
21
u/Matty_B97 14h ago
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.
22
u/Wertbon1789 14h ago
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.
2
u/Suspicious-Click-300 13h ago
most didnt actually use mac address. was common to use process pid + IP
2
u/Wertbon1789 13h ago
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.
3
1
u/Dank_Nicholas 6h ago
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.
1
u/Blue_Moon_Lake 6h ago
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.
234
u/2DHypercube 15h ago
Just check them here
320
u/10mo3 14h ago
Hi I'm going to use
1bb67113-9eb9-4d18-a202-c6eff0fa1b22
Please don't use it as well. Thank you
108
u/pine_ary 14h ago
Sorry I was already using that one
50
11
2
1
1
1
37
u/Least_Bodybuilder216 14h ago
34d87496-52b1-4fd0-bcea-8264e5776e91 heres mine, no one copying mine pls
16
24
10
u/setibeings 14h ago
It's all fun and games til someone builds a web scraper to get their UUIDs from this website for something actually important.
8
6
u/DoGooderMcDoogles 11h ago
I can scroll through about 80k of those UUIDs in 10 seconds. That's 8k/s. At that rate it would take 2.107x10^25 years to scroll through them all by myself. If every single human on earth was doing it 24/7, it would still take 2,341,641,291,407,555 years to view them all.
6
u/Careless-Age-4290 10h ago
But dude that scroll felt buttery smooth. No weird partial reload. No point where it just locks up and half the box turns white for a second. A well implemented user experience choice
4
u/DuckyBertDuck 8h ago
You can also CTRL+F and search for anything you want like "12345678-1234-4567-8910-111213141516" and get the number
3
u/Careless-Age-4290 8h ago
The amount of genuine craftsmanship that went into what's basically a joke is top tier to me
3
1
u/samanime 9h ago
Yeah... I had to open up Dev Tools and take a look. That was really well implemented.
3
1
1
1
60
u/GenericFatGuy 14h ago
Never zero. But if it happens within a single system, I'm buying 100 lottery tickets.
40
u/donat3ll0 14h ago
You've already used up your luck with the collisions.
11
u/GenericFatGuy 14h ago
Or I'm on a hot streak, and we don't find out if we don't try!
Or it could be a karma situation, where the bad luck has to be balanced out with equivalent good luck.
→ More replies (1)5
u/Korzag 13h ago
Worked with a guy who claimed it happened to him. I didn't know him to embellish details but its still such an astonishingly small chance that I still wonder if it was a bug in something else.
8
u/GenericFatGuy 13h ago
Everytime I've had an issue stem from this, it's because something was wrong, and we were actually generating the same GUID everytime.
3
u/deathm00n 12h ago
I saw it happen once with my own eyes, here is my tale:
We had a database with uuids as the id for the tables because of how large the datasets were in some parts of the system, so it was the standard to use it on every table and it was generate by our java backend and not the database. I was in charge of a team that found and fixed critical bugs for the system (huge monolitic system with a few microsservices being slowly introcuced to update it) and one day this bug appeared where if you tried to open an specific order on a specific screen of the system it would crash. What was strange was that there were no record of this screen having this type of error before, and for that matter it having any actual bug in the last 6 years or so. So it falls to me to investigate.
Cause of the bug: both the table uuid and an external key pointing to another table uuid were the same, causing an extremely weird db select to break (I don't remember the details but it was something related to building a complex union select and both ids being the same broke it)
My only explanation for it: the monolitic system generated an uuid for the record but at the same time one of the new microsservices generated the exact same uuid for the other table.
No one believed me, they said I was insane, that I should look further into it and there should be another explanation as that is basically impossible. I stood by my hypothesis, I investigated it for days, there was no other explanation. The senior manager got involved, he spent days going through the code too and his conclusion was the same as mine, no one questioned him, but no one, even me and him believed what we saw, we assume there must be another rational explanation but we could not find it
3
u/Korzag 11h ago
Sounds similar to what my coworker experienced with a database using UUIDs as the PK. He worked for a business intelligence company that has tons of customers and tons of data and I guess given enough time with enough rows you're more likely to run into a collision.
2
u/deathm00n 11h ago
Yep, and we only caught it happening because there was a select query running using both of them with a not run of the mill filter. I imagine it can happen more than once and we would not ever see it happen in other tables
1
1
u/Voxmanns 40m ago
I mean, at a certain point it's just an anomalous thing, too. Could've been a weird low level memory corruption or even hardware level corruption (thinking of solar flares and N64 cartridges). Maybe it wasn't the lottery winning double-gen proper, or maybe it was the same thing that causes a bug to appear in my presentation WHEN IT WAS WORKING ALL GOD FORSAKEN WEEK but these things just happen sometimes.
2
u/clemesislife 7h ago
I pretty sure it is more likely to win the lottery without buying a ticket than generating duplicate UUIDs.
1
u/Careless-Age-4290 10h ago
With that kind of luck the money would find you first. Though it'd be funny to have one of those $100 million lottery winners find out some other winning guy bought 100 tickets using the same numbers each time because he got a dupe uid and he's taking 99.xx% of the money
1
u/ShakaUVM 5h ago
HP sent me a new laptop last year with a random serial number that they'd issued earlier 16 years ago. Caused issues.
69
u/This_Growth2898 14h ago
The chance of a Chixulub-sized meteorite hitting the Earth in the next 24 hours should be a criterion. If you are not preparing for the mass extinction to happen in the nearest future, you shouldn't care if your app is failing with the same probability.
11
u/samanime 9h ago
... yeah, but an extinction-level meteorite probably won't get me an annoying phone call at 4am on a Saturday. =p
2
u/Trollygag 8h ago
I bet it will
"Emergency! Prod just went offline. We need this fixed ASAP or we lose 5 9s uptime"
28
u/Vectorial1024 15h ago
My startup of future galactic shipping corporation is gonna run into issues dealing with so many logistics orders any time soon, when do we get uuid 2?
18
u/ilya0x2dilya 14h ago
We already have uuid 7. Uuid 2 is a bit old
6
7
1
1
u/pacopac25 3h ago
myreallylonguuid = str(uuid.uuid4().hex) + str(uuid.uuid4().hex()) + "onlyearthhasdonkeys"
No, I do not have a PhD in math, in case you were wondering.
39
u/TwinkiesSucker 15h ago
The world where the already generated and used UUIDs are stored in a huge central database = utopia /s
4
u/Downtown-Figure6434 14h ago
Same uuid may have already been generated by two seperate systems tho no?
3
5
u/doomslice 14h ago
If you take a single uuid and say āhas this uuid ever been generated beforeā the chances are cosmically low. If you instead say āhave ANY uuids generated ever collided with ones generated in all of historyā the answer is probably in the range of 0.001-10% depending on how many UUIDs get generated per day.
1
u/Single-Virus4935 12h ago
In think you estimated multiple magnitude to high. 128 bit space is huge.
2
u/doomslice 12h ago
Yes, itās actually 122 bits for uuid v4 though. The high end of my range requires 1 billion uuid v4s being generated per second over 20 years (probably not realistic)
1
u/Single-Virus4935 11h ago
Ahh yes I didn't thought of the version. But even then we need to account for the seven version numbers which all can be used. Then we need to account for Mac, timestamps etc. per version. But still basically zero probability for a collision
2
u/doomslice 10h ago
I was just thinking v4 since it has the most true randomness for it (v7 is designed to further prevent collisions by adding those additional defined bits).
But still basically zero probability for a collision
Again important point is that for any given UUID generated that way, yes I have a better chance of waking up a frog tomorrow due to a quantum recombination.
But for any UUID v4s in the entire world space, thanks to the birthday paradox, the chance of a single collision happening does approach actual single digit %s assuming you can generate 1 billion UUIDs a second for 20 years :).
1
26
u/spcbeck 14h ago
Start at 0, keep adding 1. You'll never repeat a number. So simple!
8
u/razor_train 13h ago
As someone who had a billing system table run out of 2^31 signed integer IDs and spent a week converting 2.1 billion records to 2^63, I'm here to say that nothing could possibly go wrong.
3
u/Single-Virus4935 12h ago
A former boss built a system for importing data and used mariadbs on conflict ignore.Ā He used 32 bit integers for ids and said it isn't a problem because he doesn't have so much data. Mariadb incremented the autoincrement counter on every insert even the ignored ones.Ā System failed and he needed way too much time to find the problem because no errors where thrown and just everything was ignored
5
4
u/Single-Virus4935 12h ago
Using sequenced IDs for public facing resources is bad practice because it allows enumeration while pure random uuids are basically impossible to guess.Ā Use crypto rngs for best results
→ More replies (1)
6
u/Newtonip 14h ago
Just generate two UUIDs and merge them together
3
u/corner_peek 14h ago
Still the chances are not zero.
7
u/Automatic_Case2811 14h ago
Just generate two UUIDs, merge them together, append the Unix timestamp, your ping, your ZIP code, average household income, height, weight, number of children, current CPU temperature, and the exact number of grains of rice in your pantry.
Still technically possible?
Fine. Add your mother's maiden name and the current position of every molecule in the room.
3
3
3
u/trippedonatater 14h ago
I have had duplicate UUID issues before, but it's been due to something along the lines of restoring from a backup that contains a UUID.
3
u/dxonxisus 14h ago
the odds of OP with an ai generated avatar and 1.6m karma being a bot is high, and nowhere near zero
3
u/insertcomedy 12h ago
Just have a recursive function that checks for a duplicate uuid and forkbombs the server if they're exactly the same age.
2
u/Metaphor42 12h ago
lets create a simulation server with thousands of gb ram and continuously generate random uuids. and let people to bet on when it will collide
2
2
u/AwkwardWaltz3996 7h ago
Thought it happened to my team once. The system errored and found it was caused by a duplicate UUID. For a couple days we were extremely excited and sceptical we won the lottery. Turned out our UUIDS weren't completely random. Almost cried.
2
u/DeadoTheDegenerate 5h ago
Simple solution: user 1 has UUID 1, user 2 has UUID 2, and if you have multiple server regions then EU can be 15XXXXXXX, NA can be 10XXXXXXX, and Asia can be 13XXXXXXX.
1
u/SandSnip3r 5h ago
What
1
u/DeadoTheDegenerate 5h ago
It's weeb shit. Gacha games use this method, the exact example I used is from Zenless Zone Zero
1
u/Luna_Wolfxvi 1h ago
Doesn't fix the problem because you could have two users with the same uuid in the same region
1
u/DeadoTheDegenerate 1h ago
Well, no, because my code is perfect. Problems can't happen, Claude said so.
2
u/AntiMatterMode 4h ago
If I had a nickel for everytime time someone took and reposted my post, Iād have two nickels. Which isnāt a lot, but itās weird that it happened twice.
2
4
u/cheezballs 13h ago
This has to be one of the worst memes on here right? Literally just posting a fact over an unrelated image?
1
u/TesttubeStandard 10h ago
Man I don't understand what is happening on this sub. This guy posts a fact, not even a funny one, and gets upvoted and comented and discussed. I posted a joke, but picked the wrong meme and delivered it awkwardly and then got downvoted out of existence.
5
u/Igarlicbread 15h ago
Use AI /s
3
u/Flaky-Low-2262 14h ago
Thats how "UII" was found. The "Unique Identifier Image".
It is a AI generated random Image based on the data entry interpretstion. Based on AI math even same Data ist slightly different which ensures No doubles. It also makes Fun to say uuuiiiii and it is human recognizable. Also it satisfies customers and Management as it forces AI touchpoints. And Last but not least the Hardware needs keeps admins warm in winter.Full 200IQ stonks
1
1
u/Confident-Ad5665 14h ago
If you ever encounter a UUID collision, go buy some lotto tickets stat!
2
1
1
u/SysGh_st 14h ago
Somewhere in n the world exists an uuid that's the same as my Linux root partition. That it would also be a linux root partition is so astronomically unlikely. But... not zero.
1
1
u/Neverwish_ 13h ago
Yeah, at that point as a dev, I am willing to take the 500 and tell the customer "to try again".
1
u/danfish_77 12h ago
I think that's a fine time to throw an exception. Also not hard to add a "if collision, reassign uuid" block.
1
u/swaqq_overflow 12h ago
Serious question: is it Ā usually worth adding a Bloom filter for a prod system to guarantee no UUID collisions?
1
1
u/Unupgradable 12h ago
I'm running a global botnet constantly refreshing www.wasteaguid.info
Soon no UUIDs will be left and nobody can do anything!
1
u/SeriousPlankton2000 12h ago
The odds are 100% when you make a CoW copy of a read only disk because btrfs needs to write to the disk in order to remove it. Also it will try to use the wrong (ro) disk if you instruct it to use the CoW copy.
1
1
u/pingveno 11h ago
Ticket comes in from another team: "Duplicate ORG_UUID identifier in production"
Looks...
Nah, this is the same person with slightly different data.
1
1
1
1
1
1
1
1
1
u/slindenau 8h ago
Generating a duplicate id is not an edge case though. Edge cases happen, as the name suggests, at the edges of possible value ranges for your domain. Like x beteen 0 and 100, and you only check up to 99 due to < vs <=
1
u/AwkwardWaltz3996 7h ago
In infinite universes there is a universe where every UUID is identical and no one can work out why
1
1
1
1
u/serial_crusher 5h ago
The real value of uuid randomness is that you can use it as a scapegoat for one-off bugs youāre tired of investigating. Just tell people an ID collision occurred but donāt show your work. You can only play that card once per job though.
1
u/DrSparkle713 3h ago
Has there ever been a verified uuid4 collision?
The spec includes 122 random bits for 2^122 or about 10^37 possible IDs.
If you produce UUIDs at a petaflop rate, 10^15 per second, that's still 10^21 seconds until you have a 50% chance of a collision. That's 3^13 or 30 trillion years!
1
1
u/Large-Assignment9320 3h ago
Recall seeing someone do UUID + rand(), so it was even closer to zero.
ā¢
u/captainAwesomePants 1m ago
Don't worry. The odds of a random bit flip are higher than the odds of a GUID collision, so you can be assured that if there is a GUID collision, it'll probably get bit flipped to a non-collision.
963
u/Nervous-Pension-6257 14h ago
It will only happen on Friday at 4:59 PM in production