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

Goodbye integers, hello UUIDv7

buildkite.com

Post reply on HN
Print view View original

121–130 of 376 posts

Re: Goodbye integers, hello UUIDv7

#121

Post by rossant »

Traubenfuchs wrote: post #71

Am I the only one instinctively upset by the communication/bandwith/storage overhead of the dashes as well as the version and variant bits of UUIDs? It might be insignificant, but to me it makes UUID feel tainted, dirty. 11.1% of a UUID are dashes. 15.3% of a UUID are wasted bits if you count version and variant bits. Anecdote: I worked for a company that used numeric primary ids internally and externally and increas…

The dashes do not take up any space, they are not encoded. I think it's fairly common to reserve some space to versions and ECC in uuids, packets etc. That's a price to pay to avoid many bugs and compatibility issues.

Re: Goodbye integers, hello UUIDv7

#122

Post by pfix »

BiteCode_dev wrote: post #100
imiric wrote: post #97

Earlier quoted context omitted.

I'm a fan of Cuid2[1] for this reason. They are compact, don't leak information, and make a good case why k-sortable IDs are unnecessary, or even harmful for performance. I'm using sequential integers and created_at/updated_at timestamps for internal use, and Cuid2 IDs externally. [1]: https://github.com/paralleldrive/cuid2

What benefice over uuid4 ?

There's a comparison in the README of the project:

https://github.com/paralleldrive/cuid2#the-contenders

Some of the arguments mentioned are explained elsewhere in the README, others are assumed.

One argument standing out for me is the lack of collision-resistance for UUIDv4 which is surprising for me and I didn't spot any sources for that argument.

Another argument is the entropy source where they go about that Math.random is not reliable as a single entropy source but glimpsing at the source code, they sprinkle the CUID with Math.random data.

I am no expert in ID security, so I am not qualified to speak about the validity of their arguments, only that there's insufficient information to validate without prior knowledge about the problem domain.

Re: Goodbye integers, hello UUIDv7

#123

Post by bajsejohannes »

notpushkin wrote: post #91
dajonker wrote: post #85

Earlier quoted context omitted.

That's an interesting idea, how would you deal with the bits in the UUID that are used for the version? Setting them to random bits may cause issues for clients that try to use the identifier in their own database or application, as mentioned in the article.

Is there a way to encrypt 122 bits -> 122 bits? If so – do that and set version to 4. Alternatively, just say it's a random string ID and not an UUID.

I'm actually working on encrypting database keys like this, and I opted for a string ID with "url safe" base64. It avoids the ambiguity of looking like a UUID when it's not, and I prefer "o3Ru98R3Qw-_x2MdiEEdSQ" in a URL over "a3746ef7-c477-430f-bfc7-631d88411d49". (Not that either one is very beautiful)

Re: Goodbye integers, hello UUIDv7

#124

Post by oittaa »

erik_seaberg wrote: post #43

> first component (prefix) of the identifier is a sortable timestamp > values generated are practically sequential These statements aren’t strict enough to be relied on. Maybe you have engineered the hell out of your distributed clock scheme, and your IDs actually are completely monotonic, which is great. But you probably haven’t done that, which means conflicts will surely happen and you must handle them gracefully.

https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc...

Re: Goodbye integers, hello UUIDv7

#125

Post by adrian_b »

fodkodrasz wrote: post #113
oconnore wrote: post #55

Earlier quoted context omitted.

Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits

No IV, ECB mode... why bother with encryption at all? Just expose the internal id.

Encrypting an internal id with ECB into an external id continues to allow the comparison for equality of 2 ids, to determine whether they are the same or not, but except for this it removes all the information contained in the structure of an UUID.

Re: Goodbye integers, hello UUIDv7

#126

Post by conradludgate »

rockwotj wrote: post #3

I find it interesting that it’s quoted random IDs are bad for performance, because it’s actually better for distributed storage systems because you don’t hotspot on a single node. For example see: https://stackoverflow.com/a/53901549 and https://medium.com/google-cloud/cloud-spanner-choosing-the-r...

As far as I understand, you want to have a random shard position, but once you have found a shard you want that index operation to be cache friendly. When choosing a shard, you can always use the last N bits or use some consistent hashing strategy[1]

[1]: https://en.m.wikipedia.org/wiki/Consistent_hashing

Re: Goodbye integers, hello UUIDv7

#127

Post by oittaa »

8organicbits wrote: post #77
coolgoose wrote: post #74

I am confused how this is new. UUIDv1 is time based, you just need to be careful about entropy, and in MySQL 8 you can for a longish time use it as an ordered field.

The use of a MAC address and fine grained timestamp are challenges of UUIDv1. https://blog.devgenius.io/analyzing-new-unique-identifier-fo...

And the crazy epoch instead the more known Unix epoch. Why would anyone want to create UUIDs around year 1500?

Re: Goodbye integers, hello UUIDv7

#128

Post by computerfriend »

fodkodrasz wrote: post #113
oconnore wrote: post #55

Earlier quoted context omitted.

Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits

No IV, ECB mode... why bother with encryption at all? Just expose the internal id.

ECB is perfectly secure when you use it on a single block.

Re: Goodbye integers, hello UUIDv7

#129

Post by Traubenfuchs »

rossant wrote: post #121
Traubenfuchs wrote: post #71

Am I the only one instinctively upset by the communication/bandwith/storage overhead of the dashes as well as the version and variant bits of UUIDs? It might be insignificant, but to me it makes UUID feel tainted, dirty. 11.1% of a UUID are dashes. 15.3% of a UUID are wasted bits if you count version and variant bits. Anecdote: I worked for a company that used numeric primary ids internally and externally and increas…

The dashes do not take up any space, they are not encoded. I think it's fairly common to reserve some space to versions and ECC in uuids, packets etc. That's a price to pay to avoid many bugs and compatibility issues.

UUIDs are often pushed around in JSON and as string types, including the none random parts.

Re: Goodbye integers, hello UUIDv7

#130

Post by LAC-Tech »

sapling-ginger wrote: post #118
declan_roberts wrote: post #26

It’s 2023. Why aren’t we using more characters from the utf-8 keyspace to make things like UUIDs use less characters?

Base8192: https://alicecengal.github.io/uuid-hangul/

That's awesome. "Aesthetic, Cosmopolitan" LOL
Post reply on HN