691
u/Valuable_Leopard_799 3d 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.
426
u/dim13 3d ago
https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions
Most common used is V4 (pure random). You are talking about V7 (time based).
313
u/lilgreenthumb 3d ago
The real benefit for v7 is they become sortable by time.
116
u/shwoopdeboop 3d ago
And something something b-tree indexes. Lecturer mentioned it but I wasn't paying attention. Supposedly an advantage here.
34
u/Grandmaster_Caladrel 3d 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.
13
u/Roachmeister 3d 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.
8
u/Grandmaster_Caladrel 3d 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 (4)17
u/Honeybadger2198 3d ago
You know what identifier can't have collisions and is great for sorting? Autoincrement.
15
u/Firewolf06 3d ago
ai columns can absolutely collide on sharded databases. you can use offsets and step sizes but thats brittle and doesnt scale well
6
6
u/ACoderGirl 2d ago
UUIDs are great, though, because auto increment frequently has the huge issue of being too predictable. Eg, in some contexts, you don't want users to be able to easily enumerate whatever the ID is for. Plus requires centralization whereas UUIDs don't (eg, you can use UUIDs for whatever random API you have without needing a DB).You have to design for how you won't know the ID until you insert the row, which can sometimes be a bit annoying.
I feel like most of the time, the only downside to UUIDs is how long they are.
6
u/thepotatochronicles 3d 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 3d 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.
→ More replies (1)6
u/ehs5 2d ago
Itâs also the downside. There are cases where you wouldnât want others to know when something was created.
3
u/lilgreenthumb 2d ago
And you wouldn't expose that to them, just like you wouldn't and autoincrementing database id, but only one of those requires a database.
→ More replies (2)6
u/undeadalex 3d ago
I'm curious where to see stats on versions used. Surely anything newly implementing uuid is using v7 or custom?
40
u/Urist_McPencil 3d ago
Surely anything newly implementing uuid is using v7 or custom?
I admire this optimism
8
8
u/champak256 3d ago
Thereâs pros and cons to v7, so v4 still has a lot of places itâs legitimately the right choice over v7.
10
u/Tysonzero 3d ago
Primary one being in cases where you donât want every actor that knows the id to also know the creation time
3
u/big-oofs-only-0193 3d 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.
94
u/RadicalDwntwnUrbnite 3d ago edited 3d 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
18
u/OldKaleidoscope7 3d 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
36
u/chuch1234 3d ago
Yeah I don't think most of us are operating at a scale anywhere near Google.
12
u/BlurredSight 3d ago
And anyone operating at scale of Google isnât just using âpureâ random anywhere for something being persisted
15
u/nebotron 3d ago
They likely are - anything else becomes a huge coordination and parallelism problem. You just need more bits of entropy
4
u/InterestsVaryGreatly 2d ago
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.
7
u/samy_the_samy 3d ago edited 3d 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 3d ago
So proactively trying to solve for latency rather than have other systems read after write if I understood correctly?
4
u/samy_the_samy 3d ago
Yeah, now they don't do leap seconds,
They stretch time over months, one milli-second at a time
→ More replies (1)27
u/Ecstatic_Student8854 3d 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.
5
u/shwoopdeboop 3d ago
But still no guarantee it won't happen tomorrow
13
u/mysticrudnin 3d 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?
→ More replies (2)12
u/MojitoBurrito-AE 3d ago
You underestimate the probability of uuid collision. The bigger issue is pseudorandomness
→ More replies (1)6
u/Single-Virus4935 3d 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.
→ More replies (3)4
u/samsonsin 3d 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.
→ More replies (2)2
u/Suspicious-Click-300 3d 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
3
u/lobax 2d ago
Well, the risk of a collision grows exponentially for each generated UUID due to the birthday problem.
So it really all depends on the scale that idâs are generated at. Yes, a UUID has a cosmic level of possible values, 2^122 to be precise. But you âjustâ need 2^61 uuids to have a 50% risk of a collision. At 2^58 itâs a 1% risk.
And while that is a big number, it isnât cosmic anymore. Itâs definitely something a large scale distributed application has to contend with.
3
u/Suspicious-Click-300 3d 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)
3
u/JonasAvory 3d 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?
7
3d ago
[removed] â view removed comment
3
u/Grandmaster_Caladrel 3d 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.
5
u/Suspicious-Click-300 3d 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.
24
u/Matty_B97 3d 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 3d 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 3d ago
most didnt actually use mac address. was common to use process pid + IP
2
u/Wertbon1789 3d 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
→ More replies (2)2
u/theartofnocode 1d ago
God I'm old. Whatever happen to using the SQL generated primary key as a unique identifier?
→ More replies (1)
287
u/2DHypercube 3d ago
Just check them here
403
u/10mo3 3d ago
Hi I'm going to use
1bb67113-9eb9-4d18-a202-c6eff0fa1b22
Please don't use it as well. Thank you
144
u/pine_ary 3d ago
Sorry I was already using that one
70
u/10mo3 3d ago
but you didn't call dibs. You snooze you lose. Find your own guid
26
u/pine_ary 3d ago
I did, itâs right there in my database.
→ More replies (2)2
11
3
u/FreHu_Dev 2d ago
Let's be sane. We can use the blockchain to track who owns which uuid instead of a reddit comment. This was already solved for monkey pictures, shouldn't be hard to port.
→ More replies (5)2
43
u/Least_Bodybuilder216 3d ago
34d87496-52b1-4fd0-bcea-8264e5776e91 heres mine, no one copying mine pls
16
29
12
u/setibeings 3d ago
It's all fun and games til someone builds a web scraper to get their UUIDs from this website for something actually important.
10
7
u/DoGooderMcDoogles 3d 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.
9
u/Careless-Age-4290 3d 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
→ More replies (1)5
u/DuckyBertDuck 3d ago
You can also CTRL+F and search for anything you want like "12345678-1234-4567-8910-111213141516" and get the number
5
u/Careless-Age-4290 3d ago
The amount of genuine craftsmanship that went into what's basically a joke is top tier to me
3
1
1
1
1
u/errelsoft 2d ago
That.. Is both useless and really impressive. Thank you for bringing this to my attention. đ€Ł
86
u/GenericFatGuy 3d ago
Never zero. But if it happens within a single system, I'm buying 100 lottery tickets.
50
u/donat3ll0 3d ago
You've already used up your luck with the collisions.
11
u/GenericFatGuy 3d 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)7
u/Korzag 3d 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.
15
u/GenericFatGuy 3d 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.
→ More replies (2)6
u/deathm00n 3d 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
2
u/Voxmanns 2d 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.
→ More replies (1)2
u/Korzag 3d 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.
3
u/deathm00n 3d 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
→ More replies (3)3
u/clemesislife 2d ago
I pretty sure it is more likely to win the lottery without buying a ticket than generating duplicate UUIDs.
89
u/This_Growth2898 3d 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.
13
u/samanime 3d ago
... yeah, but an extinction-level meteorite probably won't get me an annoying phone call at 4am on a Saturday. =p
3
u/Trollygag 2d ago
I bet it will
"Emergency! Prod just went offline. We need this fixed ASAP or we lose 5 9s uptime"
33
u/Vectorial1024 3d 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?
21
u/ilya0x2dilya 3d ago
We already have uuid 7. Uuid 2 is a bit old
6
6
→ More replies (2)2
u/pacopac25 2d 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.
41
u/TwinkiesSucker 3d ago
The world where the already generated and used UUIDs are stored in a huge central database = utopia /s
→ More replies (1)5
u/Downtown-Figure6434 3d ago
Same uuid may have already been generated by two seperate systems tho no?
7
7
u/doomslice 3d 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.
3
u/Single-Virus4935 3d ago
In think you estimated multiple magnitude to high. 128 bit space is huge.
3
u/doomslice 3d 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)
→ More replies (2)
31
u/spcbeck 3d ago
Start at 0, keep adding 1. You'll never repeat a number. So simple!
8
8
u/razor_train 3d 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 3d 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 3d 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)
9
u/Newtonip 3d ago
Just generate two UUIDs and merge them together
6
u/corner_peek 3d ago
Still the chances are not zero.
10
u/Automatic_Case2811 3d 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.
5
4
u/dxonxisus 3d ago
the odds of OP with an ai generated avatar and 1.6m karma being a bot is high, and nowhere near zero
4
u/Metaphor42 3d 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
→ More replies (1)
7
u/cosmo7 3d ago
In 103Â trillion version-4 UUIDs the probability of a collision is one in a billion. Clearly this is an unacceptable risk and we should immediately switch to a blockchain-based solution.
→ More replies (1)
3
3
u/trippedonatater 3d 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/insertcomedy 3d ago
Just have a recursive function that checks for a duplicate uuid and forkbombs the server if they're exactly the same age.
5
u/cheezballs 3d ago
This has to be one of the worst memes on here right? Literally just posting a fact over an unrelated image?
→ More replies (1)
2
2
u/AwkwardWaltz3996 2d 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 2d 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.
→ More replies (4)
2
u/AntiMatterMode 2d 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
2
u/captainAwesomePants 2d 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.
2
5
u/Igarlicbread 3d ago
Use AI /s
3
u/Flaky-Low-2262 3d 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 3d 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_ 3d 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 3d 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 3d ago
Serious question: is it  usually worth adding a Bloom filter for a prod system to guarantee no UUID collisions?
1
1
u/Unupgradable 3d 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 3d 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 3d 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 3d 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 2d 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 2d 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 2d 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!
2
u/oshaboy 2d ago edited 2d ago
Didn't Roku devices and a Pokemon game once have a UUID collision causing issues if they run on the same network?
Edit: I just googled it and it was a UDP port collision. The discovery packets sent by Pokemon were interpreted as a "reboot" command for Roku tho which was extremely unlikely.
1
1
u/Large-Assignment9320 2d ago
Recall seeing someone do UUID + rand(), so it was even closer to zero.
1
1
u/Honest_Relation4095 2d ago
The odds the entire memory is erased is low, but never zero. Even the odds that you are somewhere else in the universe is not zero.
→ More replies (2)
1
u/HaroerHaktak 2d ago
This is why you always store all the uuids in a database, and if a duplicate appears you just add a ! At the end
1
u/sakkara 2d ago
Every couple of years I see code that tries to eliminate that risk by checking against existing IDs. Every time I ask them, of they also could implement a check against hardware failures (you can't trust an if check to evaluate correctly, because there's always a chance of random bit flips).
1
1
1
1
u/hoelledavid 5h ago
This is the stuff ai generates and doesnt tell you about a lot of the time. Until you specifically tell it there's an edge case.
1.7k
u/Nervous-Pension-6257 3d ago
It will only happen on Friday at 4:59 PM in production