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

Understanding UUIDs, ULIDs and string representations

sudhir.io

Post reply on HN
Print view View original

11–20 of 104 posts

Re: Understanding UUIDs, ULIDs and string representations

#11

Post by lewisl9029 »

verdverm wrote: post #3

Why not CUID?

First time hearing about CUID too, but have used ULID before. ULID is basically just 48 bits of timestamp + 80 bits of randomness, while CUID adds a counter for monotonicity, and a client fingerprint for collision resistance, presumably at the cost of less bits of randomness?

Would love to hear experts chime in on the tradeoffs here:

In terms of collision resistance, how much does adding a client fingerprint component really help? 80 bits of randomness in ULID already sounds pretty collision resistant to me, since that's a 50% chance of collision after generating 2^40 IDs. It kind of feels like the risk of collision on the fingerprinting mechanism itself (here it's described as 2 chars from PID and 2 chars from hostname for node, which honestly sounds a little bit shakey to me) combined with the reduced bits of randomness could undermine any potential gains in collision resistance through client fingerprinting.

Do folks know of examples where collision resistance through 80 bits or more randomness has failed in practice and generated collisions? Would love to see more reading material on this kind of stuff.

Re: Understanding UUIDs, ULIDs and string representations

#12

Post by skunkworker »

I'm liking ULIDs more and more recently, as a UUIDv4 is random, insert performance is going to be subpar compared to bigserial. But going to a ULID which includes the time allows you slightly quicker insert performance. Also allowing for some tiered storage architectures, where if you know the ULID, you know where to look (approximately).

Re: Understanding UUIDs, ULIDs and string representations

#13

Post by eins1234 »

nostoc wrote: post #5

First time hearing about ULIDs. The locality is interesting, but they leak information about when they were generated down to the millisecond, which could lead to problems if combined with other issues. I'd be wary of using them client-side.

Can someone expand on the practical consequences with leaking when things were created to the millisecond?

Re: Understanding UUIDs, ULIDs and string representations

#14

Post by JoelEinbinder »

eins1234 wrote: post #13
nostoc wrote: post #5

First time hearing about ULIDs. The locality is interesting, but they leak information about when they were generated down to the millisecond, which could lead to problems if combined with other issues. I'd be wary of using them client-side.

Can someone expand on the practical consequences with leaking when things were created to the millisecond?

Consider a timing attack: https://en.wikipedia.org/wiki/Timing_attack

Let's say a UUID comes back with an error message. This could be used to figure out how long it took to generate the error. That could tell you if a particular resource is cached, even if you don't have access to that resource.

Timing attacks are usually pretty creative. It's hard to predict how extra timing information could be misused.

Re: Understanding UUIDs, ULIDs and string representations

#17

Post by hn_go_brrrrr »

skunkworker wrote: post #12

I'm liking ULIDs more and more recently, as a UUIDv4 is random, insert performance is going to be subpar compared to bigserial. But going to a ULID which includes the time allows you slightly quicker insert performance. Also allowing for some tiered storage architectures, where if you know the ULID, you know where to look (approximately).

Depends on your storage system. For the one I work with most, a common prefix on your primary keys will hurt performance because it causes hotspotting. A UUID primary key would be the best case because it optimally shards writes. A ULID would be the worst case -- I would need to store it with the bits reversed.

Re: Understanding UUIDs, ULIDs and string representations

#20

Post by gorgoiler »

All this stuff about collisions and avoiding them, even though they will never happen, feels like a PHB compliance issue.

“Great work Geoff! One question: what’s the probability of two transactions having the same ID?”

“It is very low”

“Hmmm. But it’s not zero?”

“It’s so low that it practically is zero.”

“But it’s not technically zero? This company wasn’t built on taking chances, son! Come back when your product complies with our corporate zero-risk policy.”

Post reply on HN