News for hackers. Stuff that matters.

A comment on Understanding UUIDs, ULIDs and string representations. Parent comment

Re:Understanding UUIDs, ULIDs and string representations by jrochkind1 on Wednesday January 05, 2022 @09:18AM (#29809198)
Interesting, I learned about ULIDs for the first time from this article, which says: "The remaining 80 bits [in a ULID] are available for randomness", which I read as saying those last 80 (non-timestamp) bytes were random, not incremental. But this was misleading/I got the wrong idea?

Going to the spec [1]... Yeah, that's weird. The spec calls those 80 bytes "randomness", and apparently you are meant to generate a random number for the first use within a particular ms... but on second and subsequent uses you need to increment that random number instead of generating another random number?

Very odd. I don't entirely understand the design constraints that led to a non-random "randomness" section still called "randomn" in the spec even though they are not.

[1]: https://github.com/ulid/spec

[ Parent | on HN ]
Re:Understanding UUIDs, ULIDs and string representations by elevader on Wednesday January 05, 2022 @10:55AM (#29810522)
From what I gather this is done to persist the sort order. All calls within the same millisecond will get the same timestamp component so that can't be used to sort the ULIDs. So the "random" part is incremented and the resulting ULIDs can still be sorted by the order of function calls. This wouldn't be possible if the random part were truly random. I'm not sure this is a good idea but that is what I understood from the spec.
[ Parent | on HN ]
Re:Understanding UUIDs, ULIDs and string representations by layer8 on Wednesday January 05, 2022 @12:13PM (#29811746)
It’s not clear why they don’t just use a finer-grained timestamp component (e.g. nanoseconds) and increase that number if two events are within the same clock interval, and keep the random component random.
[ Parent | on HN ]
Re:Understanding UUIDs, ULIDs and string representations by elevader on Wednesday January 05, 2022 @12:53PM (#29812400)
The reference implementation is written in Javascript and I don't think that provides a reliable way to get timestamps this fine grained.
[ Parent | on HN ]
Re:Understanding UUIDs, ULIDs and string representations by layer8 on Wednesday January 05, 2022 @04:14PM (#29815021)
The underlying clock doesn’t need to be fine-grained; only the target representation needs to be fine-grained enough for the additional increments inserted by the code that generates the IDs. Effectively, the precision of the timestamp part needs to be large enough to support the number of IDs per second you want to be able to generate sustainably.
[ Parent | on HN ]
Re:Understanding UUIDs, ULIDs and string representations by WorldMaker on Wednesday January 05, 2022 @01:25PM (#29812887)
Also, the spec notes there is an entropy trade off in using more bits for the time stamp. More timestamp bits is fewer random bits, because ULIDs constrained themselves to a combined total 128 bits (to match GUID/UUID width).
[ Parent | on HN ]