Today, the JDK includes support for generating random UUIDs ("v4") and
name-based UUID's ("v3"). These two types have random leading bits, and
that results in poor performance in database systems that have sorted
indexes (i.e. most of them).RFC 9562 [1], an update to the original UUID RFC, solves this by including standard formats for time-ordered UUIDs, namely the v7 variant: > UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4 <https://www.rfc-editor.org/rfc/rfc9562.html#uuidv4>), 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. > Time-ordered monotonic UUIDs benefit from greater database-index locality because the new values are near each other in the index. As a result, objects are more easily clustered together for better performance. The real-world differences in this approach of index locality versus random data inserts can be one order of magnitude or more. Now that v7 UUIDs are well-defined, does anyone think it would be useful to have in-jdk support for their generation? I am willing to do the work to shepherd a proposal forward, given consensus and interest. [1] https://www.rfc-editor.org/rfc/rfc9562.html -- Confidentiality note: This e-mail may contain confidential information from Nu Holdings Ltd and/or its affiliates. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone; for details about what personal information we collect and why, please refer to our privacy policy <https://nubank.com.br/contrato/politica-privacidade/>.
