5 ms·
> UUID versions 1, 2, 3, 4, 5 are already outdated. Interesting comment, since v4 is the only version that provides the maximal random bits and is recommended
by matja 7mo ago
> UUID versions 1, 2, 3, 4, 5 are already outdated.
Interesting comment, since v4 is the only version that provides the maximal random bits and is recommended for use as a primary key for non-correlated rows in several distributed databases to counter hot-spotting and privacy issues.
Edit: Context links for reference, these recommend UUIDv4:
https://www.cockroachlabs.com/docs/stable/uuid https://www.cockroachlabs.com/docs/stable/uuid
https://docs.cloud.google.com/spanner/docs/schema-design#uuid_primary_key https://docs.cloud.google.com/spanner/docs/schema-design#uui...
- zadikian 7mo agoYeah v4 is the goto, and you only use something else if you have a very specific reason like needing rough ordering
- jodleif 7mo agoDeterministic uuids is a very standard usecase
- 8organicbits 7mo agoYou're talking about the hash-based UUIDv3/v5? I haven't found examples of those being used, but I'm curious. Using MD5 or 122 bits of a SHA1 hash seems questionable now that both algorithms have known collisions. Using 122 bits of a SHA2/3 seems pretty limited too. Maybe if you've got trusted inputs?
- eureka7 7mo agoI remember using them in a massive SQL query that needed to generate a GIS data set from multiple tables with an ungodly amount of JOINs and sub-queries to achieve ID stability. Don't ask :p For those ~~curious~~ worried, no, this was not a security sensitive context.
- zadikian 7mo agoCommon one is if you want two structs deemed "equivalent" based on a few fields to get the same ID, and you're only concerned about accidental collision. There are valid use cases for that, but I've also seen it misused often. v7 rough ordering also helps as a PK in certain sharded DBs, while others want random, or nonsharded ones usually just serial int.
- 8organicbits 7mo agoHave you seen UUIDv3/v5 used there though? I've seen lots of md5 historically and sha variants recently, but not the UUID approach.
- zadikian 7mo agoYeah, I've seen both 3 and 5 used, not just hashes in some custom format. That way it works with Postgres uuid type etc.
- buffalobuffalo 7mo agoI use these a lot. My favorite use case is templates, especially ones that were not initially planned in the architecture. Let's say i have some entity like an "organization" that has data that spans several different tables. I want to use that organization as a "parent" in such a way where i can clone them to create new "child" organizations structured the same way they are. I also want to periodically be able to pull changes from the parent organization down into the child organization. If the primary keys for all tables involved are UUIDs, I can accomplish this very easily by mapping all IDs in the relevant tables `id => uuid5(id, childOrgId)`. This can be done to all join tables, foreign keys, etc. The end result is a perfect "child" clone of the organization with all data relations still in place. This data can be refreshed from the parent organization any time simply by repeating the process.
- bootsmann 7mo agoReally? Doesn’t v4 locally make the inserts into the B-Tree pretty messy? I was taught to use v7 because it allows writes to be a lot faster due to memory efficient paging by the kernel (something you lose with v4 because the page of a subsequent write is entirely random).
- matja 7mo agoIn distributed databases I've worked with, there's usually something like a B-tree per key range, but there can be thousands of key ranges distributed over all the nodes in the cluster in parallel, each handling modifications in a LSM. The goal there is to distribute the storage and processing over all nodes equally, and that's why predictable/clustered IDs fail to do so well. That's different to the Postgres/MySQL scenario where you have one large B-tree per index.
- out_of_protocol 7mo agov7 exposes creation date, and maybe you don't want that. So, depends on use-case
- sintax 7mo agohttps://www.thenile.dev/blog/uuidv7#why-uuidv7 https://www.thenile.dev/blog/uuidv7#why-uuidv7 has some details: " UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4), have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for this (B-tree and its variants) can be dramatic. ". Also mentioned on HN https://news.ycombinator.com/item?id=45323008 https://news.ycombinator.com/item?id=45323008
- arccy 7mo ago[flagged]
- gzread 7mo agoIf you want 128 bits of randomness why not use 128 bits of randomness? A random UUID presupposes the random number has to fit in UUID format.
- da_chicken 7mo ago122 bits of randomness. It's the same reason we use UTF-8. It's well supported. UUIDs are well supported by most languages and storage systems. You don't have to worry about endianness or serialization. It's not a thing you have to think about. It's already been solved and optimized.
- gzread 7mo agobyte[16] is well supported by most languages and storage systems.
- da_chicken 7mo agoSure. Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG? Are you doing that every time you're generating one of these IDs in any system that might need to communicate with your API? Or maybe they just generated one random number, and now they're adding 1 every time. Now transfer it over a wire. Are you sure the way you're serializing it is how the remote system will deserialize it? Maybe you should use a string representation, since character transmission is a solved problem with UTF-8. OK, so who decides what that canonical representation is? How do we make it recognizable as an ID without looking like something that people should do arithmetic with? It's not like random IDs were a new idea in 2002.
- gzread 7mo agoHow's your UUIDv4 generated? > Are you sure the way you're serializing it is how the remote system will deserialize it? It's 16 bytes. There's no serialization.
- 7mo ago
- pclmulqdq 7mo agoI believe current official guidance if you want a lot of random data is to use v8, the "user-defined" UUID. The use of v4 is strictly less flexible here.
- 8organicbits 7mo agoNo, UUIDv8 offers 122 bits for vendor specific or experimental use cases. If you fill those bits randomly, you get the same amount of randomness as a v4. The spec is explicit that it does not replace v4 for random data use case. > To be clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all 122 extra bits are filled with random data. https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2 https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2
- pclmulqdq 7mo agoYes, vendor-specific data can be 100% random.
- 8organicbits 7mo agoIt can be, but you should prefer UUIDv4 if you do that. One problem is that UUIDv8 does not promise uniqueness. > UUIDv8's uniqueness will be implementation specific and MUST NOT be assumed. Here's a spec compliant UUIDv8 implementation I made that doesn't produce unique IDs: https://github.com/robalexdev/uuidv8-xkcd-221 https://github.com/robalexdev/uuidv8-xkcd-221 So, given a spec-compliant UUIDv4 you can assume it is unique, but you'd need out-of-band information to make the same assumption about a UUIDv8. I wrote much more in a blog post: https://alexsci.com/blog/uuid-oops/ https://alexsci.com/blog/uuid-oops/
- da_chicken 7mo agoYeah, I thought it was a strange comment, too. v7 is great when you explicitly need monotonicity, but encoded timestamps can expose information about your system. v4 is still very valid.
- lijok 7mo agoHave you considered using two uuids for more randomness
- jandrewrogers 7mo agoI think "outdated" was a poor choice of words. It is a failure to meet application requirements, which has more to do with design than age. Every standardized UUID is expressly prohibited in some application contexts due to material deficiencies, including v4. That includes newer standards like v7 and v8. In practice, most orgs with sufficiently large and complex data models use the term "UUID" to mean a pure 128-bit value that makes no reference to the UUID standard. It is not difficult to find yourself with a set of application requirements that cannot be satisfied with a standardized UUID. The sophistication of our use case scenarios for UUIDs exceeds their original design assumptions. They don't readily support every operation you might want to do on a UUID.