UUIDの要点がよくわかりません。衝突の確率が事実上 nilであることは知っていますが、事実上 nilは不可能に近いわけではありません。
UUID を使用せざるを得ない例を誰か挙げてもらえますか? 私が見たすべての使用法から、UUID のない別の設計を見ることができます。確かに設計はもう少し複雑かもしれませんが、少なくとも失敗する可能性がゼロではないというわけではありません。
UUID はグローバル変数のようなにおいがします。グローバル変数を使用して設計を単純化する方法はたくさんありますが、それは単なる怠惰な設計です。
私は Ruby 用の UUID ジェネレーター/パーサーを作成したので、この件についてかなり詳しいと思います。4 つの主要な UUID バージョンがあります。
バージョン 4 の UUID は、基本的に、UUID のバージョンとバリアントを識別するためのビット操作を伴う、暗号的に安全な乱数ジェネレーターから引き出された 16 バイトのランダム性です。これらが衝突する可能性は非常に低いですが、PRNG が使用されている場合や、本当に、本当に、本当に、本当に、本当に運が悪い場合に発生する可能性があります。
バージョン 5 およびバージョン 3 の UUID は、それぞれ SHA1 および MD5 ハッシュ関数を使用して、名前空間を既に一意のデータの一部と組み合わせて UUID を生成します。これにより、たとえば、URL から UUID を生成できます。ここでの衝突は、基礎となるハッシュ関数にも衝突がある場合にのみ可能です。
バージョン 1 UUID が最も一般的です。それらは、ネットワーク カードの MAC アドレス (スプーフィングされていない限り、一意である必要があります)、タイムスタンプ、および通常のビット操作を使用して UUID を生成します。MAC アドレスを持たないマシンの場合、暗号的に安全な乱数ジェネレーターを使用して 6 ノード バイトが生成されます。タイムスタンプが前の UUID と一致するのに十分な速さで 2 つの UUID が順番に生成された場合、タイムスタンプは 1 増加します。次のいずれかが発生しない限り、衝突は発生しません。2 つの異なる UUID 生成アプリケーションを実行している 1 台のマシンが、まったく同時に UUID を生成します。ネットワーク カードがない、または MAC アドレスへのユーザー レベル アクセスがない 2 台のマシンには、同じランダム ノード シーケンスが与えられ、まったく同時に UUID が生成されます。
現実的には、これらのイベントが 1 つのアプリケーションの ID 空間内で偶然に発生することはありません。たとえば、インターネット全体の規模で ID を受け入れている場合や、ID の競合が発生した場合に悪意のある個人が何か悪いことを行う可能性がある信頼できない環境で ID を受け入れている場合を除き、心配する必要はありません。私と同じバージョン 4 の UUID を生成しても、ほとんどの場合問題にならないことを理解しておくことが重要です。あなたとはまったく異なる ID 空間で ID を生成しました。私のアプリケーションは衝突について決して知らないので、衝突は問題ではありません。率直に言って、悪意のあるアクターのいない単一のアプリケーション空間では、バージョン 4 の UUID でも衝突が発生するずっと前に、地球上のすべての生命が絶滅します。
また、2^64 * 16 は 256 エクサバイトです。1 つのアプリケーション空間で 50% の確率で ID 衝突が発生する前に、256 エクサバイト相当の ID を格納する必要があります。
UUID によって得られるもので、他の方法では行うのが非常に難しいことは、中央機関に相談したり調整したりすることなく、一意の識別子を取得することです。ある種の管理されたインフラストラクチャなしでそのようなものを取得できるという一般的な問題は、UUID が解決する問題です。
誕生日のパラドックスによると、2^64 個の UUID が生成されると、UUID の衝突が発生する可能性は 50% になると読んだことがあります。現在、2^64 はかなり大きな数ですが、衝突の可能性が 50% というのはリスクが高すぎるように思えます (たとえば、衝突の可能性が 5% になる前に、いくつの UUID が存在する必要がありますか? それは確率が大きすぎるように思えます)。 .
その分析の問題は 2 つあります。
UUID は完全にランダムではありません。UUID の主要なコンポーネントは、時間や場所に基づいています。したがって、実際に衝突の可能性を持たせるには、衝突する UUID を異なる UUID ジェネレーターからまったく同時に生成する必要があります。複数の UUID が同時に生成される可能性は十分にありますが、この非常に小さな UUID のセット間の衝突の可能性をほぼ不可能にするのに十分な他のガンク (位置情報またはランダム ビットを含む) があると言えます。 .
厳密に言えば、UUID は、比較対象となる他の UUID セットの中で一意である必要があるだけです。データベース キーとして使用する UUID を生成している場合、COM インターフェイスを識別するために同じ UUID が使用されている邪悪な代替宇宙のどこかで問題はありません。アルファ ケンタウリに「マイケル バー」という名前の誰か (または何か) がいても混乱しないように。
何事にも失敗の可能性はゼロではありません。UUID の衝突よりもはるかに発生しやすい問題 (つまり、考えられるほとんどすべて) に集中します。
また、あなたの体のすべての粒子があなたが座っている椅子を同時に通り抜け、あなたが突然床に座っていることに気付く可能性はゼロではありません。
あなたはそれについて心配しますか？
UUIDを回避するためのスキームがあります。サーバーをどこかにセットアップして、ソフトウェアの一部が普遍的に一意の識別子を必要とするたびに、そのサーバーに接続し、それを配布できるようにします。単純！
ただし、あからさまな悪意を無視したとしても、これにはいくつかの実際的な問題があります。特に、そのサーバーに障害が発生したり、インターネットの一部から到達不能になったりする可能性があります。サーバーの障害に対処するにはレプリケーションが必要であり、これを正しく行うのは非常に難しく(コンセンサスの構築が厄介な理由については、Paxos アルゴリズムに関する文献を参照してください)、速度もかなり遅いです。さらに、すべてのサーバーが「ネット」の特定の部分から到達できない場合、そのサブネットに接続されているクライアントはすべて新しい ID を待っているため、何もできません。
つまり...単純な確率的アルゴリズムを使用して、地球の存続期間中に失敗する可能性が低いものを生成するか、(資金を提供して)展開 PITA になり、頻繁に失敗する主要なインフラストラクチャを構築します。私はどちらに行くか知っています。
新しいオブジェクトを作成する前に毎回データベースにクエリを実行する必要がある単純なデータベース アプリケーションなどの代替案を見ると、UUID を使用するとシステムの複雑さが効果的に軽減されることがすぐにわかります。許可 - int キーを使用する場合、32 ビットであり、128 ビット UUID の 4 分の 1 に格納されます。確かに - UUID 生成アルゴリズムは、単純に数値をインクリメントするよりも多くの計算能力を必要とします。しかし - 誰が気にしますか？それ以外の場合は一意の番号を割り当てる「権限」を管理するオーバーヘッドは、意図した一意性 ID スペースに応じて、それを桁違いに簡単に上回ります。
UUID==遅延設計について
私はあなたの戦いを選ぶことについて同意しません. 重複する UUID が統計的に不可能であり、数学が証明されている場合、心配する必要はありません。小さな N UUID 生成システムを中心に設計するのに時間を費やすことは非現実的です。システムを改善できる方法は他にもたくさんあります。
バージョン 1 アルゴリズムを使用すると、同じ MAC アドレスから生成される UUID が 1 ミリ秒あたり 10 個未満であるという制約の下で、衝突が不可能になるようです。
概念的には、UUID の元の (バージョン 1) 生成スキームは、UUID バージョンを、UUID を生成しているコンピューターの MAC アドレスと連結し、西洋でグレゴリオ暦が採用されてからの 100 ナノ秒間隔の数と連結することでした。 . 実際には、実際のアルゴリズムはもっと複雑です。このスキームは、十分に「不透明」ではないという点で批判されています。UUID を生成したコンピュータの ID とその生成時刻の両方が明らかになります。
それがどのように機能するかを誤解した場合、誰かが私を修正してください
UUID を要求する他の誰かの API を使用しなければならない場合を除けば、もちろん常に別の解決策があります。しかし、これらの代替手段は、UUID が行うすべての問題を解決するでしょうか? それらすべてを一度に解決できたのに、それぞれが異なる問題を解決するためにハックの層をさらに追加することになりますか?
はい、理論的には UUID が衝突する可能性があります。他の人が指摘しているように、検討する価値がないという点までばかげてありそうにありません. これまでに起こったことはなく、おそらく今後も起こらないでしょう。気にしないで。
衝突を回避する最も「明白な」方法は、単一のサーバーがすべての挿入で一意の ID を生成できるようにすることです。これは明らかに深刻なパフォーマンスの問題を引き起こし、オフライン生成の問題をまったく解決しません。おっとっと。
もう1つの「明白な」解決策は、一意の番号のブロックを事前に配布する中央機関です。これは、基本的に、生成マシンのMACアドレスを使用して（IEEE OUIを介して）UUID V1が行うことです。しかし、すべての中央機関が最終的に台無しになるため、重複した MAC アドレスが発生するため、実際には、これは UUID V4 の衝突よりもはるかに可能性が高くなります。おっとっと。
UUID の使用に反対する最良の議論は、UUID が「大きすぎる」ということですが、(かなり) 小さいスキームでは、最も興味深い問題の解決に失敗することは避けられません。UUID のサイズは、これらの問題を解決する上での有用性に固有の副作用です。
UUID が提供するものを必要とするほど問題が大きくない可能性があります。その場合は、他のものを自由に使用してください。しかし、問題が予期せず大きくなった場合 (ほとんどの場合そうです)、後で切り替えることになります。成功するように設計するのは簡単なのに、なぜ失敗するように設計するのでしょうか?
UUID は、グローバル変数に関連するすべての悪いコーディング プラクティスを体現していますが、それらはキットのさまざまな部分に分散できるスーパーグローバル変数であるため、さらに悪いことです。
最近、プリンターを正確な交換モデルに交換したときにこのような問題が発生し、どのクライアント ソフトウェアも機能しないことがわかりました。