読み取り保証（read concern）

項目一覧

読み取り保証レベル

readConcern サポート
Considerations

readConcern オプションを使用すると、レプリカセットおよびシャーディングされたクラスターから読み取られたデータの一貫性と分離プロパティを制御できます。

書き込み保証と読み取り保証を効果的に使用することで、整合性保証のレベルと可用性保証のレベルを必要に応じて調整できます。たとえば、待ち時間を長くして整合性保証を強化したり、整合性要件を緩和して可用性を高めたりできます。

レプリカセットとシャーディングされたクラスターは、グローバルなデフォルトの読み取り保証 (read concern) の設定をサポートしています。読み取り保証 (read concern) を明示的に指定しない操作は、グローバルデフォルトの読み取り保証 (read concern) 設定を継承します。詳細については、setDefaultRWConcern を参照してください。

読み取り保証レベル

次の読み取り保証レベルが利用可能です。

`level`	説明
`"local"`	クエリはインスタンスからデータを返しますが、そのデータがレプリカセットのノードの大半に書き込まれた（つまり、ロールバックされる可能性がある）という保証はありません。プライマリとセカンダリに対する読み取りのデフォルト。可用性: 読み取り保証 `"local"` は、因果整合性を持つセッションやトランザクションの有無にかかわらず使用できます。詳細については、`"local"` に関する参考ページを参照してください。
`"available"`	クエリはインスタンスからデータを返しますが、そのデータがレプリカセットのノードの大半に書き込まれた（つまり、ロールバックされる可能性がある）という保証はありません。可用性: 読み取り保証 `"available"` は、因果整合性を持つセッションおよびトランザクションでは使用できません。シャーディングされたクラスターでは、さまざまな読み取り保証の中で `"available"` 読み取り保証で読み取りのレイテンシーが最低となります。ただし、シャーディングされたコレクションから読み取るときに `"available"` 読み取り保証によって孤立したドキュメントが返される可能性があるため、一貫性が犠牲になります。シャーディングされたコレクションから読み取るときに孤立したドキュメントが返されるリスクを回避するには、読み取り保証 `"local"` などの別の読み取り保証を使用します。詳細については、`"available"` に関する参考ページを参照してください。
`"majority"`	このクエリは、レプリカセットのノードの過半数が承認したデータをします。読み取り操作によって返されたドキュメントは、失敗した場合でも耐久性があります。読み取り保証「majority」を満たすために、レプリカセットのノードは、過半数がコミットしたポイントでデータのメモリ内ビューからデータを返します。そのため、読み取り保証 `"majority"` のパフォーマンスコストは、他の読み取り保証と同等です。可用性: 読み取り保証 `"majority"` は、因果関係が一貫したセッションやトランザクションの有無にかかわらず使用できます。要件: `"majority"` の読み取り保証レベルを使用するには、レプリカセットで WiredTiger ストレージエンジンを使用する必要があります。マルチドキュメントトランザクションの操作の場合、読み取り保証 `"majority"` は、トランザクションが書込み保証 "majority" でコミットされた場合にのみ保証を提供します。それ以外の場合、`"majority"` 読み取り保証では、トランザクションで読み取られるデータについて保証されません。詳細については、`"majority"` に関する参考ページを参照してください。
`"linearizable"`	クエリは、読み取り操作の開始前に完了した、過半数が承認した成功した書き込みをすべて反映したデータを返します。クエリは、同時に実行されている書き込みが大多数のレプリカセットノードに反映されるのを待ってから、結果を返す場合があります。レプリカセットノードの大部分がクラッシュして読み取り操作後に再起動した場合、 `writeConcernMajorityJournalDefault` がデフォルト状態の `true` に設定されていれば、読み取り操作によって返されるドキュメントは耐久計があります。 `writeConcernMajorityJournalDefault` を `false` に設定すると、MongoDB は書き込みを確認する前に、オンディスクジャーナルに `w: "majority"` 書き込みが書き込まれるのを待たなくなります。そのため、`"majority"` 特定のレプリカセット内の大多数のノードでの一時的な損失（例: クラッシュおよび再起動）が発生したイベントにロールバックされる可能性があります。可用性: 読み取り保証`"linearizable"`は、因果整合性を持つセッションおよびトランザクションでは使用できません。線形化可能な読み取り保証は `primary` の読み取り操作にのみ指定できます。 `$out` または `$merge` ステージを、読み取り保証 `"linearizable"` と組み合わせて使用することはできません。つまり、`"linearizable"` 読み取り保証を `db.collection.aggregate()` に対して指定した場合は、どちらのステージもパイプライン内に含めることができません。要件: 線形化可能な読み取り保証は、読み取り操作で 1 つのドキュメントを一意に識別するクエリフィルターが指定されている場合にのみ適用されます。さらに、次の条件のいずれも満たされない場合、線形化可能な読み取り保証は一貫性のあるスナップショットから読み取れず、フィルターに一致するドキュメントが返されない可能性があります。クエリは、クエリの検索キーとして不変のフィールドを使用します。たとえば、 `_id`フィールドで検索したり、 `$natural`を使用したりします。同時更新によってクエリの検索キーが変更されることはありません。検索キーにはユニークインデックスがあり、クエリはそのインデックスを使用します。前述の基準のいずれかが満たされた場合、クエリは一貫性のあるスナップショットから読み取り、一致するドキュメントを1つ返します。データを含むノードの大半が利用できない場合に備えて、必ず線形化可能な読み取り条件で `maxTimeMS` を使用してください。`maxTimeMS` を指定すると、操作が無期限に停止することはなく、代わりに読み取りの問題が満たされない場合に操作がエラーを返すようになります。詳細については、`"linearizable"` に関する参考ページを参照してください。
`"snapshot"`	読み取り保証 `"snapshot"` を指定したクエリでは、直近の特定の点のシャード全体に表示れる、過半数のコミット済みデータが返されます。読み取り保証 `"snapshot"` は、トランザクションが書込み保証 `"majority"` でコミットされた場合にのみ保証を提供します。 If a transaction is not part of a causally consistent session, upon transaction commit with write concern `"majority"`, the transaction operations are guaranteed to have read from a snapshot of majority-committed data. If a transaction is part of a causally consistent session, upon transaction commit with write concern `"majority"`, the transaction operations are guaranteed to have read from a snapshot of majority-committed data that provides causal consistency with the operation immediately preceding the transaction start. 可用性: 読み取り保証 `"snapshot"` は、以下で使用できます。読み取り保証がトランザクションレベルで設定されたマルチドキュメントトランザクション内のすべての読み取り操作。マルチドキュメントトランザクション以外の以下のメソッド。 `find` `aggregate` `distinct` （シャーディングされていないコレクションの場合） `"snapshot"` を禁止しているその他すべての操作。

