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

要件

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

• クエリは、クエリの検索キーとして不変のフィールドを使用します。例、 _idフィールドを検索するか、 $naturalを使用して を検索します。

• 同時更新によってクエリの検索キーが変更されることはありません。

• 検索キーにはユニークインデックスがあり、クエリはそのインデックスを使用します。

前述の条件のいずれかが満たされた場合、クエリはコンシステント スナップショットから読み取り、一致する 1 つのドキュメントを返します。

因果整合性セッション

読み取り保証 "linearizable"は、因果整合性のあるセッションでは 使用できません 。

集計制限

$outまたは$mergeステージは、読み取り保証（read concern "linearizable"と組み合わせて使用できません。 "linearizable"db.collection.aggregate()そのため、 に対して の読み取り保証を指定した場合、いずれのステージもパイプラインに含めることはできません。

リアルタイム注文

"majority"書込み保証と組み合わせると、 "linearizable"読み取り保証により、複数のスレッドが単一のドキュメントに対して読み取りと書込みを、単一のスレッドがこれらの操作をあたかもリアルタイムであるかのように実行できるようになります。つまり、これらの読み取りと書き込みの対応するスケジュールは線形化可能であると見なされます。

自分の書込みを読む

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

パフォーマンスの比較

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

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

以下に例を挙げます。

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