さようなら Integer、こんにちは UUIDv7

• Buildkite は PK として新しい UUIDv7 標準を採用し、従来のシーケンシャル PK と UUID 補助キーの仕組みを置き換えた
• UUID（Universally Unique Identifier）は独立して生成できる一意な識別子であり、分散システムやデータベースで広く使われている
• UUID は、予測しにくさ、内部情報や機密情報の露出防止、追加の防御層の提供など、連番の整数識別子に比べてさまざまな利点を持つ
• しかし、標準的な非時系列 UUID のランダム性は、データベースの性能問題を引き起こす可能性がある
• これを解決するために、Buildkite は時間順の UUIDv4 互換 UUID を試験導入し、これによってメインデータベースの Write Ahead Log（WAL）率を 50% 削減した
• UUID バージョン 7（UUIDv7）は、最上位の 48 ビットに Unix タイムスタンプをミリ秒単位でエンコードし、残りの 74 ビットはランダムに生成される
• Buildkite は、すべての新規テーブルの主キーとして UUIDv7 を使用することを決め、これによって識別子生成の調整が不要になり、アプリケーションロジックが単純化された
• Instagram の ShardingID 実装や Shopify の複合主キー実装のような代替案も検討されたが、チームは UUIDv7 を選択した
• UUIDv7 への移行では、UUID の 128 ビット長により追加の保存領域が必要になるが、これはデータベース行の残りの保存領域と比べればごくわずかである
• 現在、最大の Postgres データベースをシャーディングしており、必要であれば将来的に識別子へシャード番号を含めるため UUIDv8 を使う可能性がある

[GN⁺]

Hacker Newsの意見

• UUIDv7は順序付きキーであるため内部の分散システムには有益だが、潜在的なセキュリティ上の問題から公開識別子としては適さない可能性がある。
• ランダムIDは性能に悪いと主張されることがあるが、実際には単一ノードのホットスポットを防ぐため、分散ストレージシステムにはより適している。
• 識別子に求められる要件や望ましい特性が変化するため、UUIDには複数のバージョンがある。
• UUIDv7は、効率的なインデックス化のための逐次的な主キーの利点と、外部利用のためのUUID補助キーを組み合わせる。
• UUIDv7の潜在的な問題の1つは、ユーザーがIDから生成時刻を抽出できることだ。
• PostgreSQL向けのUUID v7関数がオープンソースとして公開されており、バルク挿入の高速化などの利点を提供する。
• UUIDv7はPostgresのuuid型と併用でき、これは正しい長さを持つ任意のデータを受け入れる。
• データ量や作成日時に関する情報を隠すために、逐次的な64ビット主キーと、外部利用向けの追加のランダム64ビットキーを好む人もいる。
• UUIDは、後でマージする必要がある多くの分離されたソースからキーを生成するのに有用だ。
• GUIDs/UUIDsを「検証」する必要性については議論があり、これらはしばしば不透明な識別子として扱われる。
• UUIDv7とULIDsのどちらを選ぶかは具体的な要件によって異なり、ULIDsはUUIDsがメタデータに使うものより6ビット多い追加のランダム性を提供する。