MongoDBでObjectIDの代わりにUUIDを使用する

MongoでUUIDを使用することは確かに可能であり、十分にサポートされています。たとえば、Mongoのドキュメントには、_idの一般的なオプションの1つとしてUUIDがリストされています。 フィールド。

考慮事項

• パフォーマンス –他の回答が述べているように、ベンチマークはUUIDが挿入のパフォーマンス低下を引き起こすことを示しています。測定された最悪のケース（コレクション内のドキュメントが1,000万から2,000万になる）では、約2〜3倍遅くなります。これは、1秒あたり2,000（UUID）ドキュメントと7,500（ObjectID）ドキュメントの挿入の違いです。これは大きな違いですが、その重要性はユースケースに完全に依存します。一度に何百万ものドキュメントをバッチ挿入しますか？私が作成したほとんどのアプリでは、一般的なケースは個々のドキュメントを挿入することです。同じベンチマークは、その使用パターンでは、違いが非常にであることを示しています。 小さい（6,250 -vs- 7,500;〜20％）。取るに足らないことではありませんが、地球を破壊することもありません。
• 移植性 –他の多くのDBプラットフォームは優れたUUIDをサポートしているため、移植性が向上します。または、UUIDが大きい（ビット数が多い）ため、ObjectIDをUUIDの「形状」に再パックすることができます。このアプローチは、直接の移植性ほど優れていませんが、既存のObjectIDとUUIDの間で「マッピング」する方法を提供します。
• 地方分権化 – UUIDの大きなセールスポイントの1つは、UUIDが普遍的に一意であることです。これにより、分散化された方法でどこにでもそれらを生成することが実用的になります（たとえば、「次の」値を決定するために信頼できる唯一の情報源を必要とする自動インクリメント値とは対照的です）。もちろん、MongoObjectIDもこの利点を公言しています。違いは、UUIDは15年以上前の標準に基づいており、（ほぼ？）すべてのプラットフォーム、言語などでサポートされていることです。これにより、エンティティ（または具体的には関連のセット）を作成する必要がある場合に非常に便利です。 エンティティ）データベースと対話することなく、ばらばらのシステムで。 IDと外部キーを使用してデータセットを作成し、将来のある時点で競合することなくグラフ全体をデータベースに書き込むことができます。これはMongoObjectIDでも可能ですが、それらを生成する/フォーマットで動作するコードを見つけるのは難しいことがよくあります。

修正

他のいくつかの答えとは反対に：

• UUIDはネイティブのMongoをサポートしています – UUID()を使用できます ObjectID()を使用するのとまったく同じ方法でMongoShellで機能します; UUID文字列を同等のBSONオブジェクトに変換します。
• UUIDは特に大きくありません –バイナリサブタイプ0x04を使用してエンコードされた場合 ObjectIDの96ビットと比較して、128ビットです。 （文字列としてエンコードされている場合は、 かなり無駄になり、約288ビットかかります。）
• UUIDにはタイムスタンプを含めることができます –具体的には、UUIDv1は、ObjectIDの32ビットと比較して、60ビットの精度でタイムスタンプをエンコードします。これは6桁以上の精度であるため、秒ではなくナノ秒になります。実際には、Mongo / JS Dateオブジェクトがサポートするよりも正確に作成タイムスタンプを保存するための適切な方法になる可能性がありますが、...
  • ビルドインUUID() functionはv4（ランダム）UUIDのみを生成するため、これを活用するには、IDの作成にアプリまたはMongoドライバーを使用する必要があります。
  • ObjectIDとは異なり、UUIDのチャンク化方法が原因で、タイムスタンプは自然な順序を示しません。これは、ユースケースに応じて良い場合と悪い場合があります。 （新しい標準によりこれが変更される可能性があります。以下の2021アップデートを参照してください。）
  • IDにタイムスタンプを含めることは、悪い考えである場合があります。 IDが公開されている場所では、ドキュメントの作成時刻が漏洩することになります。 （もちろん、ObjectIDはタイムスタンプもエンコードするため、これは部分的にも当てはまります。）
  • （仕様に準拠した）v1 UUIDを使用してこれを行う場合は、サーバーのMACアドレスの一部もエンコードしていることになります。これは潜在的に マシンを識別するために使用されます。おそらくほとんどのシステムでは問題ではありませんが、理想的でもありません。 （新しい標準によりこれが変更される可能性があります。以下の2021アップデートを参照してください。）

結論

Mongo DBを単独で考える場合、ObjectIDが当然の選択です。それらは箱から出してうまく機能し、完全に機能するデフォルトです。代わりにUUIDを使用する 値を操作するとき（バイナリタイプに変換する必要があるなど）とパフォーマンスの両方の点で、多少の摩擦が加わります。このわずかな不便が標準化されたID形式を持つ価値があるかどうかは、移植性とアーキテクチャの選択を重視するかどうかにかかっています。

異なるデータベースプラットフォーム間でデータを同期しますか？将来、データを別のプラットフォームに移行しますか？ IDを外部で生成する必要がありますか データベース、他のシステム、またはブラウザ？今ではない場合、将来のある時点で？ UUIDは面倒な価値があるかもしれません。

2021年8月の更新

IEFTは最近、フォーマットのいくつかの新しいバージョンを導入するUUID仕様のドラフト更新を公開しました。

具体的には、UUIDv6とUUIDv7はUUIDv1に基づいていますが、タイムスタンプチャンクを反転して、ビットが最上位から最下位に配置されるようにします。これにより、結果の値に、作成された順序を（多かれ少なかれ）反映する自然な順序が与えられます。新しいバージョンでは、サーバーのMACアドレスから派生したデータも除外されており、v1UUIDに対する長年の批判に対応しています。

これらの変更が実装に反映されるまでには時間がかかりますが、（IMHO）フォーマットを大幅に最新化および改善します。