MongoDBの_idタイプを整数に変更するのは悪いことですか？
いいえ、まったく悪くはありません。実際、組み込みのObjectIdはインデックス内でかなりサイズが大きいので、より良いものがあると思われる場合は、__id_フィールドを何にでも。
しかし、これは大きなbutであり、特にデフォルトの公式ObjectIdから移動することを決定する場合、いくつかの考慮事項があります。ここに示されている自動インクリメント_ids： http://docs.mongodb.org/manual/tutorial/create-an-auto-incrementing-field/#auto-increment-counters-collection
findAndModifyとアトミックロックで実際に対処できるため、マルチスレッドはそれほど大きな問題ではありませんが、最初の問題にぶつかるだけです。 findAndModifyは最速の関数でも最軽量の関数でもありません。定期的に使用すると、パフォーマンスが大幅に低下します。
また、findAndModifyがなくても、自分でこれを行うことのオーバーヘッドを考慮する必要があります。挿入するたびに、追加のクエリを実行する必要があります。挿入するたびに一意性をクエリする必要がある一意のIDを持つ画像。最終的には挿入率が低下し、ロックが構築されます。
もちろん、ObjectIdは、挿入前にデータベースにアクセスして独自の一意性を確認または定式化する必要がないため、一意であることが本当に得意なので、このオーバーヘッドはありません。
そうは言っても、それは世界で最悪のアイデアではなく、それがあなたのシナリオに適していると思うならそれを試してくださいが、自動インクリメントIDが必要ない場合は負担になる可能性があることに注意してください。
できますが、整数が一意であることを確認する必要があります。
MongoDBは、ほとんどのSQLデータベースのような自動インクリメントフィールドをサポートしていません。新しいデータベースエントリを作成する複数のプロセスやスレッドを持つ分散またはマルチスレッドアプリケーションがある場合、それらが同じカウンタを使用することを確認する必要があります。そうしないと、2つのスレッドが同じ_idを持つドキュメントをデータベースに保存しようとする可能性があります。
その場合、そのうちの1つが失敗します。つまり、データベースが成功またはエラーを返すまで待機する必要があります（GetLastErrorを呼び出すか、書き込みの懸念をacknowledgedに設定する）。これは、fire-and-forgetでデータを送信するよりも時間がかかります。マナー。
私にはこの使用例がありました。_idを、検索用のドキュメントインデックスのシムハッシュを表す64ビット整数に置き換えました。
「取得または作成」するつもりだったので、最初のsimhashを提供し、レコードが存在しない場合は新しいレコードを作成するのが完璧でした。また、Gogolingの誰にとっても、MongoDBサポートは、シマハッシュがシャーディングとスケーリングに完全に最適であり、シャード間でデータを完全かつ本質的に分割し、キーを保存するため、より一般的なObjectIdよりも優れていると説明しました負のスペース（uint64はobjectIdよりもはるかに小さく、とにかく保存する必要があります）。
また、Google社員にとって、MongoDBの_idをobjectId以外のもので置き換えるのは非常に簡単です。定義されている_idを使用してオブジェクトを作成するだけです。必要に応じて整数を使用します。それだけです。Mongoは単にそれを使用します。同じ_idでドキュメントを作成しようとすると、エラー（E11000 /重複キー）が発生します。私のように、simhashingを使用している場合、これはあらゆる点で理想的です。