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

91–100 of 376 posts

Re: Goodbye integers, hello UUIDv7

#91

Post by notpushkin »

dajonker wrote: post #85
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

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.

Re: Goodbye integers, hello UUIDv7

#92

Post by noduerme »

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…

Thinking that harder-to-guess IDs will mitigate attacks is an example of security by obscurity. It's better to think of any IDs in your database as being public knowledge, because they will leak anyway. Assuming that no one can guess another ID leads to shoddy practices. I generally keep IDs sequential and build security around the basic assumption that IDs are not keys, passwords, sessions, or secrets - they're just the public matching identifier for those things.

To that end, I think it's neat to be able to improve indexing on UUIDs, but it's not a security solution.

Re: Goodbye integers, hello UUIDv7

#93

Post by Raed667 »

the_arun wrote: post #90
lysium wrote: post #87

Earlier quoted context omitted.

Neat idea. I’m afraid you won’t be able to ever rotate that key, would you? Since it’s result is externally used as an identifier, you would have to rotate the external identifiers, too.

What is the use case for rotating uuids? Aren’t they immutable?

i think they meant rotating the encryption key not the internal uuids

Re: Goodbye integers, hello UUIDv7

#94

Post by tzahifadida »

To me it sounds like a corner case. Example:

a) UUID4, CreatedTime/UpdatedTime.

b) Bigint, CreatedTime/UpdatedTime.

c) UUID7 internal (which also includes time badly), UUID4 external/whatever short ID.

How exactly this helps if you need external ids (which you usually do today)? It doesn't even make it a short ID.

Even if there is a corner case, are we just saving a few bytes while adding more complication?

Clustered Index is a myth in PostgreSQL, not practical since you have to run a special program to reorder. So, a regular index might suffer but not really. Why? Because I am not ordering by the ID most of the time, I am ordering by "Created Date/Updated Date" or Name or whatever. Who cares about ordering IDs?

WAIT!!! But what about Next Tokens? ok, these are painful, but easily solved: Next can be (>=Created Date,>ID). Same result. Pagination, stays the same since it is sorted by Created Date.

Re: Goodbye integers, hello UUIDv7

#95

Post by Foobar8568 »

erik_seaberg wrote: post #59
__MatrixMan__ wrote: post #46

Earlier quoted context omitted.

When I'm using integer surrogate keys to manipulate subsets of a table, they usually correspond to some kind of out-of-band predicate. Like this is the data that appeared today , or this is everything after the bug happened , etc. Maybe there are applications where the monotonicity matters, but in my experience reasoning by surrogate key is rather coarse grained and you manually scrutinize the boundaries, so unless y…

I’ve seen too many people write a query like where ts between txn_start and txn_end order by ts and not even realize that what they’re seeing is incomplete and misleading. Clock skew is very common, and we shouldn’t sweep that under the rug to promote time ordering, because people want to believe this works the way they think.

Clock skews in a single node database? Actual question.

Re: Goodbye integers, hello UUIDv7

#96

Post by travisjungroth »

kiitos wrote: post #66
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.

How so? It seems like the only real use case for these timestamps is to get data from around the same time together. A second is fine for that. It's not about concurrency or avoiding collisions. A second can't handle that, but neither can a millisecond.

Re: Goodbye integers, hello UUIDv7

#97

Post by imiric »

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…

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

Re: Goodbye integers, hello UUIDv7

#98

Post by devoutsalsa »

threeseed wrote: post #72
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.

Never trust the client.

Re: Goodbye integers, hello UUIDv7

#99

Post by littlestymaar »

BWStearns wrote: post #86
rhaps0dy wrote: post #82

Earlier quoted context omitted.

Is PIZZAINT real? I thought it was a joke. How do you even find out how much pizza is being delivered?

In ye olden days you had a minion sitting in a car watching the front gate with a notepad and enough cigarettes to last the night. Pizza itself might be a bit of a joke but looking for non-operational behavioral changes is absolutely real. The Cuban missile crisis was started in part because soviets played soccer and Cubans played baseball and the presence of soccer fields helped confirm soviet presence (in enough nu…

> soviets played soccer and Cubans played baseball

It's a Henri Kissinger's quote, but it's not accurate: Cubans do in fact play football. Also this quote wasn't from the 1962 Cuban missile crisis, but to another event in 1970. That being said, it is true that the US intelligence got warned by the construction of football fields (or maybe even more so by the lack of baseball grounds).

https://www.cracked.com/article_31335_that-time-soccer-field...

Re: Goodbye integers, hello UUIDv7

#100

Post by BiteCode_dev »

imiric wrote: post #97
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…

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 ?
Post reply on HN