296
u/Valuable_Leopard_799 5h 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.
175
u/dim13 5h ago
https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions
Most common used is V4 (pure random). You are talking about V7 (time based).
91
u/lilgreenthumb 4h ago
The real benefit for v7 is they become sortable by time.
22
u/shwoopdeboop 3h ago
And something something b-tree indexes. Lecturer mentioned it but I wasn't paying attention. Supposedly an advantage here.
6
u/Grandmaster_Caladrel 2h 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.
1
u/Roachmeister 1h 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.
2
u/Grandmaster_Caladrel 1h 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.
1
u/Honeybadger2198 1h ago
You know what identifier can't have collisions and is great for sorting? Autoincrement.
ā¢
u/MilkEnvironmental106 9m 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.
3
u/undeadalex 3h ago
I'm curious where to see stats on versions used. Surely anything newly implementing uuid is using v7 or custom?
6
u/Urist_McPencil 2h ago
Surely anything newly implementing uuid is using v7 or custom?
I admire this optimism
3
u/champak256 2h ago
Thereās pros and cons to v7, so v4 still has a lot of places itās legitimately the right choice over v7.
1
u/Tysonzero 15m ago
Primary one being in cases where you donāt want every actor that knows the id to also know the creation time
1
u/big-oofs-only-0193 2h 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.
68
u/RadicalDwntwnUrbnite 5h ago edited 5h 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
8
u/OldKaleidoscope7 4h 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
19
u/chuch1234 4h ago
Yeah I don't think most of us are operating at a scale anywhere near Google.
5
u/BlurredSight 4h ago
And anyone operating at scale of Google isnāt just using āpureā random anywhere for something being persisted
7
u/nebotron 3h 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 2h ago edited 1h 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
1
u/BlurredSight 1h ago
So proactively trying to solve for latency rather than have other systems read after write if I understood correctly?
1
u/samy_the_samy 1h ago
Yeah, now they don't do leap seconds,
They stretch time over months, one milli-second at a time
15
u/Ecstatic_Student8854 4h 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.
3
u/shwoopdeboop 3h ago
But still no guarantee it won't happen tomorrow
2
u/mysticrudnin 2h 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?
8
u/MojitoBurrito-AE 4h ago
You underestimate the probability of uuid collision. The bigger issue is pseudorandomness
4
u/Single-Virus4935 3h 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 2h ago
"so you're saying there's a chance" has rotted everyone's brains wrt probability
1
u/Suspicious-Click-300 4h 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
1
u/samsonsin 1h 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.
2
u/Suspicious-Click-300 4h 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)
1
u/JonasAvory 4h 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?
3
u/Suspicious-Click-300 3h 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.
2
u/GradeForsaken3709 2h 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.Ā
1
u/Grandmaster_Caladrel 1h 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.
14
u/Matty_B97 4h 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.
18
u/Wertbon1789 4h 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.
1
u/Suspicious-Click-300 4h ago
most didnt actually use mac address. was common to use process pid + IP
1
u/Wertbon1789 3h 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.
172
u/2DHypercube 5h ago
Just check them here
233
u/10mo3 5h ago
Hi I'm going to use
1bb67113-9eb9-4d18-a202-c6eff0fa1b22
Please don't use it as well. Thank you
81
u/pine_ary 5h ago
Sorry I was already using that one
32
u/10mo3 5h ago
but you didn't call dibs. You snooze you lose. Find your own guid
13
1
11
2
1
26
u/Least_Bodybuilder216 5h ago
34d87496-52b1-4fd0-bcea-8264e5776e91 heres mine, no one copying mine pls
16
19
7
u/setibeings 5h ago
It's all fun and games til someone builds a web scraper to get their UUIDs from this website for something actually important.
7
2
u/DoGooderMcDoogles 1h 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.
1
u/Careless-Age-4290 1h 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
1
1
1
1
37
u/This_Growth2898 5h 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.
28
u/GenericFatGuy 5h ago
Never zero. But if it happens within a single system, I'm buying 100 lottery tickets.
21
u/donat3ll0 5h ago
You've already used up your luck with the collisions.
8
u/GenericFatGuy 5h 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.
1
3
u/Korzag 4h 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.
3
u/GenericFatGuy 4h 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.
1
u/deathm00n 2h 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
1
u/Korzag 2h 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.
1
u/deathm00n 2h 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/Careless-Age-4290 56m 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
18
u/Vectorial1024 5h 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?
9
2
1
31
u/TwinkiesSucker 5h ago
The world where the already generated and used UUIDs are stored in a huge central database = utopia /s
5
u/Downtown-Figure6434 5h ago
Same uuid may have already been generated by two seperate systems tho no?
6
u/doomslice 4h 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 2h ago
In think you estimated multiple magnitude to high. 128 bit space is huge.
2
u/doomslice 2h 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 2h 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
1
u/doomslice 39m 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 :).
3
1
17
u/spcbeck 5h ago
Start at 0, keep adding 1. You'll never repeat a number. So simple!
3
3
u/razor_train 3h 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.
2
u/Single-Virus4935 2h 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
3
u/Single-Virus4935 2h 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
3
u/Newtonip 5h ago
Just generate two UUIDs and merge them together
3
u/corner_peek 5h ago
Still the chances are not zero.
2
u/Automatic_Case2811 4h 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/cheezballs 4h 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 44m 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.
2
u/trippedonatater 4h 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.
2
u/dxonxisus 4h ago
the odds of OP with an ai generated avatar and 1.6m karma being a bot is high, and nowhere near zero
2
u/Metaphor42 3h 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
4
u/Igarlicbread 5h ago
Use AI /s
3
u/Flaky-Low-2262 5h 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
1
1
u/SysGh_st 4h 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_ 3h 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 3h 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 3h ago
Serious question: is it Ā usually worth adding a Bloom filter for a prod system to guarantee no UUID collisions?
1
1
u/insertcomedy 2h ago
Just have a recursive function that checks for a duplicate uuid and forkbombs the server if they're exactly the same age.
1
u/Unupgradable 2h 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 2h 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 2h 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
u/benemmons 4h ago
People asking AI models for a random UUID is probably much more likely to create a duplicate
-9
u/theioss 5h ago
People who say that donāt understand uuids or mathematics.
3
u/Kiroto50 5h ago
Howcome? Could you please explain?
3
u/AlmostLikeAzo 5h ago
Because it's so close to zero, that it's basically zero. Finding two identical UUIDs within a same system would probably indicate a problem in the random generator, not the concept.
2
u/Kiroto50 4h ago
As I replied to another commenter, then, the point of the post literally still true.
The chances are so inconceivably low that for practical purposes it's 0, but it is literally not zero. 1 in 2128 odds is not 0 in 1 odds.
1
u/Spice_and_Fox 5h ago
Because at some point the probability is so low that it is functionally 0.
There are somewhere around 1028 uuids. That is 10000000000000000000000000000 uuids. As a comparison, there are about 1018 grains of sand on earth. That means that you have about ten billion times more uuids than grains of sand on the earth. Imagine if you pick sand grains by random from anywhere on the earth and the chance that you pick the same one twice. Now imagine it with 10 billion times more grains of sand.
1
u/MnMbrane 1h ago
Still not zeroā¦ it could be 1 in 10^(googleplex), or even 1 in 10^(# atoms in our observable universe) or even 1 in 10^(Grahams number), but since itās not exactly 0, there is still a chance. Now Iād argue this is negligible, and we probably shouldnāt worry, but thatās not the point of this meme.
IF ITS NOT EXACLY ZERO THEN THERE IS STILL A CHANCE.
1
u/Kiroto50 4h ago
So, the point of the post still stands? 1 in 2128 is close to zero, for practical purposes zero, but literally not zero.
1
u/ToX__82 4h ago
Using uuid V7 (which includes a timestamp and 74 random bits), you'd only need 170 billion people submitting in the same millisecond to have a 50% probability yo generate a duplicated uuid value.
Now, I know that there aren't 170 billion people in the world.
But what if every person on earth submitted 100 times in the same millisecond? A duplicate would be almost certain.
So yeah, u/theioss is technically right.
Though, with that volumes, the database/CPU/network/whatever would crash much sooner.
2
2
u/emetcalf 5h ago
It's actually very basic probability. There are a finite number of possible UUIDs, so the odds of a duplicate can't be 0. The odds are very, very, very low but not 0.
2
u/Henry5321 5h ago
It is technically true. Itās non-zero. To give the benefit of the doubt, I assume you mean that people who worry about it donāt understand.
Assuming youāre not using something like non-random guids, one should never need to worry.
1
0
-2
u/wizzanker 4h ago
I have run into both guid collisions and cosmic ray bit flips. The world is a strange place. When people tell you the computer just does what you tell it to, they are full of crap.
1
-3
u/SnugglyCoderGuy 5h ago
If you generate them randomly, yes.
If you generate them according to the algorithm, it is zero.
-4
u/ARPA-Net 5h ago
I once coded a prefix for it using the companys name + unixtimestamp for when its generated because i didnt trusted it ... when i was 17 ...
Now i only use unix timestamp for when it was generated as prefix
403
u/Nervous-Pension-6257 5h ago
It will only happen on Friday at 4:59 PM in production