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

61–70 of 376 posts

Re: Goodbye integers, hello UUIDv7

#61

Post by Dylan16807 »

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.

Well yes, but were they even implying that? Even if it was infinitely strict, clocks being perfect, two server processes can touch the same data at the same time.

In other words: Sorting by millisecond-or-so is just as good as sorting by picosecond in most situations. The reason you have to deal with conflicts gracefully isn't particularly because timestamps can be imperfect.

Re: Goodbye integers, hello UUIDv7

#62

Post by masklinn »

jiggawatts wrote: post #38

It seems insane to me to “validate” GUIDs/UUIDs. Half the point of these things is that they’re treated as opaque identifiers.

I’d assume the validation is parsing the uuid with a uuid library (to decode it), and the library eagerly validates the version field, either to check for garbage or because it wants to yield a different subtype for each version.

Re: Goodbye integers, hello UUIDv7

#63

Post by kijin »

jiggawatts wrote: post #38

It seems insane to me to “validate” GUIDs/UUIDs. Half the point of these things is that they’re treated as opaque identifiers.

If UUIDv4 was all that ever existed, there would be no need to validate anything apart of the fact that it's supposed to contain 32 hexadecimal characters.

All other versions, including the new v7, attach meaning to certain bits of the identifier. That cat has been out of the bag for a long time, so now everyone needs to maintain code to ensure that some rogue node doesn't spew back-dated identifiers belonging to the wrong department.

Re: Goodbye integers, hello UUIDv7

#64

Post by kiitos »

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?

UUIDs are 128 bits, or 16 bytes. They have infinitely many possible string representations. Those strings are not the value, they're a transformation of the value.

Re: Goodbye integers, hello UUIDv7

#65

Post by sroussey »

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

It can be bad for performance due to how b-trees work in databases, and more pronounced when you have a clustered index.

Re: Goodbye integers, hello UUIDv7

#66

Post by kiitos »

Lazare wrote: post #41

UUIDv7 is a nice idea, and should probably be what people use by default instead of UUIDv4 for internal facing uses. For the curious: * UUIDv4 are 128 bits long, 122 bits of which are random, with 6 bits used for the version. Traditionally displayed as 32 hex characters with 4 dashes, so 36 alphanumeric characters, and compatible with anything that expects a UUID. * UUIDv7 are 128 bits long, 48 bits encode a unix tim…

Second precision is too coarse for many (most?) use cases.

Re: Goodbye integers, hello UUIDv7

#67

Post by riffraff »

jonhohle wrote: post #37
amanzi wrote: post #20

Can you take the first portion of the UUIDv7 string, and decode it to figure out the exact date and time that record was created? I'm wondering if there might be security/privacy concerns in some situations if the UUID codes are visible in your app?

I just commented the same thing. I can't imagine most applications would want to leak time information in their identifiers but these undoubtedly will be used most placed out of convenience. In a year or so we'll read about an attack and everyone will migrate back to v4 or have to maintain a cryptographic identifier in addition to their temporal identifier.

Most application may not want it, but will it hurt them?

I mean this is a similar concern to sequential IDs: many apps do not want to leak them, and in some cases it might cause issues, but in general it doesn't matter.

Re: Goodbye integers, hello UUIDv7

#68

Post by kijin »

Lazare wrote: post #41

UUIDv7 is a nice idea, and should probably be what people use by default instead of UUIDv4 for internal facing uses. For the curious: * UUIDv4 are 128 bits long, 122 bits of which are random, with 6 bits used for the version. Traditionally displayed as 32 hex characters with 4 dashes, so 36 alphanumeric characters, and compatible with anything that expects a UUID. * UUIDv7 are 128 bits long, 48 bits encode a unix tim…

100 years sounds short-sighted for something that's supposed to be "universally" unique. We're already having problems with the 32-bit Unix timestamp not being large enough. If you're willing to use 160-bit (or longer) identifiers, you might as well give a few more bits to the timestamp. Round it up to an even number of base-62 characters, too. That part of KSUID has always struck me as a weird decision.

I wish UUIDv7 pulled the version/variant bits up front, though, just to make sure that the identifiers don't all start with null bytes.

Re: Goodbye integers, hello UUIDv7

#69

Post by philsnow »

masklinn wrote: post #62
jiggawatts wrote: post #38

It seems insane to me to “validate” GUIDs/UUIDs. Half the point of these things is that they’re treated as opaque identifiers.

I’d assume the validation is parsing the uuid with a uuid library (to decode it), and the library eagerly validates the version field, either to check for garbage or because it wants to yield a different subtype for each version.

but why decode it at all, if it's meant to be opaque?

Re: Goodbye integers, hello UUIDv7

#70

Post by tgv »

andrewmatte wrote: post #51
jonhohle wrote: post #35

This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…

jonhohle, thanks. Do you know of examples of when milliseconds are part of the session tokens or accounts being created has been exploited?

The German tank production capacity was estimated by serial numbers of captured tanks. There are ways to read all kinds of information by observing energy usage. High resolution time and sequence data undoubtedly reveal more than you’d like.
Post reply on HN