ApsaraDB for MongoDB:トランザクションと読み取り/書き込み懸念

基本情報

MongoDB のトランザクション API はリレーショナルデータベースのものと似ているため、学習コストは最小限です。

次の例は、startTransaction/abortTransaction/commitTransaction API を使用した完全なトランザクションに加えて、session および readConcern/writeConcern の設定を示しています。

// コレクションを作成します。
db.getSiblingDB("mydb1").foo.insertOne(
    {abc: 0},
    { writeConcern: { w: "majority", wtimeout: 2000 } }
)
db.getSiblingDB("mydb2").bar.insertOne(
   {xyz: 0},
   { writeConcern: { w: "majority", wtimeout: 2000 } }
)
// セッションを開始します。
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
coll1 = session.getDatabase("mydb1").foo;
coll2 = session.getDatabase("mydb2").bar;
// トランザクションを開始します。
session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
// トランザクション内で操作を実行します。
try {
   coll1.insertOne( { abc: 1 } );
   coll2.insertOne( { xyz: 999 } );
} catch (error) {
   // エラーが発生した場合はトランザクションをアボートします。
   session.abortTransaction();
   throw error;
}
// トランザクションをコミットします。
session.commitTransaction();
session.endSession();

トランザクションの主な動作：

• 各トランザクションはセッションに関連付ける必要があります。1 つのセッションで同時にアクティブにできるトランザクションは 1 つだけです。セッションを終了すると、アクティブなトランザクションはロールバックされます。

• 分散トランザクションは、複数のドキュメント、コレクション、データベースにまたがることができます。

• トランザクションは自身の未コミットの書き込みを読み取れますが、これらの書き込みはトランザクション外の操作からは参照できません。

• 書き込みは、トランザクションがコミットされるまでセカンダリノードにレプリケートされません。コミット後、書き込みはすべてのセカンダリノードに自動的に適用されます。

• トランザクションは変更するドキュメントをロックし、完了するまで他の操作をブロックします。5 ミリ秒 (デフォルト) 以内にロックを取得できない場合、トランザクションは書き込みコンフリクトによりアボートします。このタイムアウトは、maxTransactionLockRequestTimeoutMillis パラメータで制御されます。

• トランザクションは、ネットワークの一時的な中断などの一時的なエラーが発生した場合に自動的に再試行されます。この再試行はクライアントからは透過的です。

• 60 秒を超えて実行されるトランザクションは強制的にアボートされます。このタイムアウトは、transactionLifetimeLimitSeconds パラメータで制御されます。

制限

• 分散トランザクション内で新しいコレクションまたはインデックスを作成することはできません。

• トランザクションではキャップ付きコレクションに書き込めません。

• トランザクションでは、snapshot の読み取り懸念を使用してキャップ付きコレクションから読み取ることはできません。この制限は MongoDB 5.0 以降に適用されます。

• トランザクションでは、config、admin、local の各データベース内のコレクションに対して読み取りまたは書き込みを実行できません。

• トランザクションでは、system.* 形式のコレクションなど、システムコレクションに書き込めません。

• トランザクションは explain をサポートしていません。

• トランザクション内で getMore を使用して、トランザクション外で作成されたカーソルを読み取ることはできません。同様に、トランザクション外で getMore を使用して、トランザクション内で作成されたカーソルを読み取ることもできません。

• トランザクションの最初の操作を、killCursors や hello などのコマンドにすることはできません。

• トランザクション内では非 CRUD コマンドを実行できません。例として、listCollections、listIndexes、createUser、getParameter、count などがあります。

• 分散トランザクションでは、シャード上の writeConcernMajorityJournalDefault パラメータを false に設定できません。

• 分散トランザクションは、アービター を含むシャードをサポートしていません。

ベストプラクティス

カーネル バグのリスク

長時間実行または過大なトランザクションは WiredTiger キャッシュに大きな負荷をかけます。最も古い未コミット トランザクションの開始時点から、WiredTiger はその後のすべての書き込みに対するデータと状態を維持する必要があります。アクティブなトランザクションは同一のスナップショットを共有するため、トランザクションの存続期間中は新しい書き込みがキャッシュに蓄積され続け、トランザクションがコミットまたはアボートされるまでエビクトできません。キャッシュが過負荷 (使用量およびダーティ使用量がしきい値を超過) になると、データベースの断続的な停止、レイテンシの増加、CPU 使用率 100%、およびデッドロックが発生する可能性があります。関連する問題：SERVER-50365 および SERVER-51281。

