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

31–39 of 39 posts

Re: UUIDs are obsolete in the age of Docker

#31

Post by starfox64_ »

I've had a similar issue with MongoDB's ObjectIDs. They are generated using a combination of process id, UNIX timestamp and a counter that is randomly initialized during process creation. The issue when docker comes into the mix is that the root process id of every container is 1 so a decent chunk of entropy is removed from the ObjectID. Add to that the fact that the timestamp doesn't have millisecond resolution, the only thing saving you is praying the counter of any of your processes never overlaps during the same second.

It's unlikely to happen but still possible and it has brought down some of our parallel worker pool because once you have a collision, you are bound to keep generating the same id sequence until you restart your whole process to randomize the counter again.

Re: UUIDs are obsolete in the age of Docker

#32

Post by yamtaddle »

wizofaus wrote: post #26
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.

I'm like 90% sure Stripe started on MongoDB (may still be using Mongo?). That might have something to do with it.

Re: UUIDs are obsolete in the age of Docker

#33

Post by plorkyeran »

starfox64_ wrote: post #31

I've had a similar issue with MongoDB's ObjectIDs. They are generated using a combination of process id, UNIX timestamp and a counter that is randomly initialized during process creation. The issue when docker comes into the mix is that the root process id of every container is 1 so a decent chunk of entropy is removed from the ObjectID. Add to that the fact that the timestamp doesn't have millisecond resolution, the…

MongoDB eventually switched away from doing that and now just generates random numbers for the pid and machineid fields of ObjectIDs. The timestamp is still there because people rely on being able to sort on that (which is a bad idea for various reasons), but it's at least 24 bytes of randomness now.

Re: UUIDs are obsolete in the age of Docker

#34

Post by smaccona »

wswope wrote: post #18
ekimekim wrote: post #4

As 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.

Didn’t know this - true as of MySQL 8.X. I would say “shocking” if it wasn’t in keeping with a number of dubious decisions made over the years. We are using MySQL, but thankfully are generating UUIDs in our app layer.

Kludgy, non-cryptographically-safe UUID4 implementation in MySQL: https://stackoverflow.com/a/32965744

Re: UUIDs are obsolete in the age of Docker

#35

Post by jupp0r »

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…

If you treat them as opaque strings and don't use their binary representation, you'll be fine.

Re: UUIDs are obsolete in the age of Docker

#36

Post by Fire-Dragon-DoL »

SPBS wrote: post #25

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…

64 bit integers are easier just because we also end up using low numbers

9,223,372,036,854,775,807 is as nasty as a UUID to remember and type

Re: UUIDs are obsolete in the age of Docker

#37

Post by starfox64_ »

plorkyeran wrote: post #33
starfox64_ wrote: post #31

I've had a similar issue with MongoDB's ObjectIDs. They are generated using a combination of process id, UNIX timestamp and a counter that is randomly initialized during process creation. The issue when docker comes into the mix is that the root process id of every container is 1 so a decent chunk of entropy is removed from the ObjectID. Add to that the fact that the timestamp doesn't have millisecond resolution, the…

MongoDB eventually switched away from doing that and now just generates random numbers for the pid and machineid fields of ObjectIDs. The timestamp is still there because people rely on being able to sort on that (which is a bad idea for various reasons), but it's at least 24 bytes of randomness now.

When did this change? Last I checked the PHP driver still relied on the pid.

Re: UUIDs are obsolete in the age of Docker

#38

Post by tatersolid »

yamtaddle wrote: post #32
wizofaus wrote: post #26

Earlier quoted context omitted.

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

I'm like 90% sure Stripe started on MongoDB (may still be using Mongo?). That might have something to do with it.

A company which handles money as its primary business is using MongoDB? Hopefully the actual dollars are always handled in a “realSQL” DB with proper transaction isolation.

Re: UUIDs are obsolete in the age of Docker

#39

Post by yamtaddle »

tatersolid wrote: post #38
yamtaddle wrote: post #32

Earlier quoted context omitted.

I'm like 90% sure Stripe started on MongoDB (may still be using Mongo?). That might have something to do with it.

A company which handles money as its primary business is using MongoDB? Hopefully the actual dollars are always handled in a “realSQL” DB with proper transaction isolation.

I recalled that specifically because I remember having the same reaction when I found it out (I think? I have a distinct memory of learning this) back in 2012 or something.
Post reply on HN