db.collection.createIndex()
MongoDB とドライバー
このページでは、 mongosh
メソッドについて説明します。MongoDB ドライバーで同等のメソッドを確認するには、ご使用のプログラミング言語の対応するページを参照してください。
定義
db.collection.createIndex(keys, options, commitQuorum)
コレクションにインデックスを作成します。
レプリカセットおよびシャーディングされたクラスターへのインデックス ビルドの影響を最小限に抑えるには、「 レプリカセットでのローリング インデックス ビルド 」で説明されているローリング インデックスのビルド手順を使用してください。
互換性
次の環境でホストされる配置には db.collection.createIndex()
を使用できます。
MongoDB Atlas はクラウドでの MongoDB 配置のためのフルマネージド サービスです
MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン
MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン
構文
createIndex()
メソッドの形式は次のとおりです。
db.collection.createIndex( <keys>, <options>, <commitQuorum>)
createIndex()
メソッドは次のパラメーターを取ります。
Parameter | タイプ | 説明 |
---|---|---|
keys | ドキュメント | フィールドと値のペアを含むドキュメント。フィールドはインデックス キーで、値はそのフィールドのインデックスのタイプを表します。 フィールドに昇順インデックスを作成する場合、 アスタリスク( MongoDB は、次のような多彩なインデックス タイプをサポートしています。 詳細については、「インデックス タイプ」を参照してください。 ワイルドカード インデックスは、ユーザーがカスタム フィールドまたはコレクション内の多種多様なフィールドに対してクエリを実行するワークロードをサポートします。
|
options | ドキュメント | 任意。 インデックスの作成を制御する一連のオプションを含むドキュメント。 詳細については、「オプション 」を参照してください。 |
整数または文字列 | 任意。データを保持する投票レプリカセット ノードの最小数(コミットクォーラム)で、プライマリが 次の値をサポートします。
|
オプション
options
ドキュメントには、インデックスの作成を制御する一連のオプションが含まれています。異なるインデックス タイプには、そのタイプに固有の追加オプションがある場合があります。
同じドキュメント内で複数のインデックスオプションを指定できます。ただし、複数のオプション ドキュメントを指定すると、db.collection.createIndex()
操作は失敗します。
次の db.collection.createIndex()
操作を考えてみましょう。
db.collection.createIndex( { "a": 1 }, { unique: true, sparse: true, expireAfterSeconds: 3600 } )
オプションの仕様がこのように複数のドキュメントに分割されていた場合 ({ unique: true }, { sparse: true, expireAfterSeconds: 3600 }
)、インデックス作成操作は失敗していたでしょう。
すべてのインデックス タイプのオプション
以下のオプションは、特に指定がない限り、すべてのインデックス タイプで使用できます。
Parameter | タイプ | 説明 | |
---|---|---|---|
unique | ブール値 | 任意。インデックス キーの値がインデックスの既存値と一致するドキュメントの挿入または更新をコレクションが受け入れないように、ユニークインデックスを作成します。 ユニークインデックスを作成するには、 このオプションはハッシュされたインデックスには使用できません。 | |
name | string | 任意。インデックスの名前。指定しない場合、MongoDB はインデックス フィールドの名前とソート順序を連結してインデックス名を生成します。 | |
partialFilterExpression | ドキュメント | ||
sparse | ブール値 | 任意。 次のインデックス タイプはデフォルトでスパースであり、このオプションを無視します。
Tip部分インデックスは、スパースインデックスの機能のスーパーセットを提供します。アプリケーションに特別な要件がない限り、スパースインデックスでなく、部分インデックスを使用してください。 | |
expireAfterSeconds | integer | 任意。MongoDB がこのコレクション内のドキュメントを保持する期間を制御するための有効期間(TTL)の値を秒単位で指定します。このオプションは TTL インデックスにのみ適用されます。詳細については、「TTL によるコレクションのデータ期限設定」を参照してください。 MongoDB 5.0 より前のバージョンで作成された TTL インデックスを使用する場合、または MongDB 5.0 で作成されたデータを 5.0 より前のインストールと同期する場合は、「NaN を使用して構成されたインデックス」を参照して誤った構成の問題を回避してください。 TTLインデックスの | |
ブール値 | 任意。インデックスがクエリ プランナーから非表示かどうかを決定するブール値。非表示インデックスは、クエリプランの選択において評価されません。 デフォルトは、 | ||
storageEngine | ドキュメント | 任意。インデックス作成時に、インデックス単位でストレージエンジンを構成できるようにします。
インデックスの作成時に指定されたストレージエンジン構成オプションは、異なるストレージエンジンを使用するノードのあるレプリカセットをサポートするために、レプリケーション中に検証され、oplog に記録されます。 |
照合のオプション
Parameter | タイプ | 説明 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
collation | ドキュメント | 任意。インデックスの照合を指定します。 照合を指定すると、大文字・小文字やアクセント記号など、文字列を比較するための言語独自のルールを指定できます。 コレクション レベルで照合を指定した場合、次のようになります。
照合オプションの構文は次のとおりです。
照合を指定する場合、 |
次のインデックスは単純なバイナリ比較のみをサポートしており、照合はサポートしていません。
text indexes,
2dインデックス、
geoHaystack indexes.
Tip
単純ではない照合順序を持つコレクションにtext
、 2d
、またはgeoHaystack
インデックスを作成するには、インデックスの作成時、 {collation: {locale: "simple"} }
を明示的に指定する必要があります。
照合とインデックスの使用
コレクション レベルで照合を指定した場合、次のようになります。
インデックスの作成時に照合を指定しない場合、MongoDB はコレクションのデフォルトの照合でインデックスを作成します。
インデックスの作成時に照合を指定する場合、MongoDB は指定された照合でインデックスを作成します。
Tip
照合の strength
を1
または 2
に指定すると、大文字と小文字を区別しないインデックスを作成できます。照合の strength
が 1
のインデックスは、発音と大文字・小文字の両方を区別しません。
同じキーに対して、異なる照合を持つ複数のインデックスを作成できます。同じキー パターンで照合が異なるインデックスを作成するには、ユニークインデックス名を設定する必要があります。
文字列の比較にインデックスを使用するには、操作で同じ照合も指定する必要があります。つまり、照合順序を持つインデックスでは、操作で異なる照合順序が指定されている場合、インデックス付きフィールドで文字列比較を実行する操作をサポートできません。
警告
照合が構成されたインデックスは、並べ替え順序を実現するために 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
コレクションには、数値フィールドの score
、price
、および 文字列フィールドの 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" と一致しません。
インデックスのオプションtext
次のオプションはテキストインデックスのみに使用できます。
Parameter | タイプ | 説明 |
---|---|---|
weights | ドキュメント | 任意。 テキストインデックスの場合、フィールドと重みを含むドキュメントが組み合わされます。 重みは1から99までの整数で、 999はスコアに関して他のインデックス付きフィールドと比較したフィールドの重要性を示します。 重みはインデックス フィールドの一部またはすべてに指定できます。 スコアを調整するには、「自己管理型配置のテキスト検索結果への重みの割り当て」を参照してください。 デフォルト値は MongoDB 5.0 以降、重みオプションはテキスト インデックスにのみ使用できます。 |
default_language | string | 任意。 テキストインデックスで、ストップワードのリストとステマーとトークナイザのルールを決定する言語。 使用可能な言語については「 自己管理型配置のテキスト検索言語」を、詳細と例については「 自己管理型配置のテキストインデックスのデフォルト言語の指定」を参照してください。 デフォルト値は english です。 |
language_override | string | 任意。 テキストインデックスの場合、ドキュメントの上書き言語を含む、コレクション内のドキュメントのフィールド名です。 デフォルト値は language です。 例については、「 任意のフィールドを使用してドキュメントの言語を指定する」を参照してください。 |
textIndexVersion | integer | 任意。 利用可能なバージョンについては、「バージョン 」を参照してください。 |
インデックスのオプション2dsphere
次のオプションは 2dsphere インデックスのみに使用できます。
Parameter | タイプ | 説明 |
---|---|---|
2dsphereIndexVersion | integer | 任意。 使用可能なバージョンについては、「バージョン 」を参照してください。 |
インデックスのオプション2d
次のオプションは 2d インデックスに対してのみ使用できます。
インデックスのオプションgeoHaystack
次のオプションはgeoHaystackインデックスのみに使用できます。
Parameter | タイプ | 説明 |
---|---|---|
bucketSize | 数値 | geoHaystackインデックスの場合、ロケーション値をグループ化するユニットの数を指定します。つまり、指定されたユニット数内のロケーション値を相互に同じバケット内でグループ化します。 値は 0 より大きくなければなりません。 |
注意
MongoDB 5.0 で削除
MongoDB 5.0 では、非推奨のgeoHaystackインデックスとgeoSearch
コマンドが排除されます。 代わりに、 またはサポートされている$geoNear
地理空間クエリ演算子 のいずれかを使用した 2 d インデックス を使用してください。
MongoDB インスタンスを 5.0 にアップグレードし、featureCompatibilityVersion を 5.0
に設定すると、既存の geoHaystack インデックスがすべて削除されます。
インデックスのオプションwildcard
次のオプションはワイルドカード インデックスでのみ使用できます。
Parameter | タイプ | 説明 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
wildcardProjection | ドキュメント | 任意。 ユーザーが
ワイルドカード インデックスでは、デフォルトで
|
動作
同時実行性
バージョン 4.2 で変更。
MongoDB は、インデックス構築の開始時と終了時に、指定されたコレクションを取得して保持する最適化されたビルドプロセスを使用します。 コレクションに対する後続のすべての操作は、 createIndex()
が排他ロックを解放するまで待機する必要があります。 createIndex()
では、インデックス構築の大部分の期間中に読み取り操作と書込み操作をインターリーブすることができます。
createIndex()
のロック動作の詳細については、「 格納済みコレクションでのインデックス ビルド 」を参照してください。
既存インデックスの再作成
既存インデックス向けに db.collection.createIndex()
を呼び出す場合、MongoDB はそのインデックスを再度作成しません。
インデックス オプション
照合非対応および非表示オプション
照合オプションは除き、1 つのインデックスオプションセットを使用してインデックスを作成し、その後別のインデックスオプションを使用して同じインデックスを再作成しようとすると、MongoDB はオプションを変更せず、インデックスを再作成しません。
非表示オプションはインデックスを削除して再度作成することなく変更できます。詳細は、「非表示オプション」を参照してください。
その他のインデックス オプションを変更するには、新しいオプションで を実行する前に、db.collection.dropIndex()
db.collection.createIndex()
で既存のインデックスを削除します。
照合オプション
同じキーに対して、異なる照合を持つ複数のインデックスを作成できます。同じキー パターンで照合が異なるインデックスを作成するには、ユニークインデックス名を設定する必要があります。
非表示オプション
既存のインデックスを非表示または再表示するには、次の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 } );
トランザクション
トランザクションがクロスシャード間書込みトランザクション(write transaction)でない場合に、分散トランザクション内にコレクションとインデックスを作成できます。
トランザクションで db.collection.createIndex()
を使用するには、そのトランザクションで読み取り保証(read concern)"local"
を使用する必要があります。読み取り保証レベルを "local"
以外に指定すると、トランザクションは失敗します。
例
単一フィールドでの昇順インデックスの作成
次の例では、フィールド orderDate
に昇順のインデックスを作成しています。
db.collection.createIndex( { orderDate: 1 } )
keys
ドキュメントで複数のフィールドが指定されている場合、createIndex()
で複合インデックスが作成されます。
複数のフィールドでのインデックスの作成
次の例では、orderDate
フィールド(昇順)と zipcode
フィールド(降順)に複合インデックスを作成します。
db.collection.createIndex( { orderDate: 1, zipcode: -1 } )
複合インデックスには、単一のハッシュされたフィールドを含めることができます。複合ハッシュインデックスでは、FeatureCompatibilityVersion を少なくとも 5.0
に設定する必要があります。
次の例では、state
フィールド(昇順)と zipcode
フィールド(ハッシュ)に複合インデックスを作成します。
db.collection.createIndex( { "state" : 1, "zipcode" : "hashed" } )
複合インデックス内のフィールドの順序は、インデックスを使用する sort()
操作をサポートするうえで重要です。
照合が指定されたインデックスの作成
次の例では、 category_fr
という名前のインデックスを作成します。 この例では、ロケールfr
と比較強度2
を指定する照合を使用してインデックスを作成します。
db.collection.createIndex( { category: 1 }, { name: "category_fr", collation: { locale: "fr", strength: 2 } } )
次の例では、照合を伴う date_category_fr
という名前の複合インデックスを作成します。照合は文字列値を持つインデックス キーのみに適用されます。
db.collection.createIndex( { orderDate: 1, category: 1 }, { name: "date_category_fr", collation: { locale: "fr", strength: 2 } } )
照合は、値が文字列であるインデックス キーに適用されます。
MongoDB は、同じ照合ルールを使用するインデックス付きキーに対するクエリまたはソート操作でインデックスを使用できます。詳細については、「照合とインデックスの使用」を参照してください。
ワイルドカード インデックスの作成
バージョン 4.2の新機能
ワイルドカード インデックスを作成するには、 mongod
featureCompatibilityVersionが4.2
である必要があります。 fCV を設定する手順については、「 MongoDB 6.0 配置で機能の互換性バージョンを設定する 」を参照してください。
ワイルドカード インデックスでは、デフォルトで
_id
フィールドが省略されます。_id
フィールドをワイルドカード インデックスに含めるには、wildcardProjection
ドキュメントに明示的に含める必要があります。{ "wildcardProjection" : { "_id" : 1, "<field>" : 0|1 } } _id
フィールドを明示的に含める場合を除き、wildcardProjection
ドキュメントに含むステートメントと除外するステートメントを組み合わせることはできません。ワイルドカード インデックスは、次のインデックス タイプまたはプロパティをサポートしていません。
注意
ワイルドカード インデックスは、ワイルドカード テキスト インデックスとは区別され、互換性もありません。ワイルドカード インデックスは
$text
演算子を使用するクエリをサポートしていません。ワイルドカード インデックスの制限に関する詳細なドキュメントについては、「ワイルドカード インデックスの制限 」を参照してください。
ワイルドカード インデックスの詳細については、「ワイルドカード インデックス」を参照してください。
次に、ワイルドカード インデックスの作成例を示します。
単一フィールドパスでのワイルドカード インデックスの作成
ドキュメントに 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.products_catalog.createIndex( { "product_attributes.$**" : 1 } )
このワイルドカード インデックスを使用すると、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.products_catalog.createIndex( { "$**" : 1 } )
このワイルドカード インデックスを使用すると、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.products_catalog.createIndex( { "$**" : 1 }, { "wildcardProjection" : { "product_attributes.elements" : 1, "product_attributes.resistance" : 1 } } )
キー パターン"$**"
はドキュメント内のすべてのフィールドをカバーしますが、 wildcardProjection
フィールドは 含まれるフィールドのみにインデックスを制限します。 wildcardProjection
の完全なドキュメントについては、 wildcard
インデックスのオプション を参照してください。
フィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。
作成されたインデックスは、 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.products_catalog.createIndex( { "$**" : 1 }, { "wildcardProjection" : { "product_attributes.elements" : 0, "product_attributes.resistance" : 0 } } )
キー パターン"$**"
はドキュメント内のすべてのフィールドをカバーしますが、 wildcardProjection
フィールドは指定されたフィールドをインデックスから除外します。 wildcardProjection
の完全なドキュメントについては、 wildcard
インデックスのオプション を参照してください。
フィールドがネストされたドキュメントまたは配列の場合、ワイルドカード インデックスはドキュメントまたは配列に再帰し、ドキュメントまたは配列内のすべてのスカラー フィールドにインデックスを作成します。
作成されたインデックスは、 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
ノード(コミットクォーラム)でインデックス構築を完了する必要があります。詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。
操作に commitQuorum パラメータを指定して、データを保持する投票ノードの最小数(コミットクォーラム)を設定します。プライマリはインデックスを準備完了とマークする前に、インデックス ビルドを完了する必要があります。createIndex()
デフォルトのコミットクォーラムはvotingMembers
、またはすべてのデータを持つ投票レプリカセット メンバーです。
次の操作を実行すると、コミットクォーラム が "majority"
であるか、データを保持する投票ノードの単純過半数であるインデックスが作成されます。
db.getSiblingDB("examples").invoices.createIndex( { "invoices" : 1 }, { }, "majority" )
プライマリがインデックス構築を準備完了とマークするには、データを保持する単純過半数の投票ノードがインデックス構築をコミットするために「投票」済みである必要があります。インデックス構築と投票プロセスの詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。
詳細情報
MongoDB のインデックスとインデックス作成の詳細については、このマニュアルの インデックス セクションを参照してください。
db.collection.getIndexes()
ではコレクションの既存インデックスの仕様を参照できます。text
インデックスの作成の詳細については、「 自己管理型配置のテキスト インデックス 」を参照してください。地理空間クエリ用の 地理空間インデックス。
データの有効期限を示す TTL インデックス。