Pythonでuuid.uuid1（）とuuid.uuid4（）をいつ使用すればよいですか？

私はドキュメントの2つの違いを理解しています。

uuid1()：
ホストID、シーケンス番号、および現在時刻からUUIDを生成します

uuid4()：
ランダムなUUIDを生成します。

したがってuuid1、マシン/シーケンス/時間情報を使用してUUIDを生成します。それぞれの長所と短所は何ですか？

私uuid1()はそれがマシン情報に基づいているので、プライバシーの懸念があることを知っています。どちらか一方を選ぶと、もう少し微妙なところがあるのか​​な。uuid4()完全にランダムなUUIDなので、今すぐ使用します。しかしuuid1、衝突のリスクを減らすために使用する必要があるのか​​と思います。

基本的に、私は、一方を他方と比較して使用するためのベストプラクティスに関する人々のヒントを探しています。ありがとう！

uuid1()衝突が発生しないことが保証されています（同時に多数の衝突を作成しないことを前提としています）。とuuidコンピューターの間に接続がないことが重要である場合は、MACアドレスを使用してコンピューター間で一意にするために使用しません。

100ns未満で2 ^14を超えるuuid1 を作成することで重複を作成できますが、これはほとんどの使用例では問題になりません。

uuid4()あなたが言ったように、ランダムなUUIDを生成します。衝突の可能性は本当に、本当に、本当に小さいです。十分に小さいので、心配する必要はありません。問題は、悪い乱数ジェネレーターが衝突を起こしやすくすることです。

ボブ・アマンによるこの素晴らしい答えはそれをうまくまとめています。（私は答え全体を読むことをお勧めします。）

率直に言って、悪意のある俳優のいない単一のアプリケーション空間では、衝突が発生するずっと前に、バージョン4のUUIDであっても、毎秒かなりの数のUUIDを生成している場合でも、地球上のすべての生命の絶滅が起こります。

たとえば、複数のオンライントランザクションがスケーリングのために複数のマシンで処理される場合など、UUIDが別々のマシンで生成される場合uuid1()でuuid4()はなく、検討する1つの例があります。

このような状況では、たとえば、疑似乱数ジェネレーターの初期化方法の選択が不適切なために衝突が発生するリスクがあり、生成されるUUIDの数が増える可能性があるため、IDが重複して作成される可能性が高くなります。

uuid1()その場合のもう1つの関心は、各GUIDが最初に生成されたマシンが暗黙的に（UUIDの「ノード」部分に）記録されることです。これと時間情報は、デバッグでのみ役立つ場合があります。

私のチームは、データベースアップグレードスクリプトにUUID1を使用して問題が発生し、数分以内に〜120kのUUIDを生成しました。UUIDの衝突により、主キー制約違反が発生しました。

数百台のサーバーをアップグレードしましたが、Amazon EC2インスタンスでこの問題に数回遭遇しました。時計の解像度が悪いのではないかと思い、UUID4に切り替えることで解決しました。

uuid1を使用する際の注意点の1つは、デフォルトの呼び出し（clock_seqパラメーターを指定しない）を使用した場合、衝突が発生する可能性があります。ランダム性が14ビットしかない（100ns以内に18のエントリを生成すると、衝突の確率が約1％になる）を参照してください。誕生日のパラドックス/攻撃）。この問題はほとんどの場合で発生することはありませんが、クロックの解像度が低い仮想マシンでは問題が発生します。

おそらく言及されていないのは、局所性の問題でしょう。

MACアドレスまたは時間ベースの順序付け（UUID1）を使用すると、ランダムに分散されたもの（UUID4）（ここを参照）より数値を並べて並べる作業が少なくなるため、データベースのパフォーマンスが向上します。

関連する2番目の問題は、オリジンデータが失われたり、明示的に保存されなかったりした場合でも、UUID1の使用がデバッグに役立つ可能性があることです（これは明らかにOPによって言及されたプライバシーの問題と競合しています）。

受け入れられた回答に加えて、いくつかの場合に役立つ可能性がある3番目のオプションがあります。

ランダムMACを持つv1（「v1mc」）

ランダムなブロードキャストMACアドレスを使用してv1 UUIDを意図的に生成することにより、v1とv4のハイブリッドを作成できます（これはv1仕様で許可されています）。結果のv1 UUIDは（通常のv1のように）時間に依存しますが、（v4のように）すべてのホスト固有の情報が欠けています。また、耐衝突性においてもv4に非常に近くなります。v1mc=時間の60ビット+ランダムビット61 =一意のビット121。v4 = 122ランダムビット。

私が最初にこれに遭遇したのは、Postgresのuuid_generate_v1mc（）関数でした。それ以来、次の同等のpythonを使用しています。

from os import urandom
from uuid import uuid1
_int_from_bytes = int.from_bytes  # py3 only

def uuid1mc():
    # NOTE: The constant here is required by the UUIDv1 spec...
    return uuid1(_int_from_bytes(urandom(6), "big") | 0x010000000000)

（注：UUIDオブジェクトを直接作成する、より長いバージョンとより速いバージョンがあります。誰かが望めば投稿できます）

1秒あたりのコール数が多い場合、これはシステムのランダム性を使い果たす可能性があります。代わりにstdlib モジュールを使用することもできますrandom（おそらくより高速になります）。ただし、注意が必要です。攻撃者がRNG状態を判断して、将来のUUIDを部分的に予測できるようになるまでには、数百のUUIDしかかかりません。

import random
from uuid import uuid1

def uuid1mc_insecure():
    return uuid1(random.getrandbits(48) | 0x010000000000)