Live data from Hacker News

New UUID Formats

ietf.org

151–160 of 172 posts

Re: New UUID Formats

#151
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

Just seconding this as a sane way to use UUIDs IME. Basically the sequential integer PK is the “internal ID”. IIRC in SQLite regardless of type or existence of PK there is a private sequential integer. Super handy pattern to use.

Are you talking about ROWID? [1]

> Except for WITHOUT ROWID tables, all rows within SQLite tables have a 64-bit signed integer key that uniquely identifies the row within its table. This integer is usually called the "rowid". The rowid value can be accessed using one of the special case-independent names "rowid", "oid", or "_rowid_" in place of a column name. If a table contains a user defined column named "rowid", "oid" or "_rowid_", then that name always refers the explicitly declared column and cannot be used to retrieve the integer rowid value.

> [...] If an INSERT statement attempts to insert a NULL value into a rowid or integer primary key column, the system chooses an integer value to use as the rowid automatically. A detailed description of how this is done is provided separately. [2]

[1]: https://www.sqlite.org/autoinc.html

[2]: https://www.sqlite.org/autoinc.html

Re: New UUID Formats

#152

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?

CUID might be a good alternative if you need something sortable over time: https://github.com/ericelliott/cuid

It's mentioned in this IETF draft, but I don't see the analysis made available

Re: New UUID Formats

#153
post #115

Earlier quoted context omitted.

> if you ever need to combine multiple data sources together in migration and recovery type scenarios This insane idea that combining data sources is a rare event in some unusual "migration and recovery" scenarios is one of the most poisonous and yet pervasive ideas in all of database design. You are always combining multiple data sources, all the time . Users submitting data from a form is a data source. Test, stagi…

While your tone might be a tad hyperbolic, I agree with your basic premise. If I could go back and tell my 30 year ago self one tip, it would be to use uuids over auto-increments. And this is back when that was expensive - in disk space and database time. Instead I'm stuck with my design, and as time has passed the real cost of auto-Inc has slowly revealed itself. What's interesting to me though is that this view is…

Can you give an example of an issue you faced with auto incrementing keys?

Though I can imagine scenarios, the worst I've ever run into was maxing out the integer size, bit that was easily remedied.

Re: New UUID Formats

#155

Earlier quoted context omitted.

Using purely random ids in your database destroys locality. They mention this in the introduction: > Non-time-ordered UUID versions such as UUIDv4 have poor database index locality. Meaning new values created in succession are not close to each other in the index and thus require inserts to be performed at random locations. The negative performance effects of which on common structures used for this (B-tree and its v…

100 billion UUIDs per millisecond is the 50% collision probability threshold. Achieving an acceptable collision probability for most applications would limit the UUID generation rate to more like thousands of UUIDs per millisecond. Even if one was not generating millions of UUIDs per second on average, the risk of spiky temporal distributions when generating UUIDs would still need to be considered.

Is it even possible to reach that rate given that generating a random hash takes some time?

Re: New UUID Formats

#156
Can someone ELI5 why Unix timestamp would be stored as left-padded 48 bits for a 32-bit or potentially a 64-bit number? Is it a coincidence that 48 is the middle of 32-64?

Re: New UUID Formats

#157

Earlier quoted context omitted.

“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...

On current day Linux, /dev/random will only block during bootup, never after it has once started.

Re: New UUID Formats

#159
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…

Raymond Chen's post on UUID sort orders has been indispensable to me at various points: https://devblogs.microsoft.com/oldnewthing/20190426-00/?p=10...

It's fun to note that the worst possible UUID sort order in existence isn't Microsoft's fault but Sun's. They missed the "unsigned" catch to those integers in the struct and Java sorts UUIDs as signed integers. (Which is why sometimes you'll notice in for instance Android apps Guids get sorted such that that 8000... < FFFF... < 0000... < 7FFF...)

Re: New UUID Formats

#160

Earlier quoted context omitted.

“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...

Like I said, ancient PRNGs written by confused people.
Post reply on HN