読み取り保証のレベルを問わず、ノード上の最新データにシステム内のデータの最新バージョンが反映されていない場合があります。

各読み取り保証レベルの詳細については、以下を参照してください。

`readConcern` サポート

読み取り保証のオプション

マルチドキュメントトランザクションではない操作では、読み取り保証をサポートするコマンドとメソッドのオプションとして readConcern レベルを指定できます。

readConcern: { level: <level> }

mongosh メソッド db.collection.find() の読み取り保証 (read concern) レベルを指定するには、cursor.readConcern() メソッドを使用します。

db.collection.find().readConcern(<level>)

トランザクションと使用可能な読み取り保証

マルチドキュメントトランザクションの場合、読み取り保証は、トランザクションレベルで設定します。個々の操作レベルではありません。トランザクションの操作には、トランザクションレベルの読み取り保証が使用されます。コレクションおよびデータベースレベルで設定された読み取り保証は、トランザクション内では無視されます。トランザクションレベルの読み取り保証が明示的に指定されている場合、トランザクション内ではクライアントレベルの読み取り保証も無視されます。

重要

個々の操作に対して読み取り保証を明示的に設定しないでください。トランザクションの読み取り保証を設定するには、「読み取り保証/書き込み保証/読み込み設定」を参照してください。

読み取り保証は、トランザクションの開始時に設定できます。

マルチドキュメントトランザクションの場合、次の読み取り保証レベルが使用できます。
マルチドキュメントトランザクションの一部である書き込みコマンドは、トランザクションレベルの読み取り保証をサポートできます。
トランザクション内でコレクションとインデックスを作成できます。コレクションまたはインデックスを明示的に作成する場合、トランザクションは読み取り保証 "local" を使用する必要があります。コレクションを暗黙的に作成する場合は、トランザクションに使用できる任意の読み取り保証を使用できます。

トランザクションの開始時に指定されていない場合、トランザクションはセッションレベルの読み取り保証を使用するか、設定されていない場合はクライアントレベルの読み取り保証を使用します。

詳細については、「トランザクション読み取り保証」を参照してください。

因果整合性セッションと使用可能な読み取り保証

因果整合性セッションの操作では、 "local" レベル、"majority" レベル、および"snapshot" レベルが使用できます。ただし、因果整合性を保証するには、"majority" を使用する必要があります。詳細については、「因果整合性」を参照してください。

読み取り保証をサポートする操作

以下の操作が、読み取り保証をサポートします。

重要

トランザクションの操作に読み取り保証を設定するには、個々の操作レベルではなくトランザクションレベルで読み取り保証を設定します。トランザクションにおける個々の操作に対して読み取り保証を明示的に設定しないでください。詳細については、「トランザクションと読み取り保証」を参照してください。

