複数のプロセスを持つ複数のWebサーバーがある場合、一意性を失って削除できるものは実際にはありません。
ObjectIdの性質を見ると ：
- Unixエポックからの秒数を表す4バイトの値
- 3バイトのマシン識別子
- 2バイトのプロセスID、および
- ランダムな値で始まる3バイトのカウンター。
安全に削除できるものはそれほど多くないことがわかります。最初の4バイトは時間であるため、タイムスタンプの一部をクリーンで安全な方法で削除するアルゴリズムを実装するのは困難です。
マシン識別子とプロセス識別子は、データベースサーバーのクライアントとして機能する複数のサーバーやプロセスがある場合に使用されます。これらのいずれかを削除すると、再び重複する可能性があります。最後の3バイトのランダムな値は、頻繁に要求された場合でも、同じマシン上の同じプロセス内の2つの識別子が一意であることを確認するために使用されます。
注文idとして使用していた場合 、そして確実な一意性が必要な場合は、接続されたデータベースクライアントが多数ある場合に一意の番号を生成するための堅牢で効率的な分散メカニズムを提供するように慎重に設計されているため、12バイトの番号から何も削除しません。
ObjectIdの最後の5文字を取得した場合、特定の期間に競合が発生する可能性はどのくらいですか？
- プロセスID
- カウンター
競合の可能性は高い 。プロセスIDは全期間を通じて同じままである可能性があり、他の番号は4095の注文後に繰り返される単なる増分番号です。ただし、プロセスがリサイクルされると、古い注文などと競合する可能性もあります。また、複数のデータベースクライアントについて話している場合は、その可能性も高くなります。数字を切り詰めようとはしませんでした。不幸な顧客が注文しようとする価値はありません。
ObjectIdsを生成するデータベースクライアントが複数ある場合は、タイムスタンプとランダムシード値でさえ十分ではありません。 。特にデータベースクライアントのファームのコンテキストでさまざまな部分を調べ始めると、それらが存在する理由と、それらを削除するとObjectIdがメルトダウンする可能性がある理由を確認する必要があります。 世代。
一意の番号を作成してデータベースに保存するアルゴリズムを実装することをお勧めします。それはとても簡単です。パフォーマンスに少し影響しますが、安全です。
これ
を書きました ObjectIdを使用する際の課題について少し前に答えてください URLで。 MongoDBを使用して一意の自動インクリメント番号を作成する方法へのリンクが含まれています。