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

71–80 of 376 posts

Re: Goodbye integers, hello UUIDv7

#71

Post by Traubenfuchs »

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 increased the primary key by TWO to THREE for each new customer to make it appear to the outside world we had twice to three times the rate of customer growth.

Re: Goodbye integers, hello UUIDv7

#72

Post by threeseed »

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.

Because in SPAs if a user creates new entities it can be easier to generate the UUIDs client side.

So then just a simple validation server side to ensure the data isn't malicious.

Re: Goodbye integers, hello UUIDv7

#73

Post by sj26 »

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 Depends(tm).

If you're using a system which is built for distribution, random is great.

When you're leaning on a Postgres database which has powered your startup through scaling but expects right-leaning btree indexes, it's a bad time.

Rearchitecting to use a new data store is ideal, but often impractical as an immediate step. UUIDv7 is a great increment walking that road via sharding etc.

Re: Goodbye integers, hello UUIDv7

#75

Post by jpgvm »

erik_seaberg wrote: post #48
QuadrupleA wrote: post #44

Earlier quoted context omitted.

But the timestamp is less than half the bits. The rest are random. So timestamp conflicts don't matter.

By “conflict” I don’t mean a UUID collision, I agree with the logic that 2^128 is so much entropy that memory corruption is the more likely culprit. I mean that you can’t rely for correctness on time(X) < time(Y) when X happened before Y. It’s damn hard to keep two commodity server clocks within ±1 ms of each other even within a single LAN, and across production you’re more likely to see ±10 ms, or worse if your sysa…

It's not designed for this use case. It's for cases where events in the same epoch may as well of happened concurrently.

ULID on the other hand does address this case by providing monotonicity within an epoch for a given producer. So would still need to treat each producer as a separate partition of the key space but you could order X > Y as long as both were produced by same producer (which effectively acts like a sequencer in this case).

EDIT: nvm, the UUIDv7 spec -allows- for arbitrary allocation of the remaining 62 bits which can be used as a counter: https://www.ietf.org/archive/id/draft-peabody-dispatch-new-u... All points for ULID can also apply to UUIDv7 depending on generation algorithm.

Re: Goodbye integers, hello UUIDv7

#76

Post by 8organicbits »

philsnow wrote: post #69
masklinn wrote: post #62

Earlier quoted context omitted.

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?

I think there are a couple minor problems:

- if the ID is intended to be opaque then the vendor shouldn't document it as a UUID, as this changing to a different format would be a breaking change

- if the customer isn't going to process the subcomponents of the UUID then they should process it as an opaque string

- if the UUID library encounters a version number in a UUID it doesn't understand, it shouldn't reject the UUID but present it as an unstructured string.

After this blog post it seems likely that even Kite more customer will parse the IDs to extract time, since this has been documented.

Re: Goodbye integers, hello UUIDv7

#77

Post by 8organicbits »

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

Re: Goodbye integers, hello UUIDv7

#78

Post by BWStearns »

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?

I could imagine using the timestamp segment of publicly observable ids to estimate activity patterns in an organization. Probably not super crucial and there are probably easier ways in most cases but it could be a big deal at the right moment and for the right target. This could be like a more refined version of PIZZAINT (where you can detect impending policy/operational movements by the quantity of food deliveries to a government organization).

Re: Goodbye integers, hello UUIDv7

#79

Post by erik_seaberg »

LAC-Tech wrote: post #58
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.

I feel like it's well beyond the scope of UUIDs to get into "are your clocks really monotonic?". They give you 48 bits for a timestamp, what that timestamp signifies (transactional time, valid time...) and how that's generated is up to you. Out of curiosity, are you into hybrid logical clocks?

I only raise this when I see promises that IDs are ordered and can be sorted, not merely grouped by approximate time for storage locality.

Yeah, though I’m more likely to go with a region ID and monotonic version number to compare-and-set and verify gapless data, where versions from different regions aren’t comparable. Actually I think earlier UUID RFCs talk about a “clock sequence” to distinguish timestamps from separate monotonic sources, but this paper doesn’t bring that up (or mention multiple clocks at all).

Re: Goodbye integers, hello UUIDv7

#80

Post by 8organicbits »

kijin wrote: post #68
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 UUIDv…

The timestamp is first.

https://www.ietf.org/archive/id/draft-peabody-dispatch-new-u...

Post reply on HN