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

createIndexes

項目一覧

  • 定義
  • 互換性
  • 構文
  • コマンドフィールド
  • Considerations
  • インデックス名
  • レプリカセットとシャーディングされたクラスター
  • 照合順序とインデックスの種類
  • Stable API
  • 動作
  • 同時実行性
  • メモリ使用量の制限
  • インデックス オプション
  • ワイルドカード インデックス
  • トランザクション
  • コミットクォーラムと書込み保証の対比
  • ワイルドカード インデックスの作成
  • コミットクォーラムを使用したインデックスの作成
  • 出力
createIndexes

コレクションに 1 つ以上のインデックスを構築します。

Tip

mongoshでは、このコマンドは db.collection.createIndex()およびdb.collection.createIndexes()ヘルパー メソッドを通じても実行できます。

ヘルパー メソッドはmongoshユーザーには便利ですが、データベースコマンドと同じレベルの情報は返されない可能性があります。 便宜上必要ない場合、または追加の戻りフィールドが必要な場合は、 データベースコマンドを使用します。

このコマンドは、次の環境でホストされている配置で使用できます。

  • MongoDB Atlas はクラウドでの MongoDB 配置のためのフルマネージド サービスです

注意

このコマンドは、すべての MongoDB Atlas クラスターでサポートされています。すべてのコマンドに対する Atlas のサポートについては、「サポートされていないコマンド」を参照してください。

  • MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン

  • MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン

createIndexesコマンドは次の形式をとります。

db.runCommand(
{
createIndexes: <collection>,
indexes: [
{
key: {
<key-value_pair>,
<key-value_pair>,
...
},
name: <index_name>,
<option1>,
<option2>,
...
},
{ ... },
{ ... }
],
writeConcern: { <write concern> },
commitQuorum: <int|string>,
comment: <any>
}
)

createIndexesコマンドは、次のフィールドを取ります。

フィールド
タイプ
説明

createIndexes

string

インデックスを作成するコレクション。

indexes

配列

作成するインデックスを指定します。 配列内の各ドキュメントは、個別のインデックスを指定します。

writeConcern

ドキュメント

任意。書込み保証(write concern)を表現するドキュメント。デフォルトの書込み保証を使用する場合は省略します。

commitQuorum

整数または文字列

任意。 データを保持するレプリカセット ノードの最小数( コミットクォーラム)で、プライマリがindexesを準備完了とマークする前に、インデックス ビルドの成功を報告する必要があるもの(プライマリを含む)を指します。

MongoDB v5.0 以降では、 から commit quorum is setのときに 中断されたインデックスビルドを"votingMembers" 一部再開できます。

コミットクォーラム内のレプリカセット ノードでは、 members[n].buildIndexestrueに設定されている必要があります。 いずれの投票ノードでもmembers[n].buildIndexesfalseに設定されている場合、デフォルトの"votingMembers"コミットクォーラムは使用できません。 members[n].buildIndexestrueに設定してすべてのノードを構成するか、別のコミットクォーラムを選択します。

次の値をサポートします。

  • "votingMembers" - データを保持するすべての投票レプリカセット ノード(デフォルト)。 「投票」ノードとは、 members[n].votes0より大きい任意のレプリカセット ノードです。

  • "majority" - データを保持するレプリカセット ノードの単純過半数。

  • <int> - データを保持する特定数のレプリカセット ノード。

  • 0 - クォーラム投票の動作を無効にします。ノードはインデックス構築を同時に開始しますが、インデックス構築を完了する前にクォーラムの投票や待機は行いません0 のコミットクォーラムでインデックス構築を開始した場合、後で setIndexCommitQuorum を使用してコミットクォーラムを変更することはできません。

  • レプリカセットのタグ名

comment

any

任意。このコマンドに添付するユーザー指定のコメント。設定すると、このコメントは以下の場所にこのコマンドの記録と合わせて表示されます。

コメントには、有効な BSON 型(string, integer, object, array など)を使用できます。

indexes配列内の各ドキュメントは、次のフィールドを持つことができます。

フィールド
タイプ
説明

key

ドキュメント

インデックスのフィールドを指定します。 各フィールドに対して、キーとインデックスを作成するフィールドの名前で、値がインデックス方向またはインデックスタイプのいずれかであるキーと値のペアを指定します。 方向を指定する場合は、昇順の場合は1を指定し、降順の場合は-1を指定します。

