Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Future LT#12 UUIDは本当に一意を保証してくれるのか?

Future LT#12 UUIDは本当に一意を保証してくれるのか?

フューチャーアーキテクトのLT大会第12回(発表資料)
UUIDが本当に一意か疑って調査した話

kkuchikata

August 24, 2021
Tweet

Other Decks in Technology

Transcript

  1. UUIDとシーケンスの違い UUID 数値シーケンス サンプル 0aebf1c2fd8811eb849800059a3c7a00 1,2,3,4~等 順序 ランダム(連番にはならない) 連続 その他

    IDを推測し難い 連番のためIDが推測しやすい データサイズ ※ 16BYTE(=128bit / 8) ⇒DBに入れるとINDEXが重い 2BYTE(1から32767) 4BYTE(1から2147483647) 8BYTE(1から9223372036854775807) マスタ 存在しない 必要(1箇所で管理) 同時実行 可 (どのサーバ上でも生成可能) 不可 (マスタがあるサーバでのみ生成可、複数箇 所で利用される場合は順番待ちでボトルネック になりやすい) ※ postgreSQLのカラムサイズの場合
  2. UUIDのバージョン Ver 生成値 一意性 1 60bit:タイムスタンプ(1/10億秒単位) 14bit:クロックシーケンス 48bit:ノード(MACアドレス、または乱数) 理論的には衝突し得る 2

    28bit:タイムスタンプ 6bit:クロックシーケンス 40bit:ローカルID/ローカルドメイン 48bit:ノード 理論的には衝突し得る (DCEシステムにおける権限認可 を目的に設計されたもの、システ ム開発では使用しない) 3/5 122bit:ユニークな名前(URL等)をハッシュ関数で変換 インプットが一意であれば担保 4 122bit:乱数 理論的には衝突し得る ※4bitはバージョン、2bitはバリアントを表す
  3. UUID Ver1のデータ構成 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678 11010101011101011010100100010100111111001111100000010001111010111010010100110101000000000000010110011010001111000111101000000000 11010101011101011010100100010101111111001111100000010001111010111010010100110110000000000000010110011010001111000111101000000000 11010101011101011010100100010110111111001111100000010001111010111010010100110111000000000000010110011010001111000111101000000000 11010101011101011010100100010111111111001111100000010001111010111010010100111000000000000000010110011010001111000111101000000000 11010101011101011010100100011000111111001111100000010001111010111010010100111001000000000000010110011010001111000111101000000000 11010101011101011010100100011001111111001111100000010001111010111010010100111010000000000000010110011010001111000111101000000000 11010101011101011010100100011010111111001111100000010001111010111010010100111011000000000000010110011010001111000111101000000000

    11010101011101011010100100011011111111001111100000010001111010111010010100111100000000000000010110011010001111000111101000000000 11010101011101011010100100011100111111001111100000010001111010111010010100111101000000000000010110011010001111000111101000000000 48 ノード(MACアドレス) 32 タイムスタンプ 下位 2+14 クロック シーケンス 4 ver 16 タイムスタンプ 中位 12 タイムスタンプ 上位 同一サーバで実行する 場合は同値 シーケンス、+1する 2^14=16384回で0に戻る 0.0000000001秒単位で保持 (上記以上の間隔で生成すると必ず一意)
  4. UUIDを3000万件INSERT時の処理速度変化① (100万件毎のINSERT時間) 0 50 100 150 200 250 300 1

    2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 INDEX 有り INDEX 無し 単位(秒) 単位(100万件) 総レコード 件数 INDEX 有り INDEX 無し 1M 13.49 1.97 2M 12.28 1.91 3M 12.77 1.95 4M 14.61 1.97 5M 24.47 2.02 6M 33.86 2.44 7M 44.99 2.17 8M 42.92 2.24 9M 48.11 2.01 10M 57.6 2.38 11M 54.74 2.23 12M 59.61 2.3 13M 75.68 1.97 14M 76.19 2.6 15M 74.11 2.18 16M 62.93 2.11 17M 78.54 1.9 18M 76.34 1.93 19M 69.48 2.46 20M 77.47 2.24 21M 104.58 2.42 22M 112.26 2.29 23M 126.25 2.04 24M 130.18 2.21 25M 153.48 1.81 26M 198.14 1.94 27M 218.42 1.91 28M 225.18 2.79 29M 246.75 2.5 30M 235.41 2.7 単位(秒)
  5. UUIDを3000万件INSERT時の処理速度変化② (3000万件INSERT完了までの累計時間) 単位(秒) 単位(100万件) 0 500 1000 1500 2000 2500

    3000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 INDEX有り INDEX無し 自分のノートPC内で3回 実施した平均値 ※環境・性能によって曲 線の傾きは変わります
  6. まとめ • V1 ◦ 累計生成回数によらず衝突発生確率は一定 (タイムスタンプを含むため) ◦ 衝突を発生させるにはスーパーコンピュータ並の性能が必要 • V4

    ◦ 累計生成回数に応じて、衝突発生確率が指数関数的に上がる ◦ 衝突発生確率が現実的な値になるほど、DBにデータを保持するのは、 物理的・処理性能的に困難(大幅な速度低下が見込まれる)