Hacker News Reader

Comment by edflsafoiewq | Hacker News Reader

I've never understood why UUIDs are... a thing. I understand how it can useful to have a name for different kinds of identifiers, but what is the purpose of adding variant/version bits and unifying different kinds of IDs into a single thing called a UUID? The article for instance never did anything with the "UUID-ness" of the IDs so they might as well have started with "random 128-bit integers".

Can anyone explain this?

View on HN

They're for distributed systems.

The entire point is that different computers can generate ID's that can be merged in a database later on and not collide.

And the way they're designed is less likely to collide than random numbers are. (But you need to pick the appropriate UUID version to ensure that, depending on your system's architecture.)

If you're generating ID's that originate in a single centralized table, you don't need UUID's -- autoincrement or random integer is the simpler choice.

You don't need a UUID for that. A 128 bit random integer will work just fine. Better even, as no bits are wasted on meta data.

I'm getting down votes, presumably because people think what I said is incorrect. Would anybody care to explain how UUIDs can have lower probability of collision than just random bits? (Apart from using a central coordinator for handing them out of course, which would defate the whole point.)

A UUID is random bits. The statement was oxymoron

But it isn't. A UUID is a disjoint-union of several different types of IDs, only one of which is just random bits, and if random bits is all you care about, then "random 128-bit number" is not only clearer but gives more entropy than "version 4 UUID".

That what I'm trying to ask, what is the purpose of this disjoint union, when would you ever use the "UUID-ness" of UUIDs (which is not the same as asking about the virtues of UUIDs of a particular version).

The virtue is, software has some idea what a UUID is. There's a mostly-random version which is also understood.

If you want to start doing your own thing, a random number is good. It's hard to get a good random number. I suggest starting with, hey you guessed it, the UUID library.

It's because this statement:

    You don't need a UUID for that. A 128 bit random integer will work just fine.

Basically reads:

    You don't need a UUID for that. A UUID will work just fine.

The rfc is rather long for a UUID being just a random integer...

But if we're talking about UUID v4, it seems that 122 out of 128 are indeed random. [1] So why not just go all the way? Who cares about these 6 bits of meta data?

[1] https://www.rfc-editor.org/rfc/rfc412

You can easily look it up on Wikipedia. [1]

But version 1 of UUID's, for example, concatenates a MAC address, a timestamp, and a "uniquifying" clock sequence.

As long as you're ensuring your MAC addresses are all unique (which they should be, except for manufacturing error) and only one UUID library per device, collisions are impossible.

Whereas with random numbers, there's always a chance of collisions. (There are also other versions of UUID's that do include randomness, with collision potential, in exchange for not revealing information such as timestamps and MAC addresses.)

[1] https://en.wikipedia.org/wiki/Universally_unique_identifier

Ah, got it. Reading the spec, that seems like an awful lot of trouble to prevent something that will never happen anyway.

Just wondering, can v1 guarantee uniqueness with multiple processes using the same network adapter or within containers?

Okay, thanks. Thinking about it a little more I think I get it.

1. We want a single truly universal namespace.

2. We want to have different methods of generating IDs, since there are a lot of different people in the whole universe and they may have different needs.

3. Each single method is designed to not generate collisions.

4. But there could be collisions between different methods. So some bits are added to show what method was used to generate the ID to guarantee IDs generated by different methods don't collide. This is also why we need a spec that defines what each method is, the versions are like a scare global namespace that needs to be allocated carefully.

I think the reason I found this difficult is most of the times I see UUIDs, (1) and (2) aren't actually needed (this article being representative).

One reason is web scraping. Twitter used to have sequential IDs that made it easy to tell how many users they’d added over a period of time, even after they were public.

How do random 128 bit IDs not fix this problem?

Google+ UIDs were UUIDs (or something looking very much like them).

They were nonsequential and sparse.

For those of us looking to 1) quantify activity and 2) migrate users and data off the system, they were pretty confounding.

Fortunately, Google also provided lists of those UUIDs by way of robots.txt sitemap files.

I used one sample of ~50k of those to estimate total G+ active users as of ~2014 (another group polled a random sampling of 500k for a more precise measurement). And when G+ folded in 2019, I'd provided that information plus some additional bits gleaned over the years and from some additional sources to estimate just how large the archive dataset might be, for ArchiveTeam.

One place where the sparse population might prove really useful is in telephony. Phone numbers as we know them today are densely populated, and in fact, frequently re-used (which is why your new phone is receiving debt-collection calls for its previous holder). It also makes war-dialing or random-dialing viable for robocallers.

If only 1 in 10 billion numbers was valid (about the saturation rate of G+ UUIDs), war-dialing / random dialing would be all but ineffective. If you could dial one number per second, you'd have a 50% chance of hitting a live number ... in 158 years.

(Of course, if you had a listing of valid numbers, again, see G+'s robots.txt files, your search space would be far smaller.)

And what are the hyphens good for? And what is the reason for their irregular placement?

My guess would be readability. Easier to "parse" by humans then just a long string of numbers and letters without "interpunction".

They evolved that way, and the hyphens denote the various parts of UUIDv1, the original version of UUIDs; roughly:

  123e4567-e89b-12d3-a456-426614174000
  ^^^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^^^^^^^
  time lo  time time  seq   node id
            mid  hi

+/- a few bits reserved for version & variant. The random ones are version 4, but they still share the same string representation as v1. (But outside of the bits mentioned in the article, the other bits are just random; the diagram above doesn't apply to v4.) The only thing the hypens really do there is make it easier to see where the version bits are, if you want to visually verify that it's a v4 UUID.

See: https://en.wikipedia.org/wiki/Universally_unique_identifier

Reply on news.ycombinator.com