ApsaraDB for MongoDB は、トランザクションを多用するアプリケーションには、MongoDB 5.0 以降へのアップグレードを推奨します。

基本情報

読み取り懸念 (Read Concern) は、次のレベルで整合性と分離を制御します：

• "local"：プライマリまたはセカンダリノードから読み取る際のデフォルトです。ローカルノードから読み取り、後でロールバックされる可能性があるデータを返す場合があります。

• "available"：シャードクラスターのセカンダリから読み取る際のデフォルトです。後でロールバックされる可能性があるデータを返す場合があります。シャードバージョンをチェックしないため、孤立ドキュメントを返す可能性があります。アクセス レイテンシが最小です。

• "majority"：レプリカセット メンバーの過半数によって確認されたデータを読み取ります。このデータはロールバックされません。

• "linearizable"：最も厳格なレベルです。先行するすべての書き込みがノードの過半数によって確認されるまで待機します。パフォーマンスは最も低く、プライマリでのみ使用できます。

• "snapshot"：ノードの過半数によって確認されたデータのスナップショットから読み取ります。atClusterTime を使用して特定の時点に関連付けることができます。

使用上の注意：

• 単一の mongod ノード上の最新データが、読み取り懸念レベルにかかわらず、必ずしもレプリカセットにおける最新データを表すとは限りません。

• 読み取り懸念レベルは操作ごとに指定できます。MongoDB 4.4 以降ではサーバー側のデフォルトもサポートされ、操作レベルの設定がそれを上書きします。

• local データベースから読み取る場合、読み取り懸念は無視されます。local データベース内のデータは、レベルにかかわらず読み取り可能です。

• 分散トランザクションでサポートされる読み取り懸念レベルは、"local"、"majority"、"snapshot" の 3 つのみです。

• 因果整合性のあるセッションは、読み取り懸念レベルとして "majority" を使用する必要があります。

ベストプラクティス

基本情報

書き込み懸念は次の形式を使用します。完全なリファレンスについては、書き込み懸念 (Write Concern) をご参照ください。

{ w: <value>, j: <boolean>, wtimeout: <number> }

• 書き込み懸念は、次のレベルでデータ永続性の保証を制御します：

  • {w: 0}：確認応答なし。完了を確認しないため、データ損失が発生する可能性があります。

  • {w: 1}：メモリ上の書き込みを確認します。MongoDB 5.0 より前のデフォルトです。データはまだディスクに永続化されていないため、データ損失が発生する可能性があります。

  • {j: true}：ジャーナルの確認応答。永続ストレージ上の先行書き込みログ (WAL) に書き込みがフラッシュされたことを確認します。書き込みは失われません。

  • { w: "majority" }：マジョリティの確認応答。MongoDB 5.0 以降のデフォルトです。書き込みがノードの過半数にレプリケートされるまで待機します。データはロールバックされません。

  • レプリカの確認応答：指定した数のノードへのレプリケーションを待ってから確認応答します。

  • カスタムの確認応答：settings.getLastErrorModes パラメータを使用して、タグを用いた他のカスタム確認応答方法を指定できます。

使用上の注意：

• 書き込み懸念は、任意の書き込み操作またはトランザクションに指定できます。省略した場合はデフォルトが使用されます。

  説明

  MongoDB 5.0 以降では、標準の 3 メンバー構成のレプリカセットにおけるグローバルなデフォルト書き込み懸念が {w:1} から {w:"majority"} に変更されました。アップグレード後にパフォーマンスが低下する可能性があります。

• レプリカセット内の隠しメンバー、遅延メンバー、および priority が 0 のその他の投票ノードは、いずれも "majority" の確認応答にカウントされます。

• 書き込み懸念レベルは操作ごとに指定できます。MongoDB 4.4 以降ではサーバー側のデフォルトもサポートされ、操作レベルの設定がそれを上書きします。

• local データベースに書き込む場合、指定した書き込み懸念は無視されます。

• 因果整合性のあるセッションは、書き込み懸念として "majority" を使用する必要があります。

ベストプラクティス