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

141–150 of 172 posts

Re: New UUID Formats

#141

Post by kdps »

My main concern with random-based UUIDs always has been running out of entropy and cause the application to remain in a blocking state (e.g. as described here: https://blog.fastthread.io/2022/03/09/java-uuid-generation-p...). Not due to any negative experiences that I made myself, but due to a particular colleague of mine who sees it as a dealbreaker.

Is this an actual issue? Most people don't seem to care when talking about random UUIDs. The target platform of our applications is mostly Kubernetes on cloud environments, if that makes any difference.

Why I'm asking: UUID Version 7 looks quite interesting to me, and the document describes rand_a and rand_b just as "pseudo-random data"... which made me think that in the context of "uniqueness per millisecond", a source of entropy is conceptually not required. However, chapter 6.6 clearly advises the usage of CSPRNGs, so I guess the overall problem remains :(

Re: New UUID Formats

#142

Post by astrange »

kdps wrote: post #141

My main concern with random-based UUIDs always has been running out of entropy and cause the application to remain in a blocking state (e.g. as described here: https://blog.fastthread.io/2022/03/09/java-uuid-generation-p... ). Not due to any negative experiences that I made myself, but due to a particular colleague of mine who sees it as a dealbreaker. Is this an actual issue? Most people don't seem to care when talk…

“Running out of entropy” is not possible; that’s a property of ancient PRNGs written by confused people.

Even if your PRNG could run out of entropy, rdrand would give it all it needs.

Re: New UUID Formats

#144

Post by matwood »

vlovich123 wrote: post #128
acmecorps wrote: post #127

Earlier quoted context omitted.

You’re not alone. I’ve been migrating my tables to use uuid instead of integers and have been using uuid whenever I have new tables, unless I have very good reason not to. Experience was my teacher.

Don’t UUIDs as primary keys totally destroy the performance because UUIDs aren’t sortable and thus wreak havoc with the index for the primary key?

Destroy is a strong word (and UUIDs can certainly be sorted, but locality is an issue), but all of software is a series of tradeoffs. I've used both auto-increment and UUIDs, and wish I had used UUIDs in almost every case.

Distributed generation - no sending a record to a server to get a key then using it to generate other records. In a world with increasing use of services, this becomes more important every day.

System wide unique - helps with logging, debugging, and avoiding general errors.

Multi-master db replication - I know this depends on the RDBMS, but having a unique key on every record avoids clashes. Also super useful during data migrations (which will happen. I have another rant that data always outlives code, so plan accordingly).

Validation - UUIDs have a form that can be a first level validation on input.

For me, those advantages outweigh some extra space usage, possible performance impact, and ugly URLs.

And on performance, if it's determined that it is an issue because of using UUIDs there are ways to make them more index friendly.

Re: New UUID Formats

#145

Post by Aeolun »

marcus_holmes wrote: post #140
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.

I have exactly the reverse experience. I do comparisons using ``` ::text like ' %``` when debugging in a command line. Or just copy/paste the whole thing. Yes it's marginally more annoying than integers, but only marginally. I have several times wondered why I was getting no match on a query. And then discovered that I was using a user_id on an account_id field. UUID's have saved me from shooting myself in the foot s…

How do UUID’s help in that situation? You get no result at all instead of the wrong result?

Re: New UUID Formats

#146

Post by oittaa »

stevesimmons wrote: post #143
canadiantim wrote: post #50

How would one go about trying to use UUID 7 in a Postgres database / python codebase now?

My Python implementation is here: https://github.com/stevesimmons/uuid7 https://pypi.org/project/uuid7/

Nice to see another implementation which takes a bit different approach. Just for your information, there's now Draft 03 which changes the format a little bit. I kinda liked the arbitrary precision of Draft 02, but the newer one just requires millisecond precision and then basically leaves it up to the implementation how to handle the generation of multiple UUIDs within the same millisecond.

https://github.com/uuid6/prototypes/issues/21

Re: New UUID Formats

#147

Post by tpetry »

jeremyjh wrote: post #91
RobertRoberts wrote: post #84

Earlier quoted context omitted.

Is there not an equivalent text representation for UUIDv7?

Sure you could encode it in Crockford's base-32 but if it isn't part of the standard then tools won't implement it natively, so you couldn't copy a key from a url and look it up in postgres without running it through a conversion function, for example.

You can write a custom data type in pure SQL for PostgreSQL which is just transforming a visible string to the more efficient uuid type. That‘s basically how the uuid type can be implemented: For storage it‘s binary(16) but all operations transform the value to the visible string you see all the time. It‘s a pretty powerfull feature.

Re: New UUID Formats

#148

Post by ciupicri »

astrange wrote: post #142
kdps wrote: post #141

My main concern with random-based UUIDs always has been running out of entropy and cause the application to remain in a blocking state (e.g. as described here: https://blog.fastthread.io/2022/03/09/java-uuid-generation-p... ). Not due to any negative experiences that I made myself, but due to a particular colleague of mine who sees it as a dealbreaker. Is this an actual issue? Most people don't seem to care when talk…

“Running out of entropy” is not possible; that’s a property of ancient PRNGs written by confused people. Even if your PRNG could run out of entropy, rdrand would give it all it needs.

From the documentation for java.security.SecureRandom from Java 17 [1]:

> Note: Depending on the implementation, the generateSeed, reseed and nextBytes methods may block as entropy is being gathered, for example, if the entropy source is /dev/random on various Unix-like operating systems.

[1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

Re: New UUID Formats

#149

Post by blueflow »

iforgotpassword wrote: post #135
smallnamespace wrote: post #113

Earlier quoted context omitted.

Isn’t endianness marked by the variant field? 1 is IETF, 2 is Microsoft, and this can be inferred from the sticker.

At my last workplace we twice got new workstations where they all had the same bogus UUID. Once it was Dell, the other I don't remember. The fix was to either manually set a new one in the BIOS setup, or install a BIOS Update. So I have my doubts that the variant field can be trusted here.

After failed attempts with the UUID due to above problems, we now do machine identification for PXE via MAC address for virtual machines (you see/set it in the hypervisor) and the DMI product_serial for physical machines (written on chassis).

Re: New UUID Formats

#150

Post by sumtechguy »

vlovich123 wrote: post #128
acmecorps wrote: post #127

Earlier quoted context omitted.

You’re not alone. I’ve been migrating my tables to use uuid instead of integers and have been using uuid whenever I have new tables, unless I have very good reason not to. Experience was my teacher.

Don’t UUIDs as primary keys totally destroy the performance because UUIDs aren’t sortable and thus wreak havoc with the index for the primary key?

There is a perf hit. You can not help it when you are slugging that many bytes around. An int/int64 fits into a register easy and the instruction for comparison is cheap. However, when you add in replication and other items UUID becomes more desirable due to the property having extra information embedded into it to make them unique. You can get some of the same benefits with more complexity if you are using auto increment. Such as using a stride that is similar to the number of machines you have in the cluster. But even that can get weird, and depending on your db can be a pain to setup. Using them as a cluster index and you probably will most certainly create a hotspot index and poor lookup performance, but decent write. Just due to the fact that items probably are not grouped the same as your where clause. SSD's have hidden most of this for most databases. But the issues are the same.
Post reply on HN