MongoDB は、次のような多彩なインデックス タイプをサポートしています。

詳細については、「インデックス タイプ」を参照してください。

ワイルドカード インデックスは、ユーザーがカスタム フィールドまたはコレクション内の多種多様なフィールドに対してクエリを実行するワークロードをサポートします。

  • ワイルドカード インデックスは、特定のフィールドとそのサブパス、またはドキュメント内のすべてのフィールドで作成できます。

    詳しくは、「ワイルドカード インデックス」を参照してください。

name

string

インデックスを一意に識別する名前。

unique

ブール値

任意。インデックス キーの値がインデックスの既存値と一致するドキュメントの挿入または更新をコレクションが受け入れないように、ユニークインデックスを作成します。

ユニークインデックスを作成するには、true を指定します。デフォルト値は false です。

このオプションはハッシュされたインデックスには使用できません

partialFilterExpression

ドキュメント

任意。指定すると、インデックスはフィルター式に一致するドキュメントのみを参照します。詳細については、「部分インデックス」を参照してください。

フィルター式には、次の要素を含めることができます。

クライアント側フィールドレベル暗号化またはQueryable Encryptionを使用している場合、 partialFilterExpressionは暗号化されたフィールドを参照できません。

MongoDB ではすべてのインデックス タイプpartialFilterExpression オプションを指定できます。

sparse

ブール値

任意。true の場合、インデックスは指定されたフィールドを持つドキュメントのみを参照します。これらのインデックスの使用スペースは小さくなりますが、いくつかの状況(特にソート)で異なる動作をします。デフォルト値は false です。詳細については、「スパースインデックス」を参照してください。

次のインデックス タイプはデフォルトでスパースであり、このオプションを無視します。

2dsphere インデックスキーを含む複合インデックスで、他の種類のキーも含まれている場合、インデックスがドキュメントを参照するかどうかは 2dsphere 個のインデックス フィールドによってのみ決定されます。

MongoDB には、部分インデックスを作成するオプションが用意されています。 これらは スパース インデックス の機能のスーパーセットを提供し、代わりに優先されます。

expireAfterSeconds

integer

任意。MongoDB がこのコレクション内のドキュメントを保持する期間を制御するための有効期間(TTL)の値を秒単位で指定します。このオプションは TTL インデックスにのみ適用されます。詳細については、「TTL によるコレクションのデータ期限設定」を参照してください。

MongoDB 5.0 より前のバージョンで作成された TTL インデックスを使用する場合、または MongDB 5.0 で作成されたデータを 5.0 より前のインストールと同期する場合は、「NaN を使用して構成されたインデックス」を参照して誤った構成の問題を回避してください。

TTLインデックスの expireAfterSeconds 値は、0 から 2147483647 の範囲内(両端を含む)である必要があります。

ブール値

任意。 インデックスがクエリ プランナーから非表示かどうかを決定するブール値。 非表示インデックスは、クエリプラン選択手順の一部として評価されません。

デフォルトは、false に設定されています。

storageEngine

ドキュメント

任意。インデックス作成時に、インデックス単位でストレージエンジンを構成できるようにします。

storageEngine オプションは次のような形式をとります。

storageEngine: { <storage-engine-name>: <options> }

インデックスの作成時に指定されたストレージエンジン構成オプションは、異なるストレージエンジンを使用するノードのあるレプリカセットをサポートするために、レプリケーション中に検証され、oplog に記録されます。

weights

ドキュメント

任意。 テキストインデックスの場合、フィールドと重みを含むドキュメントが組み合わされます。 重みは1から99までの整数で、 999はスコアに関して他のインデックス付きフィールドと比較したフィールドの重要性を示します。 重みはインデックス フィールドの一部またはすべてに指定できます。 スコアを調整するには、「自己管理型配置のテキスト検索結果への重みの割り当て」を参照してください。 デフォルト値は1です。

default_language

string

任意。 テキストインデックスで、ストップワードのリストとステマーとトークナイザのルールを決定する言語。 使用可能な言語については「 自己管理型配置のテキスト検索言語」を、詳細と例については「 自己管理型配置のテキストインデックスのデフォルト言語の指定」を参照してください。 デフォルト値はenglishです。

language_override