コマンド/メソッド	`"local"`	`"available"`	`"majority"`	`"snapshot"` [3]	`"linearizable"`
`count`	✓	✓	✓		✓
`distinct`	✓	✓	✓	✓ [2]	✓
`find`	✓	✓	✓	✓	✓
`db.collection.find()` via `cursor.readConcern()`	✓	✓	✓	✓	✓
`getMore`	✓				✓
`aggregate` `db.collection.aggregate()`	✓	✓	✓	✓	✓ [3]
`Session.startTransaction()`	✓		✓	✓

[1]	`$out` または `$merge` ステージを、読み取り保証 `"linearizable"` と組み合わせて使用することはできません。つまり、`"linearizable"` 読み取り保証を `db.collection.aggregate()` に対して指定した場合は、どちらのステージもパイプライン内に含めることができません。

[2]	読み取り保証 `"snapshot"` は、特定の読み取り操作およびマルチドキュメントトランザクションに対してのみ使用できます。トランザクションでは、シャーディングされたコレクションで `distinct` コマンドやそのヘルパーを使用することはできません。

マルチドキュメントトランザクションの一部である場合は、次の書き込み操作でも読み取り保証を受け付けることができます。

重要

トランザクションの操作に読み取り保証を設定するには、個々の操作レベルではなくトランザクションレベルで読み取り保証を設定します。

コマンド	`"local"`	`"snapshot"` [3]
`delete` `db.collection.deleteOne()` `db.collection.deleteMany()` `db.collection.remove()`	✓	✓
`findAndModify` `db.collection.findAndModify()` `db.collection.findOneAndDelete()` `db.collection.findOneAndReplace()` `db.collection.findOneAndUpdate()`	✓	✓
`insert` `db.collection.insertOne()` `db.collection.insertMany()`	✓	✓
`update` `db.collection.updateOne()` `db.collection.updateMany()` `db.collection.replaceOne()`	✓	✓
`create` `db.createCollection()` (Requires fCV 4.4 or greater)	✓
`createIndexes` `db.collection.createIndex()` `db.collection.createIndexes()` (Requires fCV 4.4 or greater)	✓

[3]	（ 1、2 ）読み取り保証 `"snapshot"` は、特定の読み取り操作およびマルチドキュメントトランザクションでのみ使用できます。トランザクションの場合は、トランザクションレベルで読み取り保証を設定します。`"snapshot"` をサポートするトランザクション操作は、トランザクションで使用可能な CRUD 操作に対応します。詳細については、「トランザクションと読み取り保証」を参照してください。

データベースで読み取り保証 (read`local` concern) はサポートされていません

ローカルデータベースは読み取り保証をサポートしていません。MongoDB は、ローカルデータベース内のコレクションに対する操作に対して構成された読み取り保証を暗黙的に無視します。

Considerations

自分の書込みを読む

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

リアルタイム注文

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

パフォーマンスの比較

"majority" とは異なり、"linearizable" 読み取り保証は、読み取り操作が { w: "majority" } 書込み保証で書き込みを確認できるプライマリから読み取られていることをセカンダリノードに確認します。[4] そのため、線形化可能な読み取り保証による読み取りは、"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
} )

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

読み取り操作および `afterClusterTime`

MongoDB には非公式のコンシステントセッションのサポートが含まれています。非公式のコンシステントセッションに関連付けられた読み取り操作の場合、MongoDB は、非公式のコンシステントセッションに関連付けられた操作のドライバーによって自動的に設定される afterClusterTime 読み取り保証 (read concern) オプションをサポートしています。

重要

読み取り操作のために手動で afterClusterTime を設定しないでください。MongoDB ドライバーは、因果整合性のあるセッションに関連付けられた操作に対して、この値を自動的に設定します。ただし、別のクライアントセッションの操作と一致させるなど、セッションの optime やクラスター時間を繰り上げることはできます。例については、「例」を参照してください。

注意

afterClusterTimeと組み合わせてatClusterTimeを指定することはできません。読み取り保証 "snapshot" で atClusterTime を使用するには、因果整合性のあるセッションを無効にする必要があります。

T の afterClusterTime 値がある読み取りリクエストを満たすには、mongod は oplog が時間 T に達した後にリクエストを実行する必要があります。oplog が時間 T に達していない場合、mongod はリクエストを処理するまで待機する必要があります。

指定された afterClusterTime を使用した読み取り操作では、読み取り保証 (read concern) レベル要件と指定された afterClusterTime 要件の両方を満たすデータが返されます。

因果整合性のあるセッションに関連付けられていない読み取り操作の場合、afterClusterTime は設定されません。