タイトルに関する短い質問です。デフォルトでセーフモードになっているmongo Shellを使用していますが、この動作を無効にすることでパフォーマンスを向上させたいと考えています。
コンテキストを知りたい人への長い質問: 私は次のような膨大なデータセットに取り組んでいます
{
_id:ObjectId("azertyuiopqsdfghjkl"),
stringdate:"2008-03-08 06:36:00"
}
および他のいくつかのフィールドと、そのような約2億5000万のドキュメントがあります（インデックスの重みが36Goのデータベース全体）。日付を実際の ISODATE フィールドに変換したい。次のような更新クエリを作成する方法を少し検索しました
db.data.update({},{$set:{date:new Date("$stringdate")}},{multi:true})
しかし、これを機能させる方法が見つからず、ドキュメントを次々に取得し、新しい Date(stringdate) を値として取得する新しいフィールドを設定する更新を行うスクリプトを作成することにしました。クエリは _id を使用するため、デフォルトのインデックスが使用されます。
問題は、非常に長い時間がかかることです。新しいフィールドが追加されたときにデータの再配置の問題があるため、データベースを作成したときに空の日付オブジェクトを挿入した場合にのみ、パフォーマンスが向上することをすでに理解しました。また、関連するフィールドにインデックスを設定して、データベースをチャンクごとに処理します。最後に、サーバーとワークステーションの両方で複数の mongo クライアントを同時に実行して、制限要因がデータベース ロックの可用性であり、CPU やネットワーク コストなどの他の要因ではないことを確認しました。
mongotop、mongostats、および Web 監視インターフェイスを使用して全体を監視し、70% の時間で書き込みロックがかかっていることを確認しました。mongodb の書き込みロックがより正確な粒度を持っていないことに少しがっかりしています。干渉のリスクがない限り、同じコレクションに対して同時書き込み操作を許可しないのはなぜですか? 考えてみると、各シャードに個別のロックがあったため、同じサーバーにとどまっている場合でも、コレクションをダースのシャードにシャーディングする必要がありました。
しかし、現在のデータベース構造に対して今は何もできないので、少なくとも私の時間の 90% (現在の 70%) を mongo で書くためにパフォーマンスを改善する方法を探しました。デフォルトのmongoシェルの私のスクリプトは、更新を行うたびに、後で呼び出される getLastError() もあり、99.99%の成功の可能性があり、失敗した場合でも私はできるので、私はそれを望まない単一の例外を取得するために、大きなプロセスの終了後に集約リクエストを作成します。
getLastError 呼び出しを非アクティブにすることでパフォーマンスが大幅に向上するとは思いませんが、試してみる価値はあると思います。
ドキュメントを調べたところ、デフォルトの動作は確認できましたが、変更手順はわかりませんでした。なにか提案を？