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

New UUID Formats

ietf.org

Post reply on HN
Print view View original

41–50 of 172 posts

Re: New UUID Formats

#41

Post by RobertRoberts »

hn_throwaway_99 wrote: post #34
tpetry wrote: post #27

Earlier quoted context omitted.

That‘s in my experience also the best approach. I wrote an article a few days ago about the exact thing: An integer auto incrementing PK with an UUID you use externally: https://sqlfordevs.io/uuid-prevent-enumeration-attack

That is how I used to do (and currently still do) DB design, but honestly I think if DBs start supporting UUID v7s well that I would use that as the sole primary DB key as well as the external ID: 1. They are still sorted in increasing timestamp order (at millisecond granularity), so they should have good DB index characteristics. 2. At the same time, they contain 62 bits of randomness, would should pretty much elimi…

Yep, I want UUID v7, because right now I am using ULID and it's fantastic, but I'd like more official and wide support as well.

Re: New UUID Formats

#42

Post by staticassertion »

stormbrew wrote: post #30
staticassertion wrote: post #26

Earlier quoted context omitted.

I feel like `serial` has got to be pretty fast for writes and gives you some nice properties like sorted ordering based on insertion time, a smaller key, and a key that can be compressed far better than a uuid. I get the idea of a ULID/UUID7 encoding a timestamp so you get sorted order, but I wonder at what scale that beats just using serial.

At any scale where you have to have multiple writers generating IDs or need to merge results from multiple sources, basically. Synchronizing a serial increment across hosts and across time is a pain. Obviously you can composite a timestamp to an incrementing id, but then the serial part of it is kind of useless for ordering, so you may as well use a random number and avoid needing to synchronize at all. And then you'…

I'm wondering what that performance actually looks like though. The closest benchmark I have is a single postgres instance with a uuid pkey and a bigint column, transactionally incrementing the integer in the column.

I mean I guess mathing it out, updating an atomic integer is ~2-100ns, depending on contention. If you need to coordinate the writes you have anywhere from ~250μs-10ms.

We can basically throw away the increment at that point since the network is hundreds/thousands of times slower.

So at 10ms, that's 100 op/s. At 250μs more like 40kops/s.

That ignores the fact that your db can perform those writes concurrently and then batch the writes off to the other database, so long as it doesn't pretend that they're all committed at once. psql HOT updates would presumably be a thing here idk.

If I had to guess, I'd lean towards the "40kop/s" being closer than the "100op/s" but idk! I wish we had benchmarks but I can't find anything :\

Re: New UUID Formats

#43

Post by RobertRoberts »

rekwah wrote: post #13
kbumsik wrote: post #8

UUIDv7 looks interesting, but how is it different from ULID [1] in practice? I was considering using ULID for a upcoming new project because it is lexicographically sortable but it looks like UUIDv7 just can replace that. [1]: https://cran.r-project.org/web/packages/ulid/vignettes/intro...

As the author of a popular ULID implementation in python[1], the spec has no stewardship anymore. The specification repo[2] has plenty of open issues and no real guidance or communication beyond language implementation authors discussing corner cases and the gaps in the spec. The monotonic functionality is ambiguous (at best), doesn't consider distributed id generation, and is implemented differently per-language [3]…

Thank you, I've been using ULID for a while now, and it serves my purposes. But I have long term support concerns.

UUIDv7 really seems like the sweet spot between pure INT/BIGINT auto incrementing PKs and universally sortable universal ids.

Re: New UUID Formats

#44

Post by Someone »

amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

> Hint: do not use integer types in C code for portable data structures. ntohl, etc are a mess. Just use arrays of bytes.

I don’t see how that helps much. If a developer forgets to call ntohl on multi-byte integer fields, I don’t trust them to correctly convert said integers to arrays of bytes, either.

Re: New UUID Formats

#45

Post by firebird84 »

amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

It's actually worse than that. The first 3 groupings (textually) of the uuid might be little endian while the other 2 are big endian. Learning this cost me more time than I care to admit.

https://en.wikipedia.org/wiki/Universally_unique_identifier#...

Re: New UUID Formats

#46

Post by CharlesW »

cameronh90 wrote: post #35
GiorgioG wrote: post #22

I used to be a big proponent of using UUIDs for database PKs but I've found them inherently difficult to work with. It's much easier to remember/recognize an integer based PK when troubleshooting a data problem. This isn't to say you shouldn't use UUIDs at all, but I much prefer to use an "ExternalId" column of UUID type if you don't want to expose your integer based PKs externally.

UUIDs have a few distinct advantages: you'll never run out, you don't need a roundtrip to find out what they are after saving them, they often make a good partitioning key and it makes things easier if you ever need to combine multiple data sources together in migration and recovery type scenarios. I also quite like how they're unique across all data sources and tables, so if you just encounter a random contextless U…

> There are a few compact representations you can use in URLs which make it a bit less ugly…

Any thoughts on where to find best-practices guidance? I need to create an external ID scheme for several million items. hashids (hashids.org) seems interesting, but I have anxiety about choosing a solution with weaknesses that I can't identify given my current level of experience in regards to this.

Re: New UUID Formats

#47

Post by deepsun »

GiorgioG wrote: post #22

I used to be a big proponent of using UUIDs for database PKs but I've found them inherently difficult to work with. It's much easier to remember/recognize an integer based PK when troubleshooting a data problem. This isn't to say you shouldn't use UUIDs at all, but I much prefer to use an "ExternalId" column of UUID type if you don't want to expose your integer based PKs externally.

The best strategy is to have integer primary keys for internal purposes, and some form of uuid for external (think permalinks).

Re: New UUID Formats

#48

Post by jeremyjh »

RobertRoberts wrote: post #41
hn_throwaway_99 wrote: post #34

Earlier quoted context omitted.

That is how I used to do (and currently still do) DB design, but honestly I think if DBs start supporting UUID v7s well that I would use that as the sole primary DB key as well as the external ID: 1. They are still sorted in increasing timestamp order (at millisecond granularity), so they should have good DB index characteristics. 2. At the same time, they contain 62 bits of randomness, would should pretty much elimi…

Yep, I want UUID v7, because right now I am using ULID and it's fantastic, but I'd like more official and wide support as well.

I like the textual representation of ULIDs as well though; I wish they’d just adopted ULID as v7. At least it is binary compatible with existing UUID types.

Re: New UUID Formats

#49

Post by cpach »

firebird84 wrote: post #45
amluto wrote: post #19

Fortunately this is a bit less relevant today as Windows loses market share in database and server applications, but: UUIDs have historically massively screwed up endian handling. While this new draft discusses sorting UUIDs as strings of octets (bytes) and the text of RFC4122 is fairly explicit about most significant bytes coming first, the C UUID structure in RFC 4122 appendix A is entirely misguided: typedef struc…

It's actually worse than that. The first 3 groupings (textually) of the uuid might be little endian while the other 2 are big endian. Learning this cost me more time than I care to admit. https://en.wikipedia.org/wiki/Universally_unique_identifier#...

What the…?

This fact will haunt me in my dreams :-p

Post reply on HN