string

任意。 テキストインデックスの場合、ドキュメントの上書き言語を含む、コレクション内のドキュメントのフィールド名です。 デフォルト値はlanguageです。 例については、「自己管理型配置のテキストインデックスのデフォルト言語の指定」を参照してください。

textIndexVersion

integer

任意。text インデックスのバージョン番号。ユーザーはこのオプションを使用してデフォルトのバージョン番号を上書きできます。

使用可能なバージョンについては、「自己管理型配置のテキストインデックス バージョン 」を参照してください。

2dsphereIndexVersion

integer

任意。2dsphere インデックスのバージョン番号。ユーザーはこのオプションを使用してデフォルトのバージョン番号を上書きできます。

使用可能なバージョンについては、「2dsphere インデックス」を参照してください。

bits

integer

任意。2d インデックスで、ロケーション データの保存されたジオハッシュ値の精度数。

bits 値の範囲は 1 から 32 まで(32 を含む)です。デフォルト値は 26 です。

min

数値

任意。 2dインデックスで、経度と緯度の境界(下限を含む)。 デフォルト値は-180.0です。

max

数値

任意。 2dインデックスで、経度と緯度の値の境界(上限を含む) デフォルト値は180.0です。

collation

ドキュメント

任意。インデックスの照合を指定します。

照合を指定すると、大文字・小文字やアクセント記号など、文字列を比較するための言語独自のルールを指定できます。

コレクション レベルで照合を指定した場合、次のようになります。

  • インデックスの作成時に照合を指定しない場合、MongoDB はコレクションのデフォルトの照合でインデックスを作成します。

  • インデックスの作成時に照合を指定する場合、MongoDB は指定された照合でインデックスを作成します。

照合オプションの構文は次のとおりです。

collation: {
locale: <string>,
caseLevel: <boolean>,
caseFirst: <string>,
strength: <int>,
numericOrdering: <boolean>,
alternate: <string>,
maxVariable: <string>,
backwards: <boolean>
}

照合を指定する場合、locale フィールドは必須ですが、その他の照合フィールドはすべて任意です。フィールドの説明については、照合ドキュメントを参照してください。

wildcardProjection

ドキュメント

任意。

ユーザーが{ "$**" : 1}キー パターンを使用して、ワイルドカード インデックスに特定のフィールドパスを含めたり、 ワイルドカード インデックスから特定のフィールドパスを除外したりできます。 このオプションは、すべてのドキュメント フィールドにワイルドカード インデックスを作成する場合にのみ有効です。 特定のフィールドパスとそのサブフィールドにワイルドカード インデックスを作成する場合は、このオプションは指定できません。例: { "path.to.field.$**" : 1 }

wildcardProjection オプションは次のような形式をとります。

wildcardProjection: {
"path.to.field.a" : <value>,
"path.to.field.b" : <value>
}

<value> は次のいずれかになります。

  • 1 または true の場合は、ワイルドカード インデックスにフィールドが追加されます。

  • 0 または false の場合は、ワイルドカード インデックスからフィールドが除外されます。

ワイルドカード インデックスでは、デフォルトで _id フィールドが省略されます。_id フィールドをワイルドカード インデックスに含めるには、wildcardProjection ドキュメントに明示的に含める必要があります。

{
"wildcardProjection" : {
"_id" : 1,
"<field>" : 0|1
}
}

wildcardProjection ドキュメント内のすべてのステートメントは、包含ステートメントまたは除外ステートメントのいずれかである必要があります。除外ステートメントに _id フィールドを含めることもできます。これは、このルールの唯一の例外です。

mongoshdb.collection.createIndex() コマンドのラッパーとしてメソッドdb.collection.createIndexes()createIndexes と を提供します。

MongoDB ではバージョン0インデックスの作成が許可されていません。

createIndexesコマンドとmongoshヘルパーdb.collection.createIndex()およびdb.collection.createIndexes()は、ある名前でインデックスを作成し、その後別の名前で同じインデックスを再度作成しようとするとエラーを報告します。

{
"ok" : 0,
"errmsg" : "Index with name: x_1 already exists with a different name",
"code" : 85,
"codeName" : "IndexOptionsConflict"
}

以前のバージョンでは、MongoDB はインデックスを再度作成することはなく、 1ok値を持つ応答オブジェクトと、インデックスが再作成されなかったことを意味するメモを返します。 例:

