I was explaining UUIDs to a junior colleague today, who was hung up on the idea of probabilities, and it lead to an interesting viewpoint.
A UUID is a Universal Unique IDentifier. They’re used all over the place in IT: as database identifiers, unique file names, etc. Here’s one:
67fbd46e-7609-477f-b5c3-edf98bbbb511
I generated that on Linux by typing
uuid -v4
Of course, there are many libraries for all the major programming languages as well.
There are different types of UUIDs, and some depend on the issuer (i.e., you) setting a namespace, which then puts you in charge of ensuring that everything in your namespace is unique. Here I’m talking about v4, which uses for purely random generation.
When I issued the above command, my computer didn’t go talk to some global registry that keeps a list of all the UUIDs issued. Instead, the uuid utility went through a series of random number generations to produce the above. So if my computer generates 67fbd46e-7609-477f-b5c3-edf98bbbb511, what’s to prevent your computer from generating the same number and having a collision?
Nothing. Except math. Usually. And then there’s that revolver gamble.
The odds of two randomly-generating UUIDs colliding (having the same value) is 5.3×1036. For comparison, there are about 6×1023 silicon atoms in the universe, so you could give every silicon atom its own UUID and still have plenty leftover (the precise calculation is left as an exercise for the reader).
However, you may recall when I said my computer wasn’t checking out some guaranteed unique number from a registry, but generating it randomly itself? Do you see a problem there?
My Linux box is using whatever standard library the uuid utility uses, and I’m sure it’s engineered to be the best possible. But what if you’ve got a laptop running CrapOS and CrapOS has a horrible random number generator? As RFC 4122 puts it:
Distributed applications generating UUIDs at a variety of hosts must
be willing to rely on the random number source at all hosts.
In practice, this is more of a theoretical rather than an actual risk, because everyone uses standard libraries and no one has a motive to do something stupid.
But back to my colleague. Her concern was that there could still be a collision someday. My opinion was that at a certain level of odds, you just assume it’s not going to happen. However, my associate noted that there is always an implicit risk/reward calculation.
If there is a UUID collision at some point, what really is the damage? A database error or some web app can’t process a POST. Since the collision is probably not going to be a serious problem, the risk is acceptable.
But what if someone made you the proposition that you can play a game of Russian roulette and if you survive, you will receive $1 billion. Would you play? Most people would say no, because even though you have an 83% chance of winning, the risk is your life.
What if it was a 20-chamber gun? Even with a 95% chance of a wonderful outcome, you wouldn’t play. A million-chamber game? No.
But one in a UUID? Probably not. But didn’t I just say we “assume it’s not going to happen”? It’s not going to happen. You’re perfectly safe. But there’s a chance…
How about you? Would you pull the trigger in Russian roulette if the there were 5.3×1036 chambers and payoff was $1 billion? Let us know in the comments below.
I also enjoy using LEBs! I have an empire of little guys for VPNs, larger guys for apps, and big guys for databases and storage. When I'm not in front a screen I'm into German Shepherd dogs, quality knives, target shooting, theology, tabletop roleplaying games, and forest hiking.
I enjoy writing technical articles here on LowEndBox to help people get more out of their systems. You can find me on LowEndTalk @raindog308
- Artificial Intelligence Wants Lower Pricing on LowEndBox’s Black Friday - November 26, 2024
- Cheater Pants! Some Providers are Posting Black Friday Deals Early…and You’ll Love Them - November 25, 2024
- LowEndBoxTV: AMD Shootout: Ryzen vs. Epyc – Which is Right For You? - November 24, 2024
Leave a Reply