定義
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コマンドは、次のフィールドを取ります。
フィールド | タイプ | 説明 |
|---|---|---|
| string | インデックスを作成するコレクション。 |
| 配列 | 作成するインデックスを指定します。 配列内の各ドキュメントは、個別のインデックスを指定します。 |
| ドキュメント | 任意。書込み保証(write concern)を表現するドキュメント。デフォルトの書込み保証を使用する場合は省略します。 |
| 整数または文字列 | 任意。 データを保持するレプリカセット ノードの最小数( コミットクォーラム)で、プライマリが MongoDB v5.0 以降では、 から コミットクォーラム内のレプリカセット ノードでは、 次の値をサポートします。
|
| any | 任意。このコマンドに添付するユーザー指定のコメント。設定すると、このコメントは以下の場所にこのコマンドの記録と合わせて表示されます。
コメントには、有効な BSON 型(string, integer, object, array など)を使用できます。 |
indexes配列内の各ドキュメントは、次のフィールドを持つことができます。
フィールド | タイプ | 説明 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ドキュメント | インデックスのフィールドを指定します。 各フィールドに対して、キーとインデックスを作成するフィールドの名前で、値がインデックス方向またはインデックスタイプのいずれかであるキーと値のペアを指定します。 方向を指定する場合は、昇順の場合は MongoDB は、次のような多彩なインデックス タイプをサポートしています。 詳細については、「インデックス タイプ」を参照してください。 ワイルドカード インデックスは、ユーザーがカスタム フィールドまたはコレクション内の多種多様なフィールドに対してクエリを実行するワークロードをサポートします。
| ||||||||||
| string | インデックスを一意に識別する名前。 | ||||||||||
| ブール値 | 任意。インデックス キーの値がインデックスの既存値と一致するドキュメントの挿入または更新をコレクションが受け入れないように、ユニークインデックスを作成します。 ユニークインデックスを作成するには、 このオプションはハッシュされたインデックスには使用できません。 | ||||||||||
| ドキュメント | 任意。指定すると、インデックスはフィルター式に一致するドキュメントのみを参照します。詳細については、「部分インデックス」を参照してください。 フィルター式には、次の要素を含めることができます。 クライアント側フィールドレベル暗号化またはQueryable Encryptionを使用している場合、 MongoDB ではすべてのインデックス タイプで | ||||||||||
| ブール値 | 任意。 次のインデックス タイプはデフォルトでスパースであり、このオプションを無視します。
MongoDB には、部分インデックスを作成するオプションが用意されています。 これらは スパース インデックス の機能のスーパーセットを提供し、代わりに優先されます。 | ||||||||||
| integer | 任意。MongoDB がこのコレクション内のドキュメントを保持する期間を制御するための有効期間(TTL)の値を秒単位で指定します。このオプションは TTL インデックスにのみ適用されます。詳細については、「TTL によるコレクションのデータ期限設定」を参照してください。 MongoDB 5.0 より前のバージョンで作成された TTL インデックスを使用する場合、または MongDB 5.0 で作成されたデータを 5.0 より前のインストールと同期する場合は、「NaN を使用して構成されたインデックス」を参照して誤った構成の問題を回避してください。 TTLインデックスの | ||||||||||
ブール値 | 任意。 インデックスがクエリ プランナーから非表示かどうかを決定するブール値。 非表示インデックスは、クエリプラン選択手順の一部として評価されません。 デフォルトは、 | |||||||||||
| ドキュメント | 任意。インデックス作成時に、インデックス単位でストレージエンジンを構成できるようにします。
インデックスの作成時に指定されたストレージエンジン構成オプションは、異なるストレージエンジンを使用するノードのあるレプリカセットをサポートするために、レプリケーション中に検証され、oplog に記録されます。 | ||||||||||
| ドキュメント | 任意。 テキストインデックスの場合、フィールドと重みを含むドキュメントが組み合わされます。 重みは1から99までの整数で、 999はスコアに関して他のインデックス付きフィールドと比較したフィールドの重要性を示します。 重みはインデックス フィールドの一部またはすべてに指定できます。 スコアを調整するには、「自己管理型配置のテキスト検索結果への重みの割り当て」を参照してください。 デフォルト値は | ||||||||||
| string | 任意。 テキストインデックスで、ストップワードのリストとステマーとトークナイザのルールを決定する言語。 使用可能な言語については「 自己管理型配置のテキスト検索言語」を、詳細と例については「 自己管理型配置のテキストインデックスのデフォルト言語の指定」を参照してください。 デフォルト値は | ||||||||||
| string | 任意。 テキストインデックスの場合、ドキュメントの上書き言語を含む、コレクション内のドキュメントのフィールド名です。 デフォルト値は | ||||||||||
| integer | 任意。 使用可能なバージョンについては、「自己管理型配置のテキストインデックス バージョン 」を参照してください。 | ||||||||||
| integer | 任意。 使用可能なバージョンについては、「2dsphere インデックス」を参照してください。 | ||||||||||
| integer | |||||||||||
| 数値 | 任意。 2dインデックスで、経度と緯度の境界(下限を含む)。 デフォルト値は | ||||||||||
| 数値 | 任意。 2dインデックスで、経度と緯度の値の境界(上限を含む) デフォルト値は | ||||||||||
| ドキュメント | 任意。インデックスの照合を指定します。 照合を指定すると、大文字・小文字やアクセント記号など、文字列を比較するための言語独自のルールを指定できます。 コレクション レベルで照合を指定した場合、次のようになります。
照合オプションの構文は次のとおりです。 照合を指定する場合、 | ||||||||||
| ドキュメント | 任意。 ユーザーが
ワイルドカード インデックスでは、デフォルトで
|
mongoshはdb.collection.createIndex() コマンドのラッパーとしてメソッドdb.collection.createIndexes()createIndexes と を提供します。
Considerations
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 はインデックスを再度作成することはなく、 1のok値を持つ応答オブジェクトと、インデックスが再作成されなかったことを意味するメモを返します。 例:
{ "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
Stable API V1 を使用する場合
indexes配列では次のフィールドは指定できません。backgroundbucketSizesparsestorageEngine
テキスト インデックスは作成できません。
上記でサポートされていないインデックス タイプは、 厳密モード の クエリ プランナー によって無視されます。たとえば、
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のロック動作の詳細については、「 格納済みコレクションでのインデックス ビルド 」を参照してください。
メモリ使用量の制限
createIndexes は、コレクションでの 1 つ以上のインデックスの構築をサポートしています。createIndexes はメモリとディスク上の一時ファイルの組み合わせを使用してインデックスを構築します。デフォルトのメモリ制限は、createIndexes コマンドあたり 200 メガバイトで、そのコマンドでビルドされたすべてのインデックス間で均等に共有されます。例、1 つの createIndexes コマンドで 10 インデックスをビルドする場合、 MongoDB はデフォルトのメモリ制限である 200 を使用して、各インデックス20 メガバイトをインデックス構築プロセスに割り当てます。メモリ制限に達すると、 MongoDB はビルドを完了するために --dbpath 内の _tmp サブディレクトリに一時ファイルを作成します。
maxIndexBuildMemoryUsageMegabytes パラメーターを使用してメモリ制限を調整できます。メモリ制限を高く設定すると、より早くインデックスビルドを完了できる可能性があります。ただし、システム上の未使用RAMに対してこの制限を高く設定しすぎると、メモリが不足し、サーバーがシャットダウンする可能性があります。
各 createIndexes コマンドには maxIndexBuildMemoryUsageMegabytes の制限があります。デフォルトの maxNumActiveUserIndexBuilds である 3 を使用する場合、すべての同時インデックスビルドの合計メモリ使用量は、maxIndexBuildMemoryUsageMegabytes の値の最大 3 倍に達します。
インデックス オプション
Non-Hidden Option
非表示オプションはインデックスを削除して再度作成することなく変更できます。 非表示オプション を参照してください。
インデックス オプションの変更
既存のインデックスの照合オプションを更新できます。 その他のインデックス オプションを変更するには、 db.collection.dropIndex()を使用して既存のインデックスを削除し、新しいオプションを指定してcreateIndexesを実行します。
照合オプション
同じキーに対して、異なる照合を持つ複数のインデックスを作成できます。同じキー パターンで照合が異なるインデックスを作成するには、ユニークインデックス名を設定する必要があります。
コレクション レベルで照合を指定した場合、次のようになります。
インデックスの作成時に照合を指定しない場合、MongoDB はコレクションのデフォルトの照合でインデックスを作成します。
インデックスの作成時に照合を指定する場合、MongoDB は指定された照合でインデックスを作成します。
Tip
照合の strength を1 または 2 に指定すると、大文字と小文字を区別しないインデックスを作成できます。照合の strength が 1 のインデックスは、発音と大文字・小文字の両方を区別しません。
文字列の比較にインデックスを使用するには、操作で同じ照合も指定する必要があります。つまり、照合順序を持つインデックスでは、操作で異なる照合順序が指定されている場合、インデックス付きフィールドで文字列比較を実行する操作をサポートできません。
警告
照合が構成されたインデックスは、並べ替え順序を実現するために ICU 照合キーを使用するため、照合対応のインデックス キーは、照合のないインデックスのインデックス キーよりも大きくなる可能性があります。
restaurants コレクションには、次のドキュメントがあります。
db.restaurants.insertMany( [ { _id: 1, category: "café", status: "Open" }, { _id: 2, category: "cafe", status: "open" }, { _id: 3, category: "cafE", status: "open" } ] )
restaurantsコレクションには、照合ロケール"fr" を持つ stringフィールドcategory のインデックスがあります。
db.restaurants.createIndex( { category: 1 }, { collation: { locale: "fr" } } )
インデックスと同じ照合を指定する次のクエリでは、インデックスを使用できます。
db.restaurants.find( { category: "cafe" } ).collation( { locale: "fr" } )
ただし、デフォルトで「シンプル」なバイナリー コレータを使用する次のクエリ操作では、インデックスを使用できません。
db.restaurants.find( { category: "cafe" } )
インデックス プレフィックスキーが文字列、配列、および埋め込みドキュメントではない複合インデックスの場合でも、異なる照合を指定する操作では、インデックスを使用してインデックス プレフィックスキーの比較をサポートできます。
たとえば、restaurants コレクションには、数値フィールドの score、price、および 文字列フィールドの category の複合インデックスがあります。このインデックスは、文字列比較用の照合ロケール "fr" を使用して作成されます。
db.restaurants.createIndex( { score: 1, price: 1, category: 1 }, { collation: { locale: "fr" } } )
文字列の比較に "simple" バイナリ照合を使用する次の操作では、インデックスを使用できます。
db.restaurants.find( { score: 5 } ).sort( { price: 1 } ) db.restaurants.find( { score: 5, price: { $gt: Decimal128( "10" ) } } ).sort( { price: 1 } )
次の操作では、"simple" バイナリ照合を使用してインデックス付きの category フィールドで文字列を比較しますが、クエリの score: 5 部分の実行についてはインデックスが使用できます。
db.restaurants.find( { score: 5, category: "cafe" } )
インデックスでインデックス が使用されているかどうかを確認するには、 explain() オプションを指定してクエリを実行します。
重要
ドキュメントキーとの照合(埋め込みドキュメントのキーを含む)では、単純なバイナリ比較が使用されます。つまり、"type.cafe" のようなキーのクエリは、キー "type.cafe" と一致しません。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 } );
ワイルドカード インデックス
ワイルドカード インデックスでは、デフォルトで
_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) が伝わったことを確認するレベルです。
コミットクォーラムでは、プライマリがインデックス構築にコミットする前に、インデックス構築を完了する準備が整っていなければならないノードの数を指定します。対照的に、プライマリがインデックス構築にコミットした時に、書込み保証によって、コマンドが返されるまでにインデックス構築を完了する必要があるノードの数が指定されます。
例
次のコマンドを実行すると、 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 出力の例を示しています。シャーディングされたクラスターでは、createIndexes は raw埋め込みドキュメントを出力します。このドキュメントには、インデックスが構築されている各シャードのドキュメントが含まれます。raw埋め込みドキュメントのキーは、シャード ID と、シャードを構成する個々のノードのホスト名とポートを連結したものです。
{ raw: { 'atlas-2m11gv-shard-1/atlas-2m11gv-shard-01-00.cpfgx.mongodb.net:27017,atlas-2m11gv-shard-01-01.cpfgx.mongodb.net:27017,atlas-2m11gv-shard-01-02.cpfgx.mongodb.net:27017': { numIndexesBefore: 3, numIndexesAfter: 5, createdCollectionAutomatically: false, commitQuorum: 'votingMembers', ok: 1 }, 'atlas-2m11gv-shard-0/atlas-2m11gv-shard-00-00.cpfgx.mongodb.net:27017,atlas-2m11gv-shard-00-01.cpfgx.mongodb.net:27017,atlas-2m11gv-shard-00-02.cpfgx.mongodb.net:27017': { numIndexesBefore: 3, numIndexesAfter: 5, createdCollectionAutomatically: false, commitQuorum: 'votingMembers', ok: 1 } }, ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1743624296, i: 7 }), signature: { hash: Binary.createFromBase64('22j0GK8SIK806T+0OdCY6qYHocM=', 0), keyId: Long('7438621020069560323') } }, operationTime: Timestamp({ t: 1743624296, i: 7 }) }