FAQ： 同時実行性

MongoDB ではどのようなタイプのロックを使用しますか。

MongoDBは、グローバル、データベース、またはコレクション レベルで操作をロックできる複数粒度ロック [1] を使用し、個々のストレージエンジンがコレクションレベル以下（たとえば、WiredTiger 内のドキュメントレベル）で各自の同時実行制御の実装を可能にします。

MongoDB は、データベースやコレクションなどのリソースへの同時リーダー共有アクセスを許可するリーダーおよびライターのロックを使用します。

読み取り操作用の共有（S）ロックモードと書き込み操作用の排他的（X）ロックモードに加えて、意向共有（IS）モードと意向排他（IX）モードは、より細かい粒度のロックを使用してリソースを読み書きする意向を示すものです。特定の粒度でロックする場合、上位レベルはすべて意向ロックを使用してロックされます。

たとえば、コレクションを書き込み用にロックする場合（モード X を使用）、対応するデータベース ロックとグローバル ロックの両方を意向排他（IX）モードでロックする必要があります。単一のデータベースを IS モードと IX モードで同時にロックすることは可能ですが、排他（X）ロックは他のモードと共存できず、共有（S）ロックは意向共有（IS）ロックとのみ共存できます。

ロックは公平であり、読み取りと書き込みのロック要求は順番にキューに入れられます。ただし、スループットを最適化するために、1 つのロック要求が許可されると、互換性のある他のすべてのロック要求が同時に許可され、競合するロック要求が実行される前にロックが解除される可能性があります。たとえば、X ロックが解除された直後に、競合キューに次のロックが含まれている状況を考えてみましょう。

IS → IS → X → X → S → IS

厳密な先入れ先出し（FIFO）の順序では、最初の 2 つの IS モードのみが付与されます。しかし、MongoDB は実際にはすべての IS モードと S モードを付与し、それらがすべてはけると、その間に新しい IS または S リクエストがキューに入っていても、X を付与します。付与によって他のリクエストはすべてキューの先頭に移動されるため、どのリクエストにも資源飢餓が発生することはありません。

db.serverStatus() 出力および db.currentOp() 出力では、ロック モードは次のように表されます。

MongoDB のロックの粒度はどのくらいですか。

ほとんどの読み取りおよび書き込み操作で、WiredTiger はオプティミスティック同時実行制御を使用します。 WiredTiger は、グローバル、データベース、コレクション レベルで意向ロックのみを使用します。storage engineが 2 つの操作間の競合を検出すると、1 つの操作で書込み競合 (write conflict)が発生し、MongoDB はその操作を透過的に再試行します。

一部のグローバル操作（通常は複数のデータベースに関係する短時間の操作）では、依然としてグローバルな「インスタンス全体」のロックが必要です。 renameCollectionなどの他の操作では、依然として特定の状況で排他的データベース ロックが必要です。

mongod インスタンスのロック状態を確認するにはどうすればよいですか。

ロックに関するロック使用情報のレポート作成には、次のいずれかの方法を使用します。

• db.serverStatus(),

• db.currentOp(),

• mongotop,

• mongostat、や

• MongoDB Cloud ManagerまたはOps Manager は、MongoDB Enterprise Advanced で利用可能なオンプレミス ソリューションです。

具体的には、serverStatus の出力の locks ドキュメント、または current operation reporting の locks フィールドにより、mongod インスタンス内のロック タイプとロック競合の量に関するインサイトが提供されます。

db.serverStatus() 出力および db.currentOp() 出力では、ロック モードは次のように表されます。

操作を終了するには、db.killOp() を使用します。

読み取り操作または書き込み操作でロックを解除することはありますか。

状況によっては、読み取り操作と書き込み操作はロックを解除することがあります。

クエリ、更新、および削除などの読み取りや書き込み操作の実行が長時間になると、さまざまな条件下でロックを解除します。MongoDB 操作では、複数のドキュメントに影響を与える書き込み操作において、個々のドキュメントの変更間でロックを解除することもあります。

ドキュメント レベルの同時実行制御 をサポートする、WiredTiger などのストレージ エンジンの場合、グローバル レベル、データベース レベル、およびコレクション レベルで保持される意向ロックは他のリーダーやライターをブロックしないため、ストレージにアクセスするときにロックを解除する必要はありません。しかし、次のような場合に操作は定期的にロックを解除します。

• 大量のデータをメモリに保持する可能性がある長時間のストレージ トランザクションを回避するため。

• 長時間実行されている操作を強制終了できるように割り込みポイントとして機能するため。

• インデックスやコレクションの削除や作成など、コレクションへの排他的アクセスを必要とする操作を許可するため。

一般的なクライアント操作によって取得されるロックにはどのようなものがありますか。

次の表は、ドキュメントレベルのストレージエンジンのロックに使用されるいくつかの操作とロックのタイプを示します。

データベースをロックする管理コマンドはどれですか。

一部の管理コマンドは、データベースの長時間排他ロックができます。 For large clusters, consider taking the mongod instance offline so that clients are not affected. たとえば、 mongodがレプリカセットの一部である場合、メンテナンスの実行中はmongodをオフラインにして、レプリカセットの他のノードが要求を処理できるようにします。

コレクションをロックする管理コマンドはどれですか。

以下の管理操作では、コレクション レベルで排他ロックが必要です。

• create コマンドと対応する db.createCollection() および db.createView() shell メソッド。

