1

views_countmales_views_countおよびfemales_views_countフィールドを持つコレクションがあるとしましょう。$incページが表示されたときに、カウント フィールドをそれぞれ (インクリメント)できるようにしたいと考えています。

これに関する問題は、複数の同時接続を受け取り、競合状態が発生する可能性があることです。

Mongodb のアトミック操作について読んでいます。彼らは通常、成功または失敗のアプローチを持っています。レコードが書き込まれているか、書き込まれていないかのどちらかです。つまり、操作が失敗したかどうかを判断し、失敗した場合は再試行するロジックを作成する必要があるということですか?

私のシナリオに戻ります。(競合状態が発生した場合でも) すべてのビューをカウントしたい場合はどうすればよいでしょうか。Mongodb ロックが従来の RDBMS とは少し異なることは知っています。通常、楽観的ロック手法を実装します。に似ている:

begin
  # .. do work .. determine if user is a male or a female
  stat.save
rescue StaleDocumentError
  stat.reload
  retry
end

それとも、アトミック操作は、更新を行うのはサーバーであり、真実が何であるかについて信頼できるサーバーであるため、競合状態を防ぐためのものですか? もしそうなら、楽観的/悲観的ロック技術を実装する必要はありますか?それともアトミック操作を使用する場合、Mongodb はそれを処理してくれますか?

4

1 に答える 1

2

などのアトミック操作を使用している場合$inc、競合状態はありません。異なるスレッドからの 2 つの増分がある場合、それらはサーバーによって受信された順序で適用され、両方の操作が適用された後のドキュメントの最終結果は同じになります。

を使用してフィールドを特定の値に更新する場合$set、「勝者」の値が最後$setに適用されます。アプリケーションのユースケースが同じフィールドの競合する更新につながる可能性がある場合は、楽観的ロック/バージョン管理が役立ちます。

例外処理に関する限り、データベース操作によってサーバー例外 (ネットワーク エラー、キーの重複など) が発生する可能性があると想定し、必要に応じて再試行する必要があります。独自の楽観的ロックを実装することを選択しない限り、アトミック更新と非アトミック更新に必要な特別なロジックはありません (その場合、おそらくドキュメントの現在のバージョンを再フェッチして操作を再試行します)。

MongoDB のマニュアルでは、Isolate Sequence of Operations のいくつかの異なるパターンについて説明しています。

于 2013-09-09T02:16:25.623 に答える