Similar to other comments, I've only encountered v4 in my career. Is there a large domain where v1 is the norm that dominates the statistic, and most people happen to not work in that domain? If the author knows, I wish they'd say.
UUIDs are obsolete in the age of Docker
11–20 of 39 posts
Re: UUIDs are obsolete in the age of Docker
#12> this is only correct about UUID version 1. However, it is what most applications use. This is a bold claim and doesn't match my experience at all. UUIDv4 is all I see, everywhere, everyday. That's also a big enough caveat to put in the title: if you have a beef with UUIDv1, say UUIDv1 is obsolete.
Yeah I agree that this isn't true, every popular uuid package uses V4 by default and all the places I've worked used V4 when they were using UUIDs.
Third-ing this opinion. Can’t remember the last time I saw v1 used in a design.
Re: UUIDs are obsolete in the age of Docker
#13> They are awful as keys – being strings, comparisons are dramatically slower than with integers. And even if your database has a UUID type, it’s still worse because the identifier doesn’t fit into a machine word.
I’m just a bit confused, a UUID is made up of hexadecimal digits, so why would it be stored as a string? It’s also 128 bits long, so it should fit into two words, excluding whatever overhead the DBMS puts on the data type, which is really their problem to worry about.
Re: UUIDs are obsolete in the age of Docker
#14> If you require a globally unique string ID, consider URIs Is my knee-jerk judgement that this advice borders on nonsense, unwarranted?
> Is my knee-jerk judgement that this advice borders on nonsense, unwarranted?
No, the advice is nonsense. URIs in what scheme?
I mean, since URN has a URI scheme and UUID is a URN namespace, so urn:uuid:uuid-value> is a URI, “use a URI” is not really a mutual-exclusive alternative to using UUID, its just much less specific.
Re: UUIDs are obsolete in the age of Docker
#15As the article points out, this is only an issue with UUIDv1. They claim "However, it is what most applications use." but I have no idea how true this is. I was under the impression that the vast majority of UUID generators were v4 by default. For example: Postgres only offers random uuid generation ( https://www.postgresql.org/docs/15/functions-uuid.html ). The `uuidgen` CLI tool, at least for modern versions (I hav…
Isn't the string comparison claim also wrong?
Although plenty of UUIDs are passed as strings in eg JSON, I was under the impression that where performance really matters (like db indexes) they were stored and compared as 128 bit fields. To be fair, the points about word sizes and ordering make sense.
Re: UUIDs are obsolete in the age of Docker
#16> Note: this is only correct about UUID version 1. However, it is what most applications use.
Okay, so, not all UUIDs, just v1. And, for some anecdata, I've actually only interacted with UUID v4 in my entire career; I don't know what the actual norm is, but I'm surprised to hear that it might still be v1.
> The only other practical option is version 4 – the random UUID – but random is intuitively worse, right? Read on to find out.
Oh… how is it worse?
> * They are awful as keys – being strings, comparisons are dramatically slower than with integers. And even if your database has a UUID type, it’s still worse because the identifier doesn’t fit into a machine word.
> * They are excessively long – each character of a UUID only encodes 3.5 bits of information if you count the dashes. That’s twice as less compared to 6 bits of Base64.
Sorry, UUIDs are not strings, they're 128-bit integers. They have a standardized string representation, but if you're storing a UUID as a string, you're either being required to because your language/db/tools/etc. don't support UUIDs correctly, or you're doing it wrong.
> * They are not time-ordered – despite containing a timestamp, its bits are mixed up within the UUID: the top bytes of the UUID contain the bottom bytes of the timestamp. Databases do not like an unordered primary key – it means that freshly inserted rows can go anywhere in the index. And you can’t use UUIDs for ad-hoc time sorting by time, either.
This is definitely a drawback when using a UUID as a primary key, and there are alternatives for this specific use-case. However, I think the best solution I've seen to this is to use a typical 64-bit integer for the primary key, but a UUID for a user-visible ID (so that you don't leak information about the primary keys to users); this makes joins and indexes fast, but avoids the leak to the end-user.
> * They are bad for human comprehension – UUIDs tend to look alike, and it’s hard to visually seek and compare them. This comes from experience.
This is exactly why they shouldn't be used as an Id anywhere that a human needs to interact with one. In the above solution I mentioned, the most common ID for which you'd want to use a UUID is the user's id—the user specifically has no reason to ever refer to their or anyone else's id; they'll use the human-readable username/handle equivalent instead. And developers don't need to care about UUIDs ever because inside the db, you'd have the integer primary key that you use for joins. This seems to solve all the problems?
> I kindly suggest that UUIDs are never the right answer.
Honestly, I think you've only convinced me that UUID v1 is never the right answer… and I think that's mostly been true since v4 came about.
All the best,
-HG
Re: UUIDs are obsolete in the age of Docker
#17In practice, I generate UUIDs entirely using entropy from /dev/random. The probability of a collision is really low for most use cases (although not if you are Google and need something unique across all database rows in your company or something similar).
Re: UUIDs are obsolete in the age of Docker
#18As the article points out, this is only an issue with UUIDv1. They claim "However, it is what most applications use." but I have no idea how true this is. I was under the impression that the vast majority of UUID generators were v4 by default. For example: Postgres only offers random uuid generation ( https://www.postgresql.org/docs/15/functions-uuid.html ). The `uuidgen` CLI tool, at least for modern versions (I hav…
> What's an example of a system that generates v1 uuids by default?
MySQL. One of many reasons to avoid it.
Re: UUIDs are obsolete in the age of Docker
#19I've never thought UUIDv1 was useful in any virtualized context, and I hope it should be obvious, but maybe it's worth stating in the UUID generation docs. It is already explained somewhat well what the versions are in Python docs.
However, with all the things already supporting UUID, I also don't see any reason to switch from UUIDv4 to anything else. I don't see how UUID, in general is obsolete, with the support it has from different libraries, and databases.
Re: UUIDs are obsolete in the age of Docker
#20> They are awful as keys – being strings, comparisons are dramatically slower than with integers. And even if your database has a UUID type, it’s still worse because the identifier doesn’t fit into a machine word. I’m just a bit confused, a UUID is made up of hexadecimal digits, so why would it be stored as a string? It’s also 128 bits long, so it should fit into two words, excluding whatever overhead the DBMS puts o…
This is a non-uncommon mistake. People, such as the author, seem to think that the UUID is a hex string containing dashes, since that is the format that they most frequently see them represented.
You are correct that a UUID is a 128 bit identifier, and so, fits in 128 bits.