3 ms·
One simple workaround could be to use something like UUID version 7[0], using just the first part that encodes the time, and dropping the rest. [0]: https://gi
by oittaa 4y ago
One simple workaround could be to use something like UUID version 7[0], using just the first part that encodes the time, and dropping the rest.
[0]: https://github.com/ietf-wg-uuidrev/rfc4122bis https://github.com/ietf-wg-uuidrev/rfc4122bis
- dv888dv8v8 4y agoGiven that UUID's purpose is in the name (_unique_), squeezing a timestamp in there seems to be a hack with unexpected consequences at best. Linking to a github repo without any context does not prove your point.
- paulgb 4y agoIt’s true, if the only goal of a UUID was minimizing collisions with a given number of bits, storing the timestamp would be a waste of entropy (assuming that generation rate is non-uniform over time.) The reason they encode a timestamp (which I learned from the link upthread) is interesting, though. They knew that people use UUIDs as keys in data structures like BTrees, and using a timestamp improves memory/disk locality. > 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 variants) can be dramatic.
- codetrotter 4y ago> Linking to a github repo without any context does not prove your point. The GitHub link in question is that of an IETF working group. https://www.ietf.org/about/introduction/ https://www.ietf.org/about/introduction/ Granted, linking to the draft of the standard may have been more clear. The draft is in the repo they linked. Direct link to the draft here: https://ietf-wg-uuidrev.github.io/rfc4122bis/draft-00/draft-ietf-uuidrev-rfc4122bis.html https://ietf-wg-uuidrev.github.io/rfc4122bis/draft-00/draft-... Alternatively, the currently published draft: https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-00.html https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bi... > squeezing a timestamp in there seems to be a hack with unexpected consequences at best It’s not a hack. It’s a future standard, and it is going to be widely used. IETF is an organisation that publishes many of the standards that the internet and computer software is built with. Including publishing a standard for the existing UUID variants in common use today: > UUIDs are standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). > UUIDs are documented as part of ISO/IEC 11578:1996 "Information technology – Open Systems Interconnection – Remote Procedure Call (RPC)" and more recently in ITU-T Rec. X.667 | ISO/IEC 9834-8:2005. > The Internet Engineering Task Force (IETF) published the Standards-Track RFC 4122, technically equivalent to ITU-T Rec. X.667 | ISO/IEC 9834-8. https://en.wikipedia.org/wiki/Universally_unique_identifier https://en.wikipedia.org/wiki/Universally_unique_identifier UUID was specifically created so that it could support different versions. Some of the bits in UUID identify the version. Hence, a standard that says how to encode timestamp into UUID, and assigns a version for this format, UUID v7, is in fact the exact opposite of a hack. And the reason they made UUID v7 is to have chronologically sortable UUIDs. They are inspired/based on ULID format, but made to conform to the UUID format.