Atlas Search インデックス パフォーマンス

インデックスのサイズと構成

Atlas Search インデックスを作成すると、フィールドマッピングはデフォルトで動的になります。つまり、コレクション内の動的にインデックスを作成できるすべてのデータ型が、Atlas Search によって動的にインデックス化されます。 強調表示を有効にするなどの他のオプションも、インデックスがより多くのディスク領域を使用する可能性があります。 Atlas Search インデックスのサイズとパフォーマンス フットプリントは、次の方法で縮小できます。

• カスタムインデックス定義を指定して、インデックスを作成するデータの量とタイプを絞り込みます。

• インデックス定義でstring型を指定するときに、 storeオプションをfalseに設定します。

{
  "_id": 0,
  "name": "Springfield High",
  "mascot": "Pumas",
  "teachers": [
    {
      "first": "Jane",
      "last": "Smith",
      "classes": [
        {
          "subject": "art of science",
          "grade": "12th"
        },
        ... // 2 more embedded documents
      ]
    },
    ... // 1 more embedded document
  ],
  "clubs": {
    "stem": [
      {
        "club_name": "chess",
        "description": "provides students opportunity to play the board game of chess informally and competitively in tournaments."
      },
      ... // 1 more embedded document
    ],
    ... // 1 more embedded document
  }
}

Atlas Search インデックスの作成と更新

Atlas Search インデックスの作成は、リソースを集中的に消費します。 インデックスの構築中に Atlas クラスターのパフォーマンスが影響を受ける可能性があります。

Atlas はコレクションに対するすべての書込み (write) を複製します。 つまり、Atlas Search インデックスを持つコレクションごとに、書込み (write) は、そのコレクションに定義されている Atlas Search インデックスの量に複製されます。

場合によっては、Atlas Search インデックスを再構築する必要がある場合があります。 Atlas Search インデックスの再ビルドもリソースを消費するため、データベースのパフォーマンスに影響を与える可能性があります。 Atlas Search は、次の場合にのみインデックスを自動的に再ビルドします。

• インデックスの定義の変更

• 重大な変更を含む Atlas Search のバージョン アップデート

• インデックスの破損などのハードウェア関連の問題

結果整合性とインデックス作成レイテンシ

Atlas Search は 結果整合性 をサポートしており、より強力な整合性保証は提供しません。 つまり、MongoDB コレクションに挿入され、Atlas Search によってインデックスが作成されたデータは、 $searchクエリですぐに使用できなくなります。

Atlas Search は MongoDB Change Stream からデータを読み取り、そのデータを非同期プロセスでインデックスを作成します。 このプロセスは通常非常に高速ですが、レプリケーションのレイテンシ、システムリソースの可用性、インデックス定義の複雑さによって影響を受ける場合があるかもしれません。 Atlas Search インデックスの数が多いと、Atlas Search インデックスのレプリケーションラグとレイテンシにも影響する可能性があります。

ドキュメント マッピングの説明

Atlas Search が任意のキーを持つドキュメントをインデックス化し、動的マッピングがある場合、マッピングの急増が発生します。 mongotプロセスはメモリを消費する量が増加し、クラッシュする可能性があります。 インデックスにフィールドを追加しすぎると、マッピングが急増する可能性があります。 この問題に対処するには、クラスターをアップグレードするか、データ内のすべてのフィールドにインデックスを作成しない静的マッピングを使用します。

ワイルドカード パスを使用してフィールドを検索する場合は、チュートリアルのようなスキーマを使用するように検索を設計します。 キーと値のスキーマを使用するワイルドカード パス検索を実行すると、Atlas Search は各キーを独自のフィールドとしてインデックス化するため、マッピングが急増する可能性があります。

ruleBuilder: {
  ruleName1: <data>,
  ruleName2: <data>,
  .....
  ruleName1025: <data>
}

{
  ruleBuilder: [
    {name: ruleName1, data: <data>},
    {name: ruleName2, data: <data>},
    ...
    {name: ruleName1025, data: <data>}
  ]
}

ソース フィールドの保存

Atlas Search に保存するフィールドを構成すると、 $sort 、 $match 、 $group 、 $skipなど、後続の 集計パイプライン ステージ のパフォーマンスが向上します。 元のドキュメントと一致したデータセットが大きくなり、データ全体を検索するのが非効率的になる場合は、この最適化を使用します。 Atlas Search に特定のフィールドを保存し、保存されたフィールドのみを返す方法の詳細については、「 Atlas Search インデックスに保存されたソース フィールドの定義 」と「 保存されたソース フィールドの返却 」を参照してください。

後続のステージに必要な最小限の数のフィールドのみを保存することをお勧めします。 必要に応じて、パイプライン ステージの最後に$lookupを使用して、例に示すようにドキュメント全体を検索できます。 不要なフィールドを保存すると、ディスク使用率が向上し、インデックス作成やクエリ中に悪影響が及ぶ可能性があります。

Atlas Search のアップグレード

Atlas Search は Atlas クラスターに配置されます。 Atlas Search の新しいバージョンを配置すると、Atlas クラスターで短時間のネットワーク障害が発生し、クエリ結果が返される可能性があります。 配置中に問題を軽減し、アプリケーションへの影響を最小限に抑えるには、次の点を考慮してください。

• アプリケーションに再試行ロジックを実装します。

• AtlasメンテナンスWindowsを構成します。

  注意

  Atlas Search のアップグレードは、メンテナンスウィンドウ中にのみ開始され、メンテナンスウィンドウ後に継続される可能性があります。

各リリースの変更の詳細については、「 Atlas Search の変更ログ 」を参照してください。

インデックス作成パフォーマンスのスケールアップ

クラスターをより多くのコアを持つ上位階層にアップグレードすることで、Atlas Search インデックスの最初の同期と定常状態のインデックスをスケールアップできます。 Atlas Search は、使用可能な全コアの割合を使用して最初の同期と定常状態のインデックス作成の両方を実行し、クラスターをアップグレードすることで新しいコアが使用可能になるにつれてパフォーマンスが向上します。

Atlas クラスター構成の変更

ローカル NVMeストレージ タイプを使用するように配置を再構成するか、 NVMeベースのクラスターをアップスケールするように配置を再構成する場合、Atlas Search は、各ノードが基礎となる構成またはアップスケール アクションを完了した後に、構成されたすべての Atlas Search インデックスの最初の同期を実行します。 Atlas Search インデックスの最初の同期に、クラスター構成の変更を完了するのにかかる時間よりも長い時間がかかる場合、Atlas クラスター内のすべてのノードで最初の同期が完了するまで$searchクエリを実行することはできません。

Atlas クラスターと ワークロードを個別にスケーリングするには、$search 専用の検索ノード を配置することをお勧めします。専用検索ノードはmongotプロセスのみを実行するため、 mongotプロセスの可用性、パフォーマンス、ワークロードのバランスが向上します。