/ /

読み取り保証（read concern） `"linearizable"`

"linearizable"

クエリは、読み取り操作の開始前に完了した、過半数が承認した成功した書き込みをすべて反映したデータを返します。クエリは、同時に実行されている書き込みが大多数のレプリカセットノードに反映されるのを待ってから、結果を返す場合があります。

レプリカセットノードの大部分がクラッシュして読み取り操作後に再起動した場合、 writeConcernMajorityJournalDefault がデフォルト状態の true に設定されていれば、読み取り操作によって返されるドキュメントは耐久計があります。

writeConcernMajorityJournalDefault を false に設定すると、MongoDB は書き込みを確認する前に、オンディスクジャーナルに w: "majority" 書き込みが書き込まれるのを待たなくなります。そのため、"majority" 特定のレプリカセット内の大多数のノードでの一時的な損失（例: クラッシュおよび再起動）が発生したイベントにロールバックされる可能性があります。

線形化可能な読み取り保証は primary の読み取り操作にのみ指定できます。

Tip

データを含むノードの大半が利用できない場合に備えて、必ず線形化可能な読み取り条件で maxTimeMS を使用してください。maxTimeMS を指定すると、操作が無期限に停止することはなく、代わりに読み取りの問題が満たされない場合に操作がエラーを返すようになります。

要件

線形化可能な読み取り保証は、読み取り操作で 1 つのドキュメントを一意に識別するクエリフィルターが指定されている場合にのみ適用されます。さらに、次の条件のいずれも満たされない場合、線形化可能な読み取り保証は一貫性のあるスナップショットから読み取れず、フィルターに一致するドキュメントが返されない可能性があります。

クエリは、クエリの検索キーとして不変のフィールドを使用します。たとえば、_id フィールドで検索したり、$natural を使用したりします。
同時更新によってクエリの検索キーが変更されることはありません。
検索キーにはユニークインデックスがあり、クエリはそのインデックスを使用します。

上記の基準のいずれかが満たされた場合、クエリは一貫性のあるスナップショットから読み取り、一致するドキュメントを 1 つ返します。

因果整合性セッション

Read concern "linearizable" is unavailable for use with causally consistent sessions.

集計制限

You cannot use the $out or the $merge stage in conjunction with read concern "linearizable". That is, if you specify "linearizable" read concern for db.collection.aggregate(), you cannot include either stages in the pipeline.

リアルタイム注文

Combined with "majority" write concern, "linearizable" read concern enables multiple threads to perform reads and writes on a single document as if a single thread performed these operations in real time; that is, the corresponding schedule for these reads and writes is considered linearizable.

自分の書込みを読む

書き込みリクエスト確認をする場合は、非公式のコンシステントセッションを使用して自分の書き込みを読み取ることができます。

パフォーマンスの比較

"majority""linearizable"とは異なり、読み取り保証 (read concern)は、読み取り操作が{ w: "majority" } 書込み保証 (write concern)で書込みを確認できるプライマリから読み取られていることをセカンダリノードに確認します。 []1 そのため、線形化可能な読み取り保証(read concern)による読み取りは、"majority" または"local" 読み取り保証による読み取りよりも大幅に遅くなる可能性があります。

以下に例を挙げます。

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )

[1]

状況によっては、 replica set内の 2 つのノードが一時的に自分たちがプライマリであると認識することがありますが、最大でそのうちの 1 つが{ w: "majority" }書き込み懸念で書き込みを完了できます。 { w: "majority" }書き込みを完了できるノードは現在のプライマリであり、もう一方のノードは、通常はネットワークパーティションが原因で降格をまだ認識していない以前のプライマリです。これが発生すると、以前のプライマリに接続するクライアントは、読み取り設定primaryを要求したにもかかわらず、古いデータを検出する可能性があり、以前のプライマリへの新しい書き込みは最終的にロールバックされます。

戻る

"過半数"

「スナップショット」

読み取り保証（read concern） "linearizable"