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

111–120 of 376 posts

Re: Goodbye integers, hello UUIDv7

#111

Post by hinkley »

dheera wrote: post #16
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's bad for performance if you frequently access large consecutive sets of records.

UUIDs are good for data where I want either lots of different users being able to insert without collision, or lots of users who I want to keep their peepers off of other user's metadata (eg, how many X they add to the system per day).

In both cases I'm melding highly disjointed data into a single schema. There are no large consecutive sets of records.

If you're using UUIDs, there's probably a reason. And that reason invalidates the justifications for not using them.

Re: Goodbye integers, hello UUIDv7

#112

Post by otherme123 »

tzahifadida wrote: post #94

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…

I understood it as c) only UUID7, no secondary external UUID.

The external Id is used instead of Bigint because you don't want your external users to query 1, then 2, then 3 (IDOR)... But the random part of the Uuid7 makes this impossible.

Uuid7 isn't a substitute for Created/Updated, but a substitute for the dual field Uuid4/Bigint.

Re: Goodbye integers, hello UUIDv7

#113

Post by fodkodrasz »

oconnore wrote: post #55
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…

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.

Re: Goodbye integers, hello UUIDv7

#114

Post by erik_seaberg »

Foobar8568 wrote: post #95
erik_seaberg wrote: post #59

Earlier quoted context omitted.

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.

Usually Hive or Dremel, with rows ingested from frontend instance logs. I get that it would actually work on a smaller system with a single server assigning times (or a quorum, if leader election ensures a monotonic clock).

Re: Goodbye integers, hello UUIDv7

#115

Post by dajonker »

Similar to the old situation in the article, we are using sequential 64 bit primary keys, but we use an additional random 64 bit key for external usage (instead of 128 bit).

The external key is base64 encoded for use in URLs which results in an 11 byte string.

This hides any information about the size of the data, the creation date of customer accounts (which would be sort of visible with UUIDv7) and prevents anyone from attempting to enumerate data by changing the integer in URLs.

I thought about using UUIDs as external keys but the only compelling use case seems to be the ability to generate keys from many decoupled sources that have to be merged later.

64 bit should be enough for most things https://youtu.be/gocwRvLhDf8?si=QBheJCG21bAAV0Z7

Re: Goodbye integers, hello UUIDv7

#116

Post by JCharante »

I wonder who this article is written for. Who would be reading about UUIDs but not know about cache hit rates?

> As a result, retrieving the most recent data from a large dataset will require traversing a large number of database index pages, leading to a poor cache hit ratio (how many requests a cache is able to fill successfully, compared to how many requests it receives).

Re: Goodbye integers, hello UUIDv7

#117

Post by bajsejohannes »

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.

You would still use a secret key, so it's impossible for the end user to decrypt it.

Re: Goodbye integers, hello UUIDv7

#120

Post by oittaa »

LAC-Tech wrote: post #47

Why use UUIDv7 over ULIDs? As Lazare points out in this thread they're basically the same thing, except with ULIDs you get those 6 extra bits of randomness back that UUIDs have to use for metadata.

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

ULID isn't an "official" standard like UUID. Having a real standard usually promotes interoperability and makes it easier to use. Additionally as others have pointed out you can already use UUIDv7 with some databases since it's just 16 opaque bytes and the database doesn't care what's actually in the UUID field.

Post reply on HN