Time-ordered UUID support, for improved database locality

[Ghadi Shayban]

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/>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240630/20168f47/attachment.htm>