• createIndexes コマンドと対応する db.collection.createIndex() および db.collection.createIndexes() shell メソッド。構築プロセスでは、インデックス構築の開始時と終了時にのみコレクションに対して排他ロックが保持されます。

• drop コマンドと対応する db.collection.drop() shell メソッド。

• dropIndexes コマンドと対応する db.collection.dropIndex() および db.collection.dropIndexes() shell メソッド。

• renameCollection コマンドと対応する db.collection.renameCollection() shell メソッドは、バージョンに応じて次のロックを取得します。

  • renameCollectionとdb.collection.renameCollection()の場合 : 同じデータベース内のコレクションの名前を変更する場合、その操作はソース コレクションとターゲット コレクションに対して排他（W） ロックを取得します。

  • renameCollectionのみ：ターゲット名前空間がソース コレクションとは異なるデータベースにある場合、データベース間でコレクションの名前を変更するときに、操作によってターゲット データベースで排他ロック（W）が取得され、操作が完了するまでそのデータベース上の他の操作がブロックされます。

• reIndexコマンドと対応するdb.collection.reIndex() shell メソッドは、コレクションに対して排他的ロック（W）を取得し、完了するまでコレクションに対する他の操作をブロックします。

• replSetResizeOplogコマンドはoplogコレクションに対して排他的ロック（W）を取得し、終了するまでコレクションに対する他の操作をブロックします。

MongoDB 操作によって複数のデータベースがロックされることはありますか。

以下の MongoDB 操作では、複数のデータベースに対してロックを取得して保持する場合があります。

シャーディングは同時実行性にどのように影響しますか。

シャーディングは、コレクションを複数の mongod インスタンスに分散することで同時実行性を向上させ、シャード サーバー（具体的には mongos プロセス）を下流の mongod インスタンスと同時に実行できるようにします。

シャーディングされたクラスターでは、ロックはクラスター全体ではなく、個々のシャードに適用されます。つまり、各 mongod インスタンスは、シャーディングされたクラスター内では他のインスタンスから独立しており、各自がロックを使用します。1 つの mongod インスタンスに対する操作は、他のインスタンスに対する操作をブロックしません。

同時実行性はレプリカセット プライマリにどのような影響を与えますか。

レプリカセットを使用すると、MongoDB がプライマリのコレクションに書き込むとき、MongoDB はプライマリの oplog（local データベースの特別なコレクション）にも書き込みます。そのため、MongoDB はコレクションのデータベースと local データベースの両方をロックする必要があります。mongodは、データベースの整合性を維持し、レプリケーションがある場合でも、書き込み操作がすべて完了するか、または何もなかったようにするために、両方のデータベースを同時にロックする必要があります。

レプリカセットに書き込む場合、ロックのスコープはプライマリに適用されます。

同時並行性はセカンダリにどのような影響を与えますか。

レプリケーションでは、MongoDB はセカンダリに対して書き込みを順次に適用することはありません。セカンダリは oplog エントリをバッチで収集し、それらのバッチを並列に適用します。書き込みは、oplog に現れる順序で適用されます。

セカンダリがレプリケーションを実行中の場合、 セカンダリを対象とする読み取りはWiredTigerのスナップショットからデータを読み取ります。 これにより、データの一貫したビューが保証されしながら、レプリケーションと同時に読み取りを実行できるようになります。

MongoDB はトランザクションをサポートしていますか。

単一のドキュメントには、リレーショナルスキーマの別々の親子テーブルにまたがってモデル化される関連データを含めることができるため、MongoDB のアトミックな単一ドキュメント操作は、大半のアプリケーションのデータの完全性要件を満たすトランザクション セマンティクスをすでに提供しています。複数のサブドキュメントや配列の要素の更新を含め、1 つの操作で 1 つ以上のフィールドに書き込むことができます。MongoDB が提供する保証により、ドキュメントが更新されるときに完全な分離が保証されます。エラーが発生すると、操作がロールバックされ、クライアントはドキュメントの整合性のあるビューを受け取ることができます。

MongoDB は（単一または複数のコレクション内の）複数のドキュメントへの読み取りと書込みにアトミック性を必要とする状況で、レプリカセットやシャーディングされたクラスターでのトランザクションを含む分散トランザクションをサポートします。

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

MongoDB はどのような分離保証を提供しますか。

読み取り保証（read concern）に応じて、クライアントは書き込みが永続的になる前にその書き込みの結果を確認できます。読み取られたデータをロールバックできるかどうかを制御するには、クライアントは readConcern オプションを使用できます。

ロックフリーの読み取り操作とは何ですか。

ロックフリーの読み取り操作はただちに実行されます。この操作は、別の操作がコレクションに対して排他（X）書込みロック（write lock）を持っている場合、ブロックされません。

MongoDB 5.0 以降では、別の操作がコレクションに対して排他的（X）書込みロック（write lock）を保持している場合、次の読み取り操作はブロックされません。

• find

• count

• distinct

• aggregate

• mapReduce

• listCollections

• listIndexes

コレクションに書き込む場合、mapReduce と aggregate は、意向排他（IX）ロックを保持します。そのため、コレクションに対して排他 X ロックがすでに保持されている場合、 mapReduce および aggregate 書き込み操作はブロックされます。

詳細については、次を参照してください。

• 読み取りの分離、整合性、最新性

• 原子性とトランザクション

• 読み取り保証（read concern）