{
"numIndexesBefore" : 2,
"numIndexesAfter" : 2,
"note" : "all indexes already exist",
"ok" : 1
}

注意

FeatureCompatibilityVersion 4.4 以上が必要です。

レプリカセット全体でインデックス構築を同時に開始するには、レプリカセットまたはシャーディングされたクラスター内の各 mongod は、featureCompatibilityVersion を少なくとも 4.4 に設定する必要があります

レプリカセットまたはシャーディングされたクラスター上のインデックスは、データを保持するすべてのレプリカセット ノードで同時に構築されます。シャーディングされたクラスターの場合、インデックス構築は、インデックスが作成されるコレクションのデータを含むシャードでのみ行われます。プライマリは、インデックスを使用可能とマークする前に、自身を含む最小限のデータを保持する voting ノード(コミットクォーラム)でインデックス構築を完了する必要があります。詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。

デフォルト以外のコミット クォーラムでインデックスのビルドを開始するには、 commitQuorum を指定します。

進行中のインデックスビルドのコミットクォーラムを変更するには、 setIndexCommitQuorumコマンドを使用します。

レプリカセットおよびシャーディングされたクラスターへのインデックス構築の影響を最小限に抑えるには、「レプリカセットでのローリング インデックス構築」で説明されているローリング インデックスの構築手順を使用してください。

次のインデックスは単純なバイナリ比較のみをサポートしており、照合はサポートしていません。

Tip

単純ではない照合順序を持つコレクションに text または 2d インデックスを作成するには、インデックスの作成時、明確に {collation: {locale: "simple"} } を指定する必要があります。

Stable API V1 を使用する場合

  • indexes配列では次のフィールドは指定できません。

    • background

    • bucketSize

    • sparse

    • storageEngine

  • geoHaystackまたはテキストインデックスは作成できません。

  • 上記でサポートされていないインデックス タイプは、 厳密モード の クエリ プランナー によって無視されます。たとえば、 cursor.hint()sparseインデックスを使用しようとすると、次のBadValueエラーが発生します。

    planner returned error :: caused by :: hint provided does not
    correspond to an existing index

featureCompatibilityVersion "4.2"の場合、 createIndexesは最適化されたビルドプロセスを使用し、インデックスビルドの開始時と終了時に指定されたコレクションの排他ロックを取得して保持します。 コレクションに対する後続のすべての操作は、 createIndexesが排他ロックを解放するまで待機する必要があります。 createIndexesでは、インデックス構築の大部分の期間中に読み取り操作と書込み操作をインターリーブすることができます。

featureCompatibilityVersion "4.0"について、 createIndexesは MongoDB インスタンスより前の4.2を使用しています。 インデックス構築プロセス。デフォルトでは、構築プロセスの全期間にわたって親データベースに対して排他ロックを取得します。 4より前の 。 2ビルド プロセスでは、操作が完了するまでデータベースそのコレクションに対するすべての操作がブロックされます。 backgroundインデックスは排他ロックを取得しません。

createIndexesのロック動作の詳細については、「 格納済みコレクションでのインデックス ビルド 」を参照してください。

重要

データを含む投票ノードにアクセスできなくなり、 commitQuorumがデフォルトのvotingMembersに設定されている場合、そのノードがオンラインに戻るまでインデックスビルドがハングする可能性があります。

createIndexesは、コレクションに 1 つ以上のインデックスの構築をサポートしています。 createIndexesはメモリとディスク上の一時ファイルの組み合わせを使用してインデックス構築を完了します。 createIndexesのメモリ使用量のデフォルトの制限は200メガバイトであり、単一のcreateIndexesコマンドを使用してビルドされたすべてのインデックスに共有されます。 メモリ制限に達すると、 createIndexes--dbpathディレクトリ内の_tmpという名前のサブディレクトリにある一時ディスク ファイルを使用してビルドを完了します。

maxIndexBuildMemoryUsageMegabytesサーバー パラメータを設定することで、メモリ制限を上書きできます。メモリ制限を高く設定すると、より早くインデックス構築を完了できる可能性があります。ただし、システム上の未使用 RAM に対してこの制限を高く設定しすぎると、メモリが不足し、サーバーがシャットダウンする可能性があります。

