私の場合、ほとんどのIDは、限られたサーバーセット内ではなく、多数のモバイルクライアント内で生成されます。この場合、正当な懸念があるのではないかと思います。
それは私には非常に悪いアーキテクチャのように聞こえます。 2層アーキテクチャを使用していますか？モバイルクライアントがデータベースに直接アクセスできるのはなぜですか？本当にネットワークベースのセキュリティに依存したいですか？
とにかく、衝突確率についてのいくつかの審議：
UUIDもObjectIdも、そのサイズに依存しません。つまり、どちらもランダムな数値ではありませんが、衝突の可能性を体系的に削減しようとするスキームに従います。 ObjectIdの場合、その構造は次のとおりです。
- UNIXエポックから4バイト秒
- 3バイトのマシンID
- 2バイトのプロセスID
- 3バイトカウンター
これは、UUIDとは異なり、ObjectIdは単調である（1秒以内を除く）ことを意味します。これはおそらく最も重要なプロパティです。単調なインデックスを使用すると、Bツリーがより効率的に入力され、IDによるページングが可能になり、IDによる「デフォルトの並べ替え」が可能になり、カーソルが安定します。もちろん、抽出しやすいタイムスタンプが付けられます。これらは知っておくべき最適化であり、巨大になる可能性があります。
他の3つのコンポーネントの構造からわかるように、単一のプロセスで1kを超える挿入を実行している場合（サーバーからでも実際には不可能）、またはマシンの数が増えると、衝突が発生する可能性が非常に高くなります。約10を過ぎた場合（誕生日の問題を参照）、または1台のマシンのプロセス数が大きくなりすぎた場合（これもランダムな数値ではありませんが、マシン上で本当に一意ですが、2バイトに短縮する必要があります） 。
当然、衝突が発生するには、すべてで一致する必要があります。 これらの側面があるため、2台のマシンが同じマシンハッシュを持っている場合でも、クライアントはまったく同じ秒と同じプロセスIDに同じカウンター値を挿入する必要がありますが、そうです、これらの値は衝突する可能性があります。
>