AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu

長時間実行スナップショット クエリの実行

スナップショット クエリを使用すると、直近の特定の点に表示されるデータを読み取ることができます。

MongoDB 5.0以降では、読み取り保証(read concern "snapshot"を使用してセカンダリノード上のデータをクエリできます。 この機能により、アプリケーションの読み取りの柔軟性と回復力が高まります。 データの静的コピーを作成し、別のシステムに移動し、これらの長時間実行クエリを運用ワークロードの中断から手動で分離する必要はありません。 代わりに、実行中のトランザクション データベースに対して長時間実行クエリを実行しながら、一貫した状態のデータから読み取りを行うことができます。

セカンダリ ノードで読み取り保証"snapshot"を使用しても、アプリケーションの書込みワークロードには影響しません。 アプリケーション読み取りのみ、実行時間が長いクエリをセカンダリに分離することでメリットが得られます。

以下の場合は、スナップショット クエリを使用します。

  • 関連する複数のクエリを実行し、各クエリが同じ時点からデータを読み込むようにします。

  • 過去のある点のデータが一貫した状態で読み取られていることを確認してください。

MongoDB がデフォルトの"local"読み取り保証 (read concern) を使用して長時間実行クエリを実行する場合、クエリ結果にはクエリと同時に発生した書込み (write) によるデータが含まれる場合があります。 その結果、クエリは予期しない結果や一貫性のない結果を返すことがあります。

このシナリオを回避するには、セッションを作成し、読み取り保証(read concern "snapshot"を指定します。 読み取り保証 (read concern) "snapshot"を使用すると、MongoDB はスナップショット分離でクエリを実行します。つまり、クエリは直近の特定の点に表示されたデータを読み取ります。

このページの例は、スナップショット クエリを使用して次の方法を実行する方法を示しています。

読み取り保証"snapshot"を使用すると、セッション内で複数の関連クエリを実行し、各クエリが同じ時点からデータを読み取ることができます。

犬の管理では、各タイプのコレクションを含むpetsデータベースがあります。 petsデータベースには以下のコレクションがあります。

  • cats

  • dogs

各コレクション内の各ドキュメントには、犬が保護可能かどうかを示すadoptableフィールドが含まれています。 たとえば、 catsコレクション内のドキュメントは次のようになります。

{
"name": "Whiskers",
"color": "white",
"age": 10,
"adoptable": true
}

クエリを実行して、すべてのコレクションにわたる受け入れる可能性のある犬の合計数を確認したいとします。 データの一貫したビューを提供するには、各コレクションから返されるデータが単一の時点のものであることを確認する必要があります。

この目的を実現するには、セッション内で読み取り保証(read concern) "snapshot"を使用します。

上記の一連のコマンドでは、次のようになります。

  • MongoDB 配置への接続を確立するには、 MongoClient()を使用します。

  • pets データベースに切り替えます。

  • セッションを確立します。 コマンドはsnapshot=Trueを指定しているため、セッションは読み取り保証"snapshot"を使用します。

  • petsデータベース内の各コレクションに対してこれらのアクションを実行します。

    • $matchを使用して、 adoptableフィールドがTrueであるドキュメントをフィルタリングします。

    • フィルタリングされたドキュメントの数を返すには、 $countを使用します。

    • データベースからのカウントでadoptablePetsCount変数を増加させます。

  • adoptablePetsCount変数を出力します。

セッション内のすべてのクエリは、同じ時点に表示されたデータを読み取ります。 その結果、最終カウントには、データの一貫したスナップショットが反映されます。

注意

セッションが WiredTiger 履歴保持期間(デフォルトでは300秒)を超えて続く場合、クエリはSnapshotTooOldエラーでエラーします。 スナップショット保持を構成し、長時間実行クエリを有効にする方法については、「スナップショット保持の構成 」を参照してください。

読み取り保証"snapshot"を使用すると、クエリが直近の特定の点に表示されるデータが読み取られるようになります。

オンライン ショップには、店舗で販売されている各アイテムのデータが含まれるsalesコレクションがあります。 たとえば、 salesコレクション内のドキュメントは次のようになります。

{
"shoeType": "boot",
"price": 30,
"saleDate": ISODate("2022-02-02T06:01:17.171Z")
}

毎日の午前 0 時、クエリが実行され、その日に販売された服の数を確認できます。 日次売上クエリは次のようになります。

上記のクエリでは、

  • $match$exprを使用して、 saleDateフィールドにフィルターを指定します。

  • $gt演算子と$dateSubtract式を使用して、クエリが実行される 1 日前よりも前にsaleDateが より大きいドキュメントを返します。

  • 一致するドキュメントの数を返すには、 $countを使用します。 カウントはtotalDailySales変数に保存されます。

  • 読み取り保証(read concern "snapshot"を指定して、クエリが単一の時点から読み取られるようにします。

salesコレクションはかなり大きいため、このクエリの実行には数分かかる場合があります。 この店はオンラインであるため、いつでも売上が発生する可能性があります。

たとえば、次の場合について考えてみましょう。

  • クエリは、午前12 : 00に実行を開始します。

  • あるカスタマーが、 12 : 02に 3 ペアのキーを購入します。

  • クエリの実行は、 12 : 04に実行を終了します。

クエリが読み取り保証 (read concern) "snapshot"を使用していない場合、クエリが開始してから終了するまでの間に発生する売上は、レポートが発行される日に発生していなくても、クエリ数に含めることができます。 そのため、一部の売上が 2 回カウントされるなど、不正確なレポートが表示される可能性があります。

読み取り保証 (read concern) "snapshot"を指定すると、クエリは、クエリの実行が開始される直前の時点でデータベースに存在していたデータのみを返します。

注意

クエリに WiredTiger 履歴保持期間(デフォルトでは300秒)よりも長い時間がかかる場合、クエリはSnapshotTooOldエラーでエラーになります。 スナップショット保持を構成し、長時間実行クエリを有効にする方法については、「スナップショット保持の構成 」を参照してください。

デフォルトでは、WiredTiger のストレージエンジンは履歴を300秒保持します。 snapshot=trueとのセッションは、セッションの最初の操作から最後の操作まで合計で300秒にわたって使用できます。 セッションを長時間使用すると、セッションは失敗し、 SnapshotTooOldエラーが発生します。 同様に、読み取り保証(read concern "snapshot"を使用してデータをクエリし、クエリが300秒を超えると、クエリは失敗します。

クエリまたはセッションが300秒を超えて実行される場合は、スナップショット保持期間を増やすことを検討してください。 保持期間を延長するには、 minSnapshotHistoryWindowInSecondsパラメータを変更します。

たとえば、次のコマンドは、 minSnapshotHistoryWindowInSecondsの値を600秒に設定します。

db.adminCommand( { setParameter: 1, minSnapshotHistoryWindowInSeconds: 600 } )

minSnapshotHistoryWindowInSeconds の値を増やすと、サーバーは指定された時間枠内で古い変更値の履歴を維持する必要があるため、ディスク使用量が増加します。使用されるディスク容量はワークロードによって異なり、ワークロードのボリュームが大きいほど、より多くのディスク容量が必要になります。