非表示オプションはインデックスを削除して再度作成することなく変更できます。 非表示オプション を参照してください。

既存のインデックスの照合オプションを更新できます。 その他のインデックス オプションを変更するには、 db.collection.dropIndex()を使用して既存のインデックスを削除し、新しいオプションを指定してcreateIndexesを実行します。

同じキーに対して、異なる照合を持つ複数のインデックスを作成できます。同じキー パターンで照合が異なるインデックスを作成するには、ユニークインデックス名を設定する必要があります。

コレクション レベルで照合を指定した場合、次のようになります。

  • インデックスの作成時に照合を指定しない場合、MongoDB はコレクションのデフォルトの照合でインデックスを作成します。

  • インデックスの作成時に照合を指定する場合、MongoDB は指定された照合でインデックスを作成します。

Tip

照合の strength1 または 2 に指定すると、大文字と小文字を区別しないインデックスを作成できます。照合の strength1 のインデックスは、発音と大文字・小文字の両方を区別しません。

文字列の比較にインデックスを使用するには、操作で同じ照合も指定する必要があります。つまり、照合順序を持つインデックスでは、操作で異なる照合順序が指定されている場合、インデックス付きフィールドで文字列比較を実行する操作をサポートできません。

警告

照合が構成されたインデックスは、並べ替え順序を実現するために ICU 照合キーを使用するため、照合対応のインデックス キーは、照合のないインデックスのインデックス キーよりも大きくなる可能性があります。

たとえば、コレクション myColl には、照合ロケール "fr" を持つ文字列フィールド category のインデックスがあります。

db.myColl.createIndex( { category: 1 }, { collation: { locale: "fr" } } )

インデックスと同じ照合を指定する次のクエリ操作では、インデックスを使用できます。

db.myColl.find( { category: "cafe" } ).collation( { locale: "fr" } )

ただし、デフォルトで「シンプル」なバイナリー コレータを使用する次のクエリ操作では、インデックスを使用できません。

db.myColl.find( { category: "cafe" } )

インデックス プレフィックスキーが文字列、配列、および埋め込みドキュメントではない複合インデックスの場合でも、異なる照合を指定する操作では、インデックスを使用してインデックス プレフィックスキーの比較をサポートできます。

たとえば、myColl コレクションには、数値フィールドの scoreprice、および 文字列フィールドの category の複合インデックスがあります。このインデックスは、文字列比較用の照合ロケール "fr" を使用して作成されます。

db.myColl.createIndex(
{ score: 1, price: 1, category: 1 },
{ collation: { locale: "fr" } } )

文字列の比較に "simple" バイナリ照合を使用する次の操作では、インデックスを使用できます。

db.myColl.find( { score: 5 } ).sort( { price: 1 } )
db.myColl.find( { score: 5, price: { $gt: NumberDecimal( "10" ) } } ).sort( { price: 1 } )

次の操作では、"simple" バイナリ照合を使用してインデックス付きの category フィールドで文字列を比較しますが、クエリの score: 5 部分の実行についてはインデックスが使用できます。

db.myColl.find( { score: 5, category: "cafe" } )

重要

ドキュメント キーとの照合(埋め込みドキュメントのキーを含む)では、単純なバイナリ比較が使用されます。つまり、"foo.bár" のようなキーのクエリは、strength パラメーターに設定した値にかかわらず、キー "foo.bar" と一致しません。

既存のインデックスのhiddenオプションを変更するには、次のmongoshメソッドを使用できます。

たとえば、

  • インデックスの hidden オプションを true に変更するには、db.collection.hideIndex() メソッドを使用します。

    db.restaurants.hideIndex( { borough: 1, ratings: 1 } );
  • インデックスの hidden オプションを false に変更するには、db.collection.unhideIndex() メソッドを使用します。

    db.restaurants.unhideIndex( { borough: 1, city: 1 } );

Tip

