ApsaraDB for MongoDB:MongoDB 8.0 の新機能

クイックプレビュー

このトピックでは、以下の側面から MongoDB 8.0 を紹介します。

• 新機能

  • 高度な TCMalloc

  • レプリケーション パフォーマンスの最適化

  • 再シャーディング パフォーマンスの最適化

• 最適化

  • シャーディング

  • ロギング

  • 集約

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

  • その他の最適化

詳細については、「MongoDB 8.0 リリースノート」をご参照ください。

高度な TCMalloc

MongoDB 8.0 は高度な TCMalloc を使用します。

• キャッシュ メカニズムの調整: 高度な TCMalloc は、各スレッドではなく各 CPU のキャッシュを使用して、メモリ フラグメントを削減し、データベースが高負荷に対応できるようにします。

• メモリ解放メカニズム: 高度な TCMalloc は、1 秒ごとにオペレーティング システムにメモリを解放しようと試みるバックエンド スレッドを作成します。

  tcmallocReleaseRate パラメーターは、メモリ解放のレートを bytes/s 単位で指定します。 MongoDB 8.0 より前は、このパラメーター値はあいまいな 1-10 でした。 ApsaraDB for MongoDB の tcmallocReleaseRate のデフォルト値は 10485760 で、これは 10 MB に相当します。このパラメーター値が 0 であっても、一部のメモリは解放されます。ビジネス要件に基づいてこの値をカスタマイズできます。

レプリケーション パフォーマンスの最適化

再シャーディング パフォーマンスの最適化

reshardCollection のパフォーマンスが向上しました。このコマンドを使用して、コレクションのシャード キーとデータの分散を変更できます。

MongoDB 8.0 は forceRedistribution オプションをサポートしており、これにより、以前と同じシャード キーを使用してコレクションを再シャーディングし、新しいシャードにデータを再分散できます。これは、チャンクを特定の範囲に移行するよりも時間がかかりません。このオプションを zones オプションと一緒に使用して、データを特定のゾーンに移行できます。

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

増分 oplog キャッチアップ ステージでは、ソース シャード ブロックは、推定残りの操作時間が 2 秒以内である場合にのみコレクションへの書き込みをブロックし、宛先シャードがキャッチアップを完了するのを待ちます。ただし、サービスのダウンタイムやメンテナンス ウィンドウなど、ビジネスでより長いブロッキング期間を受け入れることができる場合は、commitReshardCollection コマンドを使用して、事前にこのコレクションへの書き込みを禁止し、再シャーディング プロセスの完了を高速化できます。

再シャーディングのカーネル フローの詳細については、「再シャーディング プロセス」をご参照ください。再シャーディングに関連する操作の詳細については、「コレクションのシャーディング」をご参照ください。

シャーディング

再シャーディング パフォーマンスの最適化に加えて、MongoDB 8.0 は以下の側面からシャーディングを最適化します。

• ハッシュ シャーディングは、デフォルトでシャードごとに 1 つのチャンクを作成します（MongoDB 8.0 より前は、デフォルトで 2 つのチャンクが作成されていました）。

• dbhash コマンドはシャード上で実行できます。

• findAndModify コマンドと deleteOne コマンドは、部分的なシャード キーをクエリ述語として使用できます。

• シャーディングされたコレクションで upsert を true に設定して updateOne コマンドを使用する場合、クエリ述語内のすべてのシャード キーを除外できます。

• unshardCollection コマンドまたは sh.unshardCollection() メソッドを使用して、既存のコレクションのシャーディング操作をキャンセルできます。これにより、コレクション内のすべてのドキュメントが特定のシャード、またはデータ量が最も少ないシャードに移動されます。

• moveCollection コマンドを使用して、シャーディングされていないコレクションをプライマリ シャードに制限されることなく特定のシャードに移動できます。ただし、時系列コレクションとクエリ可能な暗号化コレクションは移動できず、コレクション書き込みブロックは約 2 秒間続きます。

• 次のデータベース コマンドと mongosh ヘルパー関数がサポートされています。

  コマンド	mongosh ヘルパー関数	説明
  moveCollection	sh.moveCollection()	シャーディングされていないコレクションを特定のシャードに移動します。
  unshardCollection	sh.unshardCollection()	既存のシャーディングされたコレクションのシャーディング操作をキャンセルし、コレクション データを特定のシャードに移動します。
  abortMoveCollection	sh.abortMoveCollection()	実行中の moveCollection 操作を停止します。
  abortUnshardCollection	sh.abortUnshardCollection()	実行中の unshardCollection 操作を停止します。
  なし	sh.shardAndDistributeCollection()	コレクションをシャーディングし、既存のシャード キーを使用してすぐにデータを再分散します。 データ移行を高速化します。このヘルパー関数は、shardCollection と reshardCollection を組み合わせたものと同じ結果になります。

ロギング

workingMillis フィールドがスロー クエリ ログに追加され、実際の操作に必要な時間が表示されます。

合計操作レイテンシを示す durationMillis オプションとは異なり、workingMillis には、ロック待ちやトラフィック調整などの要因によって消費された時間は含まれません。

集約

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

その他の最適化

• 新しい クエリ シェイプ が導入されました。以前のクエリ シェイプは、プラン キャッシュ クエリ シェイプと呼ばれます。クエリ オプティマイザーは、クエリ設定を追加の入力情報として使用し、最終的なクエリ プランの選択に影響を与えます。

  • setQuerySettings には、クエリ設定が含まれています。

    • インデックスの選択を指定します。 MongoDB 8.0 では、planCacheSetFilter を使用して index filter を設定することはできません。

    • トラフィック調整設定を指定します。 reject オプションを使用して、特定のクエリ シェイプの拒否を設定できます。

  • removeQuerySettings は、クエリ設定を削除するために使用されます。

  • $querySettings は、クエリ設定を表示するために使用されます。

• explain() コマンドには、queryPlanner.optimizationTimeMillis にミリ秒単位で測定されたクエリ プランの最適化に費やされた時間が含まれています。

• 新しい defaultMaxTimeMS パラメーターは、単一の読み取り操作が完了するまでのデフォルトの制限時間をミリ秒単位で指定します。

  • 該当する操作:

    • find

    • aggregate（$merge ステージと $out ステージを除く）

    • count

    • distinct

    • dbHash

  • クライアントが maxTimeMS を指定した場合、defaultMaxTimeMS はこの操作には適用されなくなります。

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

• updateOne は、sort オプションを使用したソートをサポートしています。

• TTL インデックスは、キャップされたコレクションに作成できます。

• トランザクションではないバルク挿入では、個別の oplog は生成されなくなり、単一の oplog でバッチ処理されます。挿入されたすべてのドキュメントは、変更ストリーム イベントで同じ clusterTime を持ちます。これにより、バルク挿入のパフォーマンスが向上し、セカンダリ ノードから複数の oplog を再生することによって発生する可能性のあるレプリケーションの遅延が回避されます。

• 同じデータベース内の異なるコレクションに対して、同時 DDL 操作を実行できます。

• コレクションを変更する reshardCollection など、シャーディングされたクラスターで DDL 操作が実行されている場合、シャードの追加または削除はブロックされます。これらの操作は、DDL 操作の後でのみ実行できます。

• インデックスの作成は、より高速なエラー レポートとより強力なディザスタ リカバリ機能によって改善されています。

  操作	MongoDB 8.0	MongoDB 8.0 より前
  エラー検出後にインデックスの作成を停止する状況	コレクション スキャン フェーズ中に検出されたインデックス エラー（重複キー エラーを除く）はすぐに返され、インデックスの作成は停止します。 MongoDB 8.0 は、インデックス エラーの診断を迅速に実行するのに役立ちます。たとえば、互換性のないインデックス値形式が見つかった場合、このエラーはすぐに返されます。	MongoDB 8.0 より前は、コレクション スキャン フェーズ中に検出されたインデックス エラーは、インデックス作成の最後に発生するコミット フェーズで返されていました。 MongoDB 8.0 と比較して、以前のバージョンでは、コミット フェーズのインデックス作成の最後にエラーが返されるため、インデックス作成エラーが返されるまでに時間がかかる場合があります。
  回復力のあるデプロイメント	デプロイメントの回復力が強化されています。インデックス作成エラーが発生した場合、セカンダリ メンバーはプライマリ メンバーにインデックス作成の停止を要求でき、クラッシュしません。 インデックス作成の停止要求は、常に実行できるとは限りません。メンバーがすでにインデックスのコミットに投票している場合、セカンダリ メンバーはインデックス作成の停止を要求できず、クラッシュします。この状況は、MongoDB 7.0 以前のバージョンと似ています。	インデックス作成エラーにより、セカンダリ メンバーがクラッシュする可能性があります。
  ディスク容量	インデックス作成のためにディスク容量管理が最適化されています。使用可能なディスク容量が indexBuildMinAvailableDiskSpaceMB パラメーターで指定された最小値未満の場合、インデックス作成が自動的に停止する場合があります。 メンバーがインデックスのコミットに投票している場合、インデックス作成は停止しません。	使用可能なディスク容量が不十分な場合も、インデックス作成は停止します。