すべてのプロダクト
Search

このプロダクト

    ApsaraDB for MongoDB:MongoDB 8.0 の新機能

    ドキュメントセンター

    ApsaraDB for MongoDB:MongoDB 8.0 の新機能

    最終更新日:Mar 29, 2026

    MongoDB 8.0 は、メモリ管理、レプリケーション、シャーディング、集約、セキュリティにおいて、大幅なパフォーマンス向上と新機能を提供します。このトピックでは、アップグレードを評価し、それらがご利用のアプリケーションにどのように影響するかを理解するのに役立つ主な変更点をまとめます。

    完全なアップストリーム変更ログについては、「MongoDB 8.0 release notes」をご参照ください。

    Advanced TCMalloc

    MongoDB 8.0 は、以前のメモリアロケータを Advanced TCMalloc バージョンに置き換えることで、メモリフラグメンテーションを削減し、高負荷下でのパフォーマンスを維持します。この改善を促進する主な変更点は次の2つです。

    • CPUごとのキャッシング: Advanced TCMalloc は、スレッドごとではなく CPU コアごとにキャッシュを使用することで、メモリフラグメンテーションを削減し、データベースが高負荷の同時ワークロードを処理できるようにします。

    • バックグラウンドメモリ解放: バックグラウンドスレッドは、未使用メモリを毎秒オペレーティングシステムに解放しようとします。

    tcmallocReleaseRate パラメーターは、バイト/秒単位での解放レートを制御します。MongoDB 8.0 以前では、このパラメーターは 1–10 という曖昧な範囲を受け入れていました。ApsaraDB for MongoDB では、デフォルト値は 10485760 (10 MB) です。0 に設定した場合でも、アロケータは一部のメモリを解放します。ご利用のワークロード要件に基づいてこの値を調整してください。

    レプリケーションパフォーマンス

    "Majority" ライトコンサーンの動作変更

    MongoDB 8.0 以降、writeConcern が majority に設定されている場合、MongoDB は oplog エントリがレプリカセットメンバーの過半数に書き込まれた後、それらのメンバーが変更を適用するのを待たずに書き込みを承認します。これにより、majority モードでの書き込みスループットが向上します。

    潜在的な影響: ご利用のアプリケーションが majority 書き込み確認を受信した直後にセカンダリノードから読み取る場合、クエリは当該書き込みからの変更が含まれていない結果を返す可能性があります。

    oplog の並行書き込みと適用

    セカンダリノードは、oplog バッチを並行して書き込み、適用するようになりました。

    • ライタースレッドは、プライマリノードから新しい oplog エントリを読み取り、ローカル oplog に書き込みます。

    • アプライヤースレッドは、それらの変更をローカルデータベースに非同期に適用します。

    これにより、セカンダリノードでのレプリケーションスループットが向上します。関連する serverStatus メトリックは、現在 metrics.repl.buffer.write および metrics.repl.buffer.apply として報告されます。

    リシャーディングパフォーマンス

    MongoDB 8.0 では reshardCollection が大幅に高速化されました。新しい forceRedistribution オプションを使用すると、既存のシャードキーを使用してコレクションをリシャードし、データを新しいシャードに再配布できます。これは、チャンクを特定の範囲に移行するよりも速く完了します。forceRedistribution を zones オプションと組み合わせることで、データを特定のゾーンに移行できます。

    db.adminCommand({
    reshardCollection: "db.coll",
    key: { shard_key: "hashed" },
    forceRedistribution: true
})
    説明

    リシャーディング中のインデックス構築は、明示的なエラーメッセージなしでインデックス構築がサイレントに失敗する原因となる可能性があります。リシャーディングを開始する前にすべてのインデックス構築を完了するか、リシャーディングが進行中の間はインデックス構築を避けてください。

    増分 oplog キャッチアップステージ中、ソースシャードは、推定残り時間が2秒以内である場合にのみコレクションへの書き込みをブロックし、その後、送信先シャードがキャッチアップを完了するのを待ちます。ご利用のユースケースが、例えばメンテナンスウィンドウ中など、より長いブロッキングウィンドウを許容できる場合は、commitReshardCollection コマンドを実行して直ちに書き込みをブロックし、リシャーディングの完了を加速してください。

    詳細については、「Resharding process」および「Shard a collection」をご参照ください。

    シャーディング

    上記のリシャーディングの改善に加えて、MongoDB 8.0 には次のシャーディング変更が含まれています。

    • ハッシュシャーディングのデフォルト: ハッシュシャーディングは、デフォルトでシャードごとに1つのチャンクを作成します (MongoDB 8.0 以前の2つのチャンクから減少)。

    • シャードでの `dbHash`: dbHash コマンドは、個々のシャードで実行できるようになりました。

    • クエリにおける部分的なシャードキー: findAndModify および deleteOne は、クエリ述語として部分的なシャードキーを受け入れます。

    • `upsert` を伴う `updateOne`: シャードコレクションで updateOne を upsert: true とともに使用する場合、すべてのシャードキーフィールドをクエリ述語から省略できます。

    • `unshardCollection`: 既存のコレクションからシャーディングを削除し、すべてのドキュメントを特定のシャード、または最もデータが少ないシャードに移動します。

    • `moveCollection`: シャード化されていないコレクションを、プライマリシャードとは独立して、特定のシャードに移動します。時系列コレクションと Queryable Encryption コレクションは移動できません。移動中、書き込み操作は約2秒間ブロックされます。

    次のコマンドと mongosh ヘルパー関数が利用可能です。

    コマンドmongosh ヘルパー説明
    moveCollectionsh.moveCollection()シャード化されていないコレクションを特定のシャードに移動します。
    unshardCollectionsh.unshardCollection()コレクションからシャーディングを削除し、すべてのデータを特定のシャードに移動します。
    abortMoveCollectionsh.abortMoveCollection()進行中の moveCollection 操作をキャンセルします。
    abortUnshardCollectionsh.abortUnshardCollection()進行中の unshardCollection 操作をキャンセルします。
    Nonesh.shardAndDistributeCollection()コレクションをシャードし、既存のシャードキーでデータを直ちに再配布します。shardCollection の実行後に reshardCollection を実行するのと同等です。

    ロギング

    workingMillis フィールドは、スロークエリログに追加されます。これは、MongoDB が操作の処理に実際に費やした時間を示し、真のパフォーマンスボトルネックを特定するのに役立ちます。

    ロック待ちやトラフィック速度制限を含む総操作レイテンシを反映する durationMillis とは異なり、workingMillis はそれらの外部待機時間を除外します。キューやロックの競合とは独立して実際の処理時間を測定したい場合は、workingMillis を使用してください。

    集約

    BinData 変換

    $convert 演算子は、次の変換をサポートするようになりました。

    • 文字列から BinData

    • BinData から文字列

    $toUUID 式は、文字列値を UUID に変換するためのショートカットを提供します。

    $queryStats

    $queryStats 集約ステージは、記録されたクエリの統計を返します。MongoDB 8.0 では、変更ストリーム内のメトリックもより効率的に追跡および報告します。

    データベースセキュリティ

    Queryable Encryption: 範囲クエリ

    Queryable Encryption は、$lt、$lte、$gt、および $gte を使用して、暗号化されたフィールドに対する範囲クエリをサポートするようになりました。

    エントランスキュー

    MongoDB 8.0 は、受信ネットワークリクエスト用のエントランスキュー (ingressAdmissionControllerTicketPoolSize) を導入します。ネットワークから受信した操作は、データベースに受け入れられる前にこのキューに入ります。

    キューはデフォルトで無制限です。最大キューサイズを設定して、キューに入れられたリクエストの数を制限し、トラフィックスパイク時の無制限のキューイングを防いでください。

    その他の最適化

    クエリシェイプとクエリ設定

    MongoDB 8.0 は、新しいクエリシェイプの概念を導入します。以前のクエリシェイプは、現在 プランキャッシュクエリシェイプ と呼ばれています。クエリプランの選択に影響を与えるには、クエリ設定 (インデックスフィルターではない) を使用してください — インデックスフィルターを設定するための planCacheSetFilter は MongoDB 8.0 ではサポートされなくなりました。

    3つのコマンドがクエリ設定を管理します。

    • setQuerySettings: インデックスヒントを指定するか、特定のクエリシェイプの reject ポリシーを設定して、その実行をブロックします。

    • removeQuerySettings: クエリシェイプのクエリ設定を削除します。

    • $querySettings: 現在のクエリ設定を表示します。

    クエリプラン最適化時間

    explain() 出力には、クエリプラン最適化に費やされた時間をミリ秒単位で報告する queryPlanner.optimizationTimeMillis が含まれるようになりました。

    デフォルトの読み取り操作タイムアウト

    新しい defaultMaxTimeMS パラメーターは、読み取り操作のデフォルトの時間制限 (ミリ秒単位) を設定します。これは、find、aggregate ($merge および $out ステージを除く)、count、distinct、および dbHash に適用されます。クライアントが個々の操作で maxTimeMS を指定した場合、その値が優先されます。

    bulkWrite コマンド

    新しい bulkWrite コマンドは、単一のリクエストで複数のコレクションにわたる複数の挿入、更新、および削除操作を実行します。

    その他の変更点

    • `updateOne` のソート: updateOne は sort オプションをサポートするようになりました。

    • キャッピングされたコレクション上の TTL インデックス: TTL インデックスは、キャッピングされたコレクション上に作成できるようになりました。

    • 一括挿入 oplog バッチ処理: 非トランザクション一括挿入は、個別のエントリではなく単一の oplog エントリとして書き込まれるようになりました。挿入されたすべてのドキュメントは、変更ストリームイベントで同じ clusterTime を共有します。これにより、一括挿入パフォーマンスが向上し、セカンダリノードで複数の oplog をリプレイすることによるレプリケーションラグが削減されます。

    • 同時 DDL 操作: 同じデータベース内の異なるコレクションは、DDL 操作を同時に実行できるようになりました。

    • DDL 中のシャードメンバーシップの変更: DDL 操作 (reshardCollection など) が進行中の間は、シャードクラスターからのシャードの追加または削除はブロックされます。シャードメンバーシップを変更する前に、DDL 操作を完了してください。

    インデックス構築の改善

    MongoDB 8.0 は、インデックス構築におけるエラー報告と回復力を向上させます。

    側面MongoDB 8.0MongoDB 8.0 以前
    エラー報告コレクションスキャンフェーズ中に検出されたエラー (重複キーエラーを除く) は直ちに返され、インデックス構築は停止します。コレクションスキャン中に検出されたエラーは、インデックス構築の最後にあるコミットフェーズでのみ返され、診断までの時間が増加していました。
    セカンダリノードの回復力インデックス構築エラー時、セカンダリノードはプライマリにインデックス構築の停止を要求でき、クラッシュしません。(セカンダリがすでにコミットに投票している場合、停止できずクラッシュします — これは MongoDB 7.0 の動作と一致します。)インデックス構築エラーにより、セカンダリノードがクラッシュする可能性がありました。
    ディスク領域管理利用可能なディスク領域が indexBuildMinAvailableDiskSpaceMB を下回ると、インデックス構築は自動的に停止します。(メンバーがすでにコミットに投票している場合は停止しません。)ディスク領域不足の場合もインデックス構築は停止していました。