以下も参照してください。

  • ワイルドカード インデックスでは、デフォルトで _id フィールドが省略されます。_id フィールドをワイルドカード インデックスに含めるには、wildcardProjection ドキュメントに明示的に含める必要があります。

    {
    "wildcardProjection" : {
    "_id" : 1,
    "<field>" : 0|1
    }
    }

    wildcardProjection ドキュメント内のすべてのステートメントは、包含ステートメントまたは除外ステートメントのいずれかである必要があります。除外ステートメントに _id フィールドを含めることもできます。これは、このルールの唯一の例外です。

  • ワイルドカード インデックスは次のインデックスをサポートしていません。

    ワイルドカード インデックスはスパースインデックスです。インデックス付きフィールドがない場合は、クエリをサポートしません。ワイルドカード フィールドに null 値がある場合、ワイルドカード インデックスはドキュメントにインデックスを作成します。

    MongoDB 7.0 以降、ワイルドカード インデックスで昇順(1)と降順(-1)のソート順序がサポートされます。以前のバージョンでは、昇順のみがサポートされていました。

詳しくは以下を参照してください。

トランザクションがクロスシャード間書込みトランザクション(write transaction)でない場合に、分散トランザクション内にコレクションとインデックスを作成できます。

トランザクションで createIndexes を使用するには、そのトランザクションで読み取り保証(read concern)"local" を使用する必要があります。読み取り保証レベルを "local" 以外に指定すると、トランザクションは失敗します。

コミットクォーラム書込み保証 には重要な違いがあります。

  • インデックス構築にはコミットクォーラムを使用します。

  • 書き込み操作には書込み保証が必要です。

クラスタ内の各データ保有ノードは投票ノードです。

コミットクォーラムは、プライマリを含むデータを保持する投票ノードの数、またはどの投票ノードがインデックス構築を同時にコミットする準備ができている必要があるかを指定し、その後プライマリがコミットを実行します。

書き込み保証 (write concern) とは、指定された数のインスタンスに書き込み (write) が伝わったことを確認するレベルです。

バージョン 8.0 での変更: コミットクォーラムでは、プライマリがインデックス構築にコミットする前に、インデックス構築を完了する準備が整っていなければならないノードの数を指定します。対照的に、プライマリがインデックス構築にコミットした時に、書き込み保証によって、コマンドが正常に返されるまでにインデックス構築の oplog エントリを複製する必要があるノードの数が指定されます。

以前のリリースでは、プライマリがインデックス構築にコミットした時に、書き込み保証によって、コマンドが正常に返されるまでにインデックス構築を完了する必要があるノードの数が指定されていました。

次のコマンドを実行すると、 productsデータベースのinventoryコレクションに 2 つのインデックスが構築されます。

db.getSiblingDB("products").runCommand(
{
createIndexes: "inventory",
indexes: [
{
key: {
item: 1,
manufacturer: 1,
model: 1
},
name: "item_manufacturer_model",
unique: true
},
{
key: {
item: 1,
supplier: 1,
model: 1
},
name: "item_supplier_model",
unique: true
}
],
writeConcern: { w: "majority" }
}
)

インデックスのビルドが正常に完了すると、MongoDB は"ok" : 1のステータスを含む結果ドキュメントを返します。

注意

ワイルドカード インデックスの詳細については、「ワイルドカード インデックス」を参照してください。

次に、ワイルドカード インデックスの作成例を示します。

ドキュメントに product_attributes フィールドが含まれる可能性があるコレクション products_catalog を考えてみましょう。product_attributes フィールドには、埋め込みドキュメントや配列など、任意のネストされたフィールドを含めることができます。

db.products_catalog.insertMany( [
{
_id : ObjectId("5c1d358bf383fbee028aea0b"),
product_name: "Blaster Gauntlet",
product_attributes: {
price: {
cost: 299.99,
currency: "USD"
}
}
},
{
_id: ObjectId("5c1d358bf383fbee028aea0c"),
product_name: "Super Suit",
product_attributes: {
superFlight: true,
resistance: [ "Bludgeoning", "Piercing", "Slashing" ]
}
}
] )

次の操作を実行すると、product_attributes フィールドでワイルドカード インデックスが作成されます。

use inventory
db.runCommand(
{
createIndexes: "products_catalog",
indexes: [
{
key: { "product_attributes.$**" : 1 },
name: "wildcardIndex"
}
]
}
)

このワイルドカード インデックスを使用すると、MongoDB はproduct_attributes のすべてのスカラー値をインデックス化します。フィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。

ワイルドカード インデックスは、product_attributes またはそのネストされたフィールドに対する任意の単一フィールド クエリをサポート可能です。

db.products_catalog.find( { "product_attributes.superFlight" : true } )
db.products_catalog.find( { "product_attributes.maxSpeed" : { $gt : 20 } } )
db.products_catalog.find( { "product_attributes.elements" : { $eq: "water" } } )

注意

パス固有のワイルドカード インデックス構文はwildcardProjectionオプションと互換性がありません。 詳細については、パラメーターのドキュメントを参照してください。

ドキュメントに product_attributes フィールドが含まれる可能性があるコレクション products_catalog を考えてみましょう。product_attributes フィールドには、埋め込みドキュメントや配列など、任意のネストされたフィールドを含めることができます。

db.products_catalog.insertMany( [
{
_id : ObjectId("5c1d358bf383fbee028aea0b"),
product_name: "Blaster Gauntlet",
product_attributes: {
price: {
cost: 299.99,
currency: "USD"
}
}
},
{
_id: ObjectId("5c1d358bf383fbee028aea0c"),
product_name: "Super Suit",
product_attributes: {
superFlight: true,
resistance: [ "Bludgeoning", "Piercing", "Slashing" ]
}
}
] )

次の操作を実行すると、すべてのスカラー フィールド(_id フィールドを除く)にワイルドカード インデックスが作成されます。

use inventory
db.runCommand(
{
createIndexes: "products_catalog",
indexes: [
{
key: { "$**" : 1 },
name: "wildcardIndex"
}
]
}
)

このワイルドカード インデックスを使用すると、MongoDB はコレクション内の各ドキュメントのすべてのスカラー フィールドにインデックスを作成します。特定のフィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。

作成されたインデックスは、コレクションのドキュメント内の任意のフィールドに対するクエリをサポートできます。

db.products_catalog.find( { "product_price" : { $lt : 25 } } )
db.products_catalog.find( { "product_attributes.elements" : { $eq: "water" } } )

注意

ワイルドカード インデックスでは、デフォルトで _id フィールドが省略されます。_id フィールドをワイルドカード インデックスに含めるには、wildcardProjection ドキュメントに明示的に含める必要があります。詳細については、パラメーターのドキュメントを参照してください。

ドキュメントに product_attributes フィールドが含まれる可能性があるコレクション products_catalog を考えてみましょう。product_attributes フィールドには、埋め込みドキュメントや配列など、任意のネストされたフィールドを含めることができます。

db.products_catalog.insertMany( [
{
_id : ObjectId("5c1d358bf383fbee028aea0b"),
product_name: "Blaster Gauntlet",
product_attributes: {
price: {
cost: 299.99,
currency: "USD"
}
}
},
{
_id: ObjectId("5c1d358bf383fbee028aea0c"),
product_name: "Super Suit",
product_attributes: {
superFlight: true,
resistance: [ "Bludgeoning", "Piercing", "Slashing" ]
}
}
] )

次の操作ではワイルドカード インデックスを作成し、wildcardProjection オプションを使用して product_attributes.elements および product_attributes.resistance フィールドのスカラー値のみをインデックスに含めます。

use inventory
db.runCommand(
{
createIndexes: "products_catalog",
indexes: [
{
key: { "$**" : 1 },
"wildcardProjection" : {
"product_attributes.elements" : 1,
"product_attributes.resistance" : 1
},
name: "wildcardIndex"
}
]
}
)

キー パターン"$**"はドキュメント内のすべてのフィールドをカバーしますが、 wildcardProjectionフィールドは含まれるフィールドとそのネストされたフィールドのみにインデックスを制限します。

フィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。

作成されたインデックスは、 wildcardProjectionに含まれる任意のスカラー フィールドに対するクエリをサポートできます。

db.products_catalog.find( { "product_attributes.elements" : { $eq: "Water" } } )
db.products_catalog.find( { "product_attributes.resistance" : "Bludgeoning" } )

注意

ワイルドカード インデックスは、_id フィールドを明示的に含める場合を除きwildcardProjection ドキュメントに包含・除外ステートメントを混在させることはできません。wildcardProjection の詳細については、パラメーターのドキュメントを参照してください。

ドキュメントに product_attributes フィールドが含まれる可能性があるコレクション products_catalog を考えてみましょう。product_attributes フィールドには、埋め込みドキュメントや配列など、任意のネストされたフィールドを含めることができます。

db.products_catalog.insertMany( [
{
_id : ObjectId("5c1d358bf383fbee028aea0b"),
product_name: "Blaster Gauntlet",
product_attributes: {
price: {
cost: 299.99,
currency: "USD"
}
}
},
{
_id: ObjectId("5c1d358bf383fbee028aea0c"),
product_name: "Super Suit",
product_attributes: {
superFlight: true,
resistance: [ "Bludgeoning", "Piercing", "Slashing" ]
}
}
] )

次の操作を実行すると、ワイルドカード インデックスが作成され、wildcardProjection ドキュメントを使用してコレクション内の各ドキュメントのすべてのスカラー フィールド フィールドとproduct_attributes.elements product_attributes.resistanceフィールド を除く )がインデックス化されます。

use inventory
db.runCommand(
{
createIndexes: "products_catalog",
indexes: [
{
key: { "$**" : 1 },
"wildcardProjection" : {
"product_attributes.elements" : 0,
"product_attributes.resistance" : 0
},
name: "wildcardIndex"
}
]
}
)

キー パターン"$**"はドキュメント内のすべてのフィールドをカバーしますが、 wildcardProjectionフィールドは指定されたフィールドをインデックスから除外します。

フィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。

作成されたインデックスは、 wildcardProjectionによって除外されるものを 除くすべてのスカラー フィールドに対するクエリをサポートできます。

db.products_catalog.find( { "product_attributes.maxSpeed" : { $gt: 25 } } )
db.products_catalog.find( { "product_attributes.superStrength" : true } )

注意

ワイルドカード インデックスは、_id フィールドを明示的に含める場合を除きwildcardProjection ドキュメントに包含・除外ステートメントを混在させることはできません。wildcardProjection の詳細については、パラメーターのドキュメントを参照してください。

注意

FeatureCompatibilityVersion 4.4 以上が必要です。

レプリカセット全体でインデックス構築を同時に開始するには、レプリカセットまたはシャーディングされたクラスター内の各 mongod は、featureCompatibilityVersion を少なくとも 4.4 に設定する必要があります

レプリカセットまたはシャーディングされたクラスター上のインデックスは、データを保持するすべてのレプリカセット ノードで同時に構築されます。シャーディングされたクラスターの場合、インデックス構築は、インデックスが作成されるコレクションのデータを含むシャードでのみ行われます。プライマリは、インデックスを使用可能とマークする前に、自身を含む最小限のデータを保持する voting ノード(コミットクォーラム)でインデックス構築を完了する必要があります。詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。

コミットクォーラムを設定するには、 createIndexesを使用してcommitQuorum値を指定します。

commitQuorum は、データを保持する投票ノードの数、またはプライマリがコミットを実行する前にプライマリを含めてどの投票ノードがインデックス構築のコミット準備をしておく必要があるかを指定します。コミットクォーラムのデフォルトである votingMembers は、データを保持するすべてのノードを指します。

次の操作を実行すると、コミットクォーラム"majority"であるか、データを保持するノードの単純過半数であるインデックスが作成されます。

db.getSiblingDB("examples").runCommand(
{
createIndexes: "invoices",
indexes: [
{
key: { "invoices" : 1 },
"name" : "invoiceIndex"
}
],
"commitQuorum" : "majority"
}
)

プライマリがインデックス構築を準備完了とマークするには、データを保持する単純過半数の投票ノードがインデックス構築をコミットするために「投票」済みである必要があります。インデックス構築と投票プロセスの詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。

createIndexesコマンドは、操作の成功を示すドキュメントを返します。 ドキュメントには、結果に応じて、次のフィールドの一部が含まれますが、すべては含まれません。

createIndexes.createdCollectionAutomatically

trueの場合、コレクションは存在せず、インデックスの作成プロセス中に作成されたことになります。

createIndexes.numIndexesBefore

コマンドの開始時点でのインデックスの数。

createIndexes.numIndexesAfter

コマンドの末尾にあるインデックスの数。

createIndexes.ok

1の値は、インデックスがその場所にあることを示します。 値が0の場合はエラーを示します。

createIndexes.note

このnoteは、既存のインデックスがすでに存在する場合に返されます。 これは、インデックスが作成または変更されなかったことを示します。

createIndexes.errmsg

エラーに関する情報を返します。

createIndexes.code

エラーのタイプを表すエラー コード。

戻る

create