OBJECTIDは12バイトであり、四つの成分のタイムスタンプ+ machash + PID + INC
_id内のデフォルトのMongoDBのコレクションはユニークです。お客様は、それがユニークなことを確認することができ、文書に挿入されたときに自動的に生成された_idドライバに依存していますか？
自動OBJECTIDの一意性
自動的に生成されたMongoのデーモンが生成されていませんが、ドライバが生成されます。
mongoshellとたJavaClientは、クライアントがOBJECTID生成されている見ることが実験から求めるOBJECTID生成一切使用し、サーバー側ではありません。フォローアップは、全体の状況を判断するために、プロセスの開始にランダムな値ので最後の3つのバイトは、常に連続していることは、同じクライアント・プロセスを生成するでしょう、そしてそれは長い時間のために、サーバー側の一般的なサービスの稼動して、サーバー側の後である場合複数のクライアントが提供OBJECTID場合サフィックスは、連続的ではないかもしれないが、実際は連続的です。
どうやらマシン名+ pidは同じであってもよいユニークな、異なるマシンのMACアドレスをOBJECTID保証するものではありませんアウトハッシュですが、可能性は比較的小さい。現在のプロセスのIDはまた、紛争のハッシュであってもよいし、可能性は比較的低いです;このランダム値からランダムな値にロード時間の現在の処理のObjectIdが時間の経過とともに、カウントアップし、異なるプロセスの増加値は、交差が可能で起こるが、可能性は非常に低いです。
競合が発生した場合は、一般的にちょうどその上にこのドライバの標準的な使用に従う、以上の4次元の小さな同時発生の確率が、この紛争の可能性ので、最小限にする必要があります。
このアルゴリズムドライバはUUIDの実装として見ることができます実際には、IDは常にユニークなタイムライン全体の複数のクライアントで生成されます。そこで、サーバはどのようにIDジェネレータのメンテナンスを必要としません。
自動的OBJECTID蓄積時間を追加したDBときOBJECTIDがある場合は、既存の挿入が失敗します。一般的にこのような理由のために不足している文書の確率が非常に小さい場合、アプリケーション層、インサートIDの競合が発生考慮していません。
なぜIDとUUIDは良いとして増分整数よりOBJECTID？
同時挿入に影響を与えるためにバインドされた整数増分は、複数のクライアントが最新のIDを知ることができない場合は、すべての一意性は、サービス側は、順序が唯一のドキュメントの挿入を扱うことができることを確認します。溶液としてMySQL設定インクリメンタルステップあるがIDの生成、マルチタスクマシンロードバランシングは、柔軟ではありません。OBJECTIDは12バイト、本質的に一意であることが保証本仕様に従って生成されたすべての駆動OBJECTID、から成ります。
ObjectId UUIDは別の具現化として見ることができます。