Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UUIDs are obsolete in the age of Docker

leonid.shevtsov.me

Post reply on HN
Print view View original

21–30 of 39 posts

Re: UUIDs are obsolete in the age of Docker

#21

Post by fabian2k »

halosghost wrote: post #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 o…

The database argument is also specific to certain databases and table types. It should only matter for clustered tables. So if e.g. I use Postgres, this doesn't matter as it doesn't have clustered tables.

Re: UUIDs are obsolete in the age of Docker

#22

Post by erik_seaberg »

woile wrote: post #7

What about ulid as an alternative?

The ULID spec encourages people to assume they can be sorted in create time order, but it does not handle clock skew. I wouldn’t use it except in a system that can rely on having a single monotonic clock, because I worry about things that are almost true.

Re: UUIDs are obsolete in the age of Docker

#23

Post by coolgoose »

Sometimes, I am amazed about what gets on the front page of ycombinator.

TLDR: Don't use UUID v1, since its entropy is based on the Mac address, if your cloud provider is generating the same mac addresses for all your containers.

To say not use UUID's it makes no sense. Use UUIDv7, use them in postgres https://github.com/fboulnois/pg_uuidv7 have fun :)

Re: UUIDs are obsolete in the age of Docker

#24

Post by erik_seaberg »

fabian2k wrote: post #21
halosghost wrote: post #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 o…

The database argument is also specific to certain databases and table types. It should only matter for clustered tables. So if e.g. I use Postgres, this doesn't matter as it doesn't have clustered tables.

Distributed databases rely on spread across possible keys to balance workload. Mostly-ordered keys create hotspots.

Re: UUIDs are obsolete in the age of Docker

#25

Post by SPBS »

1. Nobody uses UUIDv1. Why use UUIDv1 as a straw man argument?

2. UUID strings are awful for storage -- don't use them. Yes there are databases that support UUIDs natively, why is whether or not a UUID fits into a machine word relevant? You use UUIDs for its other properties that 64-bit integers cannot offer. KSUIDs are touted as fixing all the aforementioned issues but they're even bigger than UUIDs.

3. Both KSUIDs and UUIDs are hard for humans to read compared to 64-bit integers.

4. You don't have to encode UUIDs as hexadecimal numbers plus dashes. You can choose any binary encoding you want, I am partial to Crockford Base32 because of how general-purpose it is (no vulgarities, case insensitive so it works on Windows filesystems).

5. I still consider time-sortable UUID alternatives (like ULID) to be UUIDs. This article should have explicitly mentioned UUIDv1 and UUIDv4 in the title and it wouldn't have been so flamebait.

Re: UUIDs are obsolete in the age of Docker

#26

Post by wizofaus »

gnu8 wrote: post #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 o…

Apparently Stripe stores its keys as strings, though not the usual UUID string representation.

Re: UUIDs are obsolete in the age of Docker

#27

Post by WirelessGigabit »

Obligatory read about UUIDs derived from MAC addresses: https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...

TLDR on the article: don't use UUIDv1.

Lastly, even with the best and most randomized generation, it still doesn't protect you from copy pasting: https://news.ycombinator.com/item?id=22354449

Re: UUIDs are obsolete in the age of Docker

#28

Post by deathanatos »

jupp0r wrote: post #17

In 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).

Hopefully you're setting the appropriate bits. A UUID is a bit-packed struct/union at heart, really; if you're just reading 128-bits of random data from /dev/random, that's not a UUID; passing it off as such would be needlessly confusing.

(It's fine to make a new format / it's not terrible approach for making a random ident, though you might want to peek into, e.g., ksuid from the OP for some interesting points about why you might not want to do that, plus some advice about getrandom() over /dev/random.)

Re: UUIDs are obsolete in the age of Docker

#29

Post by JdeBP »

deathanatos wrote: post #28
jupp0r wrote: post #17

In 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).

Hopefully you're setting the appropriate bits. A UUID is a bit-packed struct/union at heart, really; if you're just reading 128-bits of random data from /dev/random, that's not a UUID; passing it off as such would be needlessly confusing. (It's fine to make a new format / it's not terrible approach for making a random ident, though you might want to peek into, e.g., ksuid from the OP for some interesting points about…

The systemd developers made the same mistake initially. They later corrected it, and forced the non-random fields to the correct values.
Post reply on HN