クエリと更新のパフォーマンス：効率的な書き込み操作の選択

MongoDBの書き込みパフォーマンスは、サーバーがデータをどれだけ速く受け入れられるかだけではありません。書き込みの形状、維持しなければならないインデックス、影響を与えるドキュメント、クライアントが待つ確認応答、そして同じレコードが一度に多くのリクエストによって集中的に処理されているかどうかが重要です。

読み取りと書き込みは異なる方法で失敗します。悪い読み取りは多くの場合、スキャンが多すぎます。悪い更新は、最初にスキャンし、次に成長するドキュメントを再書き込みし、いくつかのインデックスを更新し、レプリケーションを待ち、同じホットレコード上の他の作業をブロックする可能性があります。そのため、適切な書き込み操作を選択することが重要です。

核心的なトレードオフ：読み取り速度 vs. 書き込み耐久性

どのデータベースシステムでも、データの安全性（耐久性）を確保することと、高いトランザクション速度（スループット）を達成することの間には固有の緊張関係があります。MongoDBは、書き込みパフォーマンスに関連する2つの主要なメカニズム、書き込み保証（Write Concern） と書き込み操作自体のタイプ（例：単純な挿入と複雑な更新）を通じてこれを管理します。

書き込み保証の理解

書き込み保証は、アプリケーションが書き込み操作を成功と見なす前にMongoDBから必要とする確認応答のレベルを定義します。より厳格な書き込み保証は耐久性を高めますが、クライアントが確認を待つ必要があるため、書き込みスループットが低下することがよくあります。

書き込み保証レベル	説明	耐久性	レイテンシ/スループットへの影響
0（Fire and Forget）	確認応答不要。	最低	最高スループット、最低レイテンシ
majority	レプリカセットの過半数が書き込みを確認。	高	中程度のレイテンシ、良好なスループット
w: 'all'	すべてのレプリカセットメンバーが書き込みを確認。	最高	最高レイテンシ、最低スループット

実践例：書き込み保証の設定

ドキュメントを挿入する際、ドライバーレベルで書き込み保証を設定します：

const options = { writeConcern: { w: 'majority', wtimeout: 5000 } };

db.collection('logs').insertOne({ message: "Critical Event" }, options, (err, result) => {
  // 過半数の確認後にのみ操作が完了
});

ベストプラクティス： 大量のログや、偶発的な損失が許容される重要でないデータの場合、w: 0 を使用すると確認応答のレイテンシを削減できますが、不適切なシャットダウン時にデータ損失のリスクがあります。

クエリのパフォーマンス特性

読み取り（クエリ）は一般に耐久性に影響を与えず、純粋に検索速度に焦点を当てています。クエリのパフォーマンスは主に以下によって決まります：

1. インデックス作成： 適切なインデックス作成は最も重要な要素です。インデックスにヒットするクエリは、ほとんどの場合、コレクションスキャンよりも優れたパフォーマンスを発揮します。
2. データ取得サイズ： より少ないフィールドまたはより小さなドキュメントをフェッチすると、ネットワーク転送とメモリ使用量が高速化します。
3. クエリの複雑さ： 集約パイプライン、特に $lookup（結合）や負荷の高い $group 操作を含むものは、かなりのCPU時間とメモリを必要とし、サーバーの全体的な応答性に影響を与えます。

例：効率的なクエリ構造

クエリ述語では常にインデックス付きフィールドを優先します：

// 'status' フィールドがインデックス化されていると仮定
db.items.find({ status: 'active', lastUpdated: { $gt: yesterday } }).limit(100);

更新のパフォーマンスへの影響

更新は基本的に書き込み操作であり、挿入と同じ耐久性の考慮事項の対象となります。ただし、更新では、ドキュメントの構造やサイズを変更するかどうかに基づいて複雑さが生じます。

インプレース更新 vs. 再書き込み

MongoDBは、可能な限りインプレースで更新を実行しようとします。インプレース更新は、ディスク上のドキュメントの位置が変わらないため、はるかに高速です。これは次の場合に可能です：

1. 更新されたフィールドが、ドキュメントの現在の割り当てられたストレージスペースを超えない場合。
2. 更新操作が、内部の再構築を必要とする方法でドキュメントのサイズを変更しない場合。

更新によってドキュメントが現在の割り当てられたスペースよりも大きくなった場合、MongoDBはドキュメントをディスク上の新しい場所に再書き込みする必要があります。この再書き込み操作は、かなりのI/Oオーバーヘッドを生成し、ドキュメントをより長い期間ロックするため、特に高同時実行シナリオではパフォーマンスが大幅に低下します。

再書き込みの最小化

更新を最適化するには：

• 事前にスペースを割り当てる： 特定のフィールドが大幅に成長することがわかっている場合（例：配列への要素の追加）、最初にプレースホルダーデータでそれらのフィールドを初期化して、十分なスペースを確保することを検討します。
• 過剰な更新を避ける： ドキュメントが頻繁にサイズ変更される場合は、参照によってリンクされた別の小さなドキュメントを使用するようにスキーマを再構築することを検討します。

更新修飾子と速度

異なる更新演算子には、異なるパフォーマンスコストがかかります：

• アトミック操作（$set、$inc）： これらは一般に、インプレース更新になる場合は高速です。
• 配列操作（$push、$addToSet）： これらは、配列の成長によりドキュメントの再書き込みを繰り返し引き起こす場合、特に遅くなる可能性があります。
• ドキュメントの置き換え（replaceOne）： ドキュメント全体を置き換える（replaceOne または findAndModify で { upsert: true, multi: false } を使用してドキュメント全体を上書きする）と、再書き込みが強制され、古い場所を指す既存のインデックスが無効になり、更新が必要になる可能性があるため、慎重に使用する必要があります。

クエリと書き込みのパフォーマンスの比較

クエリは通常、耐久性のオーバーヘッドを回避するため書き込みよりも高速ですが、比較は微妙です：

操作タイプ	主なパフォーマンス要因	耐久性のオーバーヘッド	最悪のシナリオ
クエリ（読み取り）	インデックスの効率、ネットワークレイテンシ。	なし（古いレプリカから読み取る場合を除く）。	インデックスがないためのフルコレクションスキャン。
更新（書き込み）	書き込み保証の確認、インプレース vs. 再書き込み。	高い（w 設定に依存）。	クラスター全体での頻繁なドキュメント再書き込み。

実用的な洞察： アプリケーションが書き込みバウンドの場合は、まず更新フィルター、ホットドキュメント、ドキュメントの成長、およびインデックスのメンテナンスを確認します。書き込み保証は有用なレバーですが、耐久性を下げることは製品の決定であるべきであり、反射的な対応ではありません。

書き込み保証だけでなく、書き込みの形状を選択する

書き込み保証は、MongoDBがいつクライアントに書き込みが確認されたかを伝えるかを制御します。非効率な更新パターンを修正するわけではありません。2つの書き込みが同じ w: "majority" 設定を使用していても、一方が小さなフィールドに触れ、もう一方がホットドキュメント内の大きな配列を成長させ続ける場合、コストは大きく異なります。

よくある例は、常に成長する events 配列を持つユーザードキュメントです：

db.users.updateOne(
  { _id: userId },
  { $push: { events: { type: "login", at: new Date() } } }
)

これは最初は便利です。後で、ユーザードキュメントが大きくなり、ログインのたびに同じドキュメントが変更され、更新がユーザープロファイルの読み取りと競合し始めます。より良いモデルは、多くの場合、別の user_events コレクションです：

db.user_events.insertOne({
  userId,
  type: "login",
  at: new Date()
})

これで、プロファイルドキュメントは小さく保たれ、イベントの書き込みは1つの成長するドキュメントを繰り返し変更する代わりに、新しいドキュメントを追加します。最近のアクティビティ画面には { userId: 1, at: -1 } のインデックスを作成し、データが永続的でない場合はTTLインデックスで古いイベントを期限切れにすることができます。

別のパターンはカウンターです。すべてのリクエストが1つのグローバルドキュメントをインクリメントする場合、そのドキュメントは書き込みのホットスポットになります：

db.metrics.updateOne(
  { _id: "page_views" },
  { $inc: { count: 1 } },
  { upsert: true }
)

低トラフィックの場合、これは問題ありません。高トラフィックの場合は、分、テナント、ルート、またはシャードキーごとに1つのドキュメントなど、バケット化されたカウンターを使用します。読み取り時の集約を少し犠牲にして、書き込みの分散を大幅に改善します。

db.metrics.updateOne(
  { metric: "page_views", minute: "2026-05-24T10:31Z" },
  { $inc: { count: 1 } },
  { upsert: true }
)

Upsertは特別な注意が必要です。Upsertは最初に一致するドキュメントを見つける必要があります。フィルターがインデックス化されていない場合、書き込みパスは読み取りスキャンと書き込みに変わります。例えば、べき等な支払いコールバックの場合、一意のインデックスキーが必要です：

db.payment_events.createIndex({ providerEventId: 1 }, { unique: true })

db.payment_events.updateOne(
  { providerEventId },
  { $setOnInsert: { providerEventId, receivedAt: new Date(), payload } },
  { upsert: true }
)

これにより、コレクションをスキャンしたり重複レコードを作成したりすることなく、再試行を安全に行えます。また、アプリケーションに重複キーの競合を処理するクリーンな方法を提供します。

一括書き込みも別の有用なレバーです。10,000件のステータス変更をインポートする場合、更新ごとに1回のネットワークラウンドトリップは通常無駄です。bulkWrite を使用するとバッチを送信でき、順序付けられていないバッチは、ジョブに許容される場合、個々の障害後も続行できます。

db.orders.bulkWrite(
  updates.map(({ id, status }) => ({
    updateOne: {
      filter: { _id: id },
      update: { $set: { status, updatedAt: new Date() } }
    }
  })),
  { ordered: false }
)

速度を追求するために、盲目的に書き込み保証を緩めてはいけません。majority から w: 1 に変更するとレイテンシが低下する可能性がありますが、フェイルオーバー中に何が起こるかも変わります。w: 0 に変更すると、クライアントは書き込みがまったく失敗したかどうかを知ることができなくなります。これは使い捨てのテレメトリには許容されるかもしれませんが、注文、アカウント変更、またはユーザーが確認されることを期待するものには適していません。

より良い質問は、書き込みをより小さく、よりターゲットを絞り、競合を減らし、再試行しやすくできるかどうかです。1つのフィールドのみが変更された場合にドキュメント全体を置き換える代わりに、$set、$inc、$unset、$setOnInsert を使用します。頻繁に更新されるドキュメントから無制限の配列を排除します。読み取りフィルターだけでなく、更新フィルターにもインデックスを追加します。一意のキーを中心に再試行を設計して、重複リクエストが重複効果を生み出さないようにします。

自分を欺かずに書き込みパフォーマンスを測定する

空のローカルデータベースに小さなドキュメントを挿入するベンチマークは、本番環境の書き込みパフォーマンスについて多くを教えてくれません。実際の書き込みは、インデックス、レプリケーション、ジャーナリング、バックグラウンド作業、および他のクライアントと競合します。更新が多いパスをテストする場合は、実際のドキュメントのように見えるドキュメントと本番環境に一致するインデックスに対してテストを実行します。

少なくとも4つの数値を追跡します：アプリケーションのレイテンシ、MongoDBのコマンド実行時間、レプリケーションラグ、および書き込みエラーまたはタイムアウト。平均レイテンシを改善するがレプリケーションラグを生み出す変更は、単に問題をセカンダリに移しているだけかもしれません。w: 1 で高速に見える変更は、製品が実際に必要とする耐久性要件を満たしていない可能性があります。

インデックスは書き込みコストの一部です。インデックス付きフィールドを変更するすべての挿入または更新は、関連するインデックスエントリを更新する必要があります。これはインデックスが悪いという意味ではありません。未使用のインデックスが無料ではないという意味です。長年の機能開発中に作成された多くのインデックスがコレクションにある場合は、それらがまだ実際のクエリをサポートしているかどうかを確認します。未使用のインデックスを削除すると、書き込み速度が向上し、ストレージが削減される可能性がありますが、クエリログを確認し、ロールバック計画をテストした後で慎重に行ってください。

一般的なアプリケーションタスクの操作を選択する

プロフィール編集フォームの場合は、ユーザーが変更したフィールドに $set を使用します。古いクライアントコピーからユーザードキュメント全体を置き換えないでください。別のプロセスによって追加されたフィールドを誤って消去する可能性があります。

在庫予約の場合は、条件付き更新を使用して、チェックと変更を一緒に行います：

db.inventory.updateOne(
  { sku, available: { $gte: quantity } },
  { $inc: { available: -quantity, reserved: quantity } }
)

次に、matchedCount と modifiedCount を確認します。これにより、2つのクライアントが同じ利用可能在庫数を読み取り、両方が予約できると判断する競合を回避します。

ソフトデリートの場合は、$set で deletedAt フィールドを設定し、通常の読み取りがそれをフィルターで除外するようにします。アクティブなレコードを頻繁にクエリする場合は、そのフィールドを関連するインデックスに含めます。ハードデリートを一括で行う場合は、バッチで削除して、ワークロードの残りを妨げる長時間実行操作を作成しないようにします。

バックグラウンド移行の場合は、チェックポイント付きの小さなバッチを優先します。単一の大規模な updateMany は単純かもしれませんが、レプリケーションのプレッシャーを生み出し、ロールバックを困難にする可能性があります。一度に1,000または5,000のドキュメントを更新し、進捗を記録し、レプリケーションラグが上昇したときにスリープする移行は、劇的ではなく、通常はより安全です。

これらのケース全体でパターンは同じです：データベースに1つの正確なアトミック変更を実行させ、再試行を安全にし、ホットドキュメントを永久に成長させないようにします。

実践的な締めくくりの注意：パフォーマンスチューニング戦略

MongoDBで効率的な書き込み操作を選択するには、アプリケーションのニーズをデータベースの機能に合わせることが重要です。高い耐久性要件（w: 'all' の使用）は、本質的に高スループット要件（w: 0 の使用）よりも低速です。同時に、開発者は、割り当てられたストレージを超える更新によりドキュメントがディスク上で再書き込みを強制されることによるパフォーマンス低下から保護する必要があります。

データの重要度に基づいて書き込み保証を慎重に選択し、インプレース変更を優先するように更新を構成することで、堅牢なデータ永続性と最新アプリケーションの高同時実行要求のバランスを効果的に取ることができます。