Docs Menu
Docs Home
/
MongoDB マニュアル
/

FAQ: Indexes

項目一覧

  • インデックスの作成方法
  • インデックスビルドはデータベースのパフォーマンスにどのような影響を与えますか。
  • インデックスのビルドの進捗状況を監視するにはどうすればよいですか。
  • インデックスのビルドを終了するにはどうすればよいですか?
  • コレクションに存在するインデックスを確認するにはどうすればよいですか。
  • クエリがインデックスを使用しているかどうかを確認するには
  • インデックスを作成するフィールドをどのように決定するか?
  • インデックスのサイズを確認するには
  • 書込み (write) 操作はインデックスにどのような影響を与えますか。
  • 無作為データはインデックスのパフォーマンスにどのような影響を与えますか。

このドキュメントでは、 MongoDB インデックスに関するよくある質問について説明します。 インデックスの詳細については、「インデックス 」を参照してください。

コレクションにインデックスを作成するには、 db.collection.createIndex()メソッドを使用します。 インデックスの作成は管理操作です。 一般に、アプリケーションは定期的にdb.collection.createIndex()を呼び出しないでください。

注意

インデックスビルドはパフォーマンスに影響を与える可能性があります。詳しくは、 インデックス ビルドはデータベースのパフォーマンスにどのように影響しますか。 。 管理者は、インデックスを構築する前にパフォーマンスへの影響を考慮する必要があります。

データが存在するコレクションに対して MongoDB インデックスを構築するには、コレクションに対する排他読み取りおよび書込みロックが必要です。 コレクションに対する読み取りロックまたは書き込みロックを必要とする操作は、 mongodがロックを解放するまで待機する必要があります。

  • 機能の互換性バージョン(fcv) "4.2"の場合、MongoDB は最適化されたビルドプロセスを使用し、インデックスビルドの開始と終了時にのみ排他ロックを保持します。 構築プロセスの残りの部分は、読み取り操作と書込み (write) 操作のインターリーブによって一時停止されます。

  • 機能の互換性バージョン(fcv) "4.0"の場合、デフォルトのフォアグラウンド インデックス構築プロセスはインデックス構築全体の排他ロックを保持します。 backgroundインデックスビルドはビルドプロセス中に排他ロックを取得しませ

インデックス構築プロセスの詳細については、「入力済みコレクションでのインデックス構築」を参照してください。

レプリカセット のインデックスビルドには、特定のパフォーマンス上の考慮事項とリスクがあります。 詳細については、 「レプリケートされた環境でのインデックス構築」 を参照してください。 シャード レプリカセットを含むレプリカセットへのインデックス ビルドの影響を最小限に抑えるには、「 レプリカセットでのローリング インデックス ビルド 」で説明されているローリング インデックスのビルド手順を使用してください。

現在実行中のインデックス作成操作に関する情報を返すには、「アクティブなインデックス作成操作 」を参照してください。

進行中のインデックスビルドを終了するには、 db.collection.dropIndex()またはそのshellヘルパー dropIndex() またはdropIndexesを使用します。 レプリカセットまたはシャーディングされたクラスターで進行中のインデックスビルドを終了するために、 db.killOp()を使用しないでください。

レプリカセットのセカンダリ ノードでの複製されたインデックスのビルドは終了できません。 最初にプライマリのインデックスを削除する必要があります。 プライマリはインデックスのビルドを停止し、関連するabortIndexBuild oplogエントリを作成します。 abortIndexBuild oplog エントリを複製するセカンダリは、進行中のインデックスビルドを停止し、ビルドジョブを破棄します。

詳細については、「進行中のインデックスビルドの停止 」を参照してください。

コレクションのインデックスを一覧表示するには、 db.collection.getIndexes()メソッドを使用します。

MongoDB がクエリを処理する方法を調べるには、 explain()メソッドを使用します。

インデックスを作成するフィールドは、選択性、 複数のクエリシェイプのサポート、 インデックスのサイズ など、さまざまな要因に応じてインデックスを作成するフィールドを決定します。 詳細については、「インデックスの運用上の考慮事項 」と「インデックス作成戦略 」を参照してください。

db.collection.stats()には、コレクションの各インデックスのサイズ情報を提供するindexSizesドキュメントが含まれています。

インデックスのサイズによっては、インデックスが RAM に収まらない場合があります。 サーバーにインデックスとワーキングセットの残りの部分の両方に十分な RAM がある場合、インデックスは RAM に収まります。 インデックスが大きすぎて RAM に収まらない場合、MongoDB はディスクからインデックスを読み取る必要があります。これは、RAM からの読み取りよりもはるかに遅い操作です。

場合によっては、インデックスが RAM に完全に 収まる必要がない場合もあります。 詳細については、「 RAM に最近の値のみを保持するインデックス 」を参照してください。

書込み操作にはインデックスのアップデートが必要になる場合があります。

  • 書込み操作によってインデックス フィールドが変更される場合、MongoDB は変更されたフィールドをキーとして持つすべてのインデックスを更新します。

そのため、アプリケーションが書き込みが多い場合、インデックスはパフォーマンスに影響を与える可能性があります。

インデックス フィールドで大量の無作為データ(たとえば、ハッシュされたインデックス)の挿入操作が実行される場合、挿入パフォーマンスが低下することがあります。無作為データを一括挿入すると、無作為のインデックスエントリが作成され、インデックスのサイズが増大します。無作為な挿入ごとに別のインデックスエントリへのアクセスが必要なサイズにインデックスが達した場合、挿入により WiredTiger キャッシュがエビクションおよび置き換えられる率が上昇します。こうした場合、インデックスは完全にキャッシュされなくなり、ディスク上で更新されるため、パフォーマンスが低下します。

インデックス フィールドでの無作為データの一括挿入動作を向上させるには、次のいずれかを実行します。

  • インデックスを削除し、無作為データを挿入した後に再度作成します。

  • インデックスのない空のコレクションにデータを挿入します。

一括挿入後にインデックスを作成すると、メモリ内のデータがソートされ、すべてのインデックスに対して順序付き挿入が実行されます。

戻る

Fundamentals