クラスター化されたコレクション

メリット

クラスター化されたコレクションには、クラスター化されていないコレクションと比較して次の利点があります。

• クラスター化されたインデックス キーで範囲スキャンや等価比較を行うクエリなど、セカンダリインデックスを必要としないクラスター化されたコレクションのクエリを高速化します。

• クラスター化されたコレクションはストレージ サイズが小さいため、クエリと一括挿入のパフォーマンスが向上します。

• コレクションをクラスター化すると、セカンダリ TTL（Time To Live）インデックスを作成する必要がなくなります。

  • expireAfterSeconds フィールドを指定する場合、クラスター化されたインデックスは TTL インデックスでもあります。

  • TTL インデックスとして使用するには、_id フィールドがサポートされている日付型である必要があります。「TTL インデックス」を参照してください。

  • クラスター化されたインデックスを TTL インデックスとして使用すると、ドキュメント削除のパフォーマンスが向上し、クラスター化されたコレクションのストレージ サイズが小さくなります。

• クラスター化されたコレクションでは、挿入、更新、削除、クエリのパフォーマンスがさらに向上しています。

  • すべてのコレクションには _id インデックスがあります。

  • クラスター化されていないコレクションには、_id インデックスがドキュメントとは別にストアされます。これには、挿入、更新、削除の場合は 2 回の書き込みと、クエリの場合は 2 回の読み取りが必要です。

  • クラスター化されたコレクションは、インデックスとドキュメントを _id 値の順序でまとめてストアします。このため、挿入、更新、削除には 1 回の書き込みが必要で、クエリには 1 回の読み取りが必要です。

動作

クラスター化されたコレクションには、クラスター化されたインデックスのキー値順にドキュメントが保存されます。 クラスター化されたインデックス キーは{ _id: 1 }である必要があります。

ドキュメントは 1 つの順序でしかストアできないため、1 つのコレクションには 1 つだけのクラスター化されたインデックスを含められます。クラスター化されたインデックスを持つコレクションのみがデータをソート順でストアします。

クラスター化されたインデックス作成し、クラスター化されたコレクションにセカンダリインデックスを追加できます。クラスター化されたインデックスはセカンダリインデックスと異なります。

• クラスター化されたインデックスは、コレクションを作成するときにのみ作成できます。

• クラスター化されたインデックス キーはコレクションとともにストアされます。collStats コマンドによって返されたコレクション サイズには、クラスター化されたインデックス サイズが含まれています。

MongoDB 6.0.7以降では、使用可能なクラスター化されたインデックスが存在する場合、MongoDB クエリ プランナーはクエリ プランニング プロセスでクラスター化されたインデックスをセカンダリ インデックスに対して評価します。 クエリがクラスター化インデックスを使用する場合、MongoDB は有界コレクションスキャン を実行します。

MongoDB 6.0.7より前では、クラスター化されたコレクションにセカンダリインデックスが存在し、そのセカンダリインデックスがクエリで使用できた場合、クエリ プランナーはデフォルトでクラスター化されたインデックスではなくセカンダリインデックスを選択していました。 MongoDB 6.1以前では、クラスター化インデックスを使用するには、クエリオプティマイザがクラスター化インデックスを自動的に選択しないため、ヒントを提供する必要があります。

制限

クラスター化されたコレクションの制限事項:

• クラスター化されたインデックス キーは{ _id: 1 }である必要があります。

• クラスター化されていないコレクションをクラスター化されたコレクションに、またはその逆に変換することはできません。代わりに、次のことができます。

  • $out ステージまたは$merge ステージで1 つの集計パイプラインを使用して、1 つのコレクションからドキュメントを読み取り、別のコレクションに書き込みます。

  • mongodumpを使用してコレクション データをエクスポートし、mongorestore を使用してそのデータを別のコレクションにインポートします。

• クラスター化されたインデックスを隠すことはできません。「非表示のインデックス」を参照してください。

• クラスター化されたコレクションにセカンダリインデックスがある場合、コレクションのストレージ サイズは大きくなります。これは、大きなクラスター化されたインデックス キーを持つクラスター化されたコレクションのセカンダリインデックスは、クラスター化されていないコレクションのセカンダリインデックスよりもストレージサイズが大きい可能性があるためです。

• クラスター化されたコレクションは、上限付きコレクションであってはなりません。

独自のクラスター化されたインデックスのキー値の設定

デフォルトでは、クラスター化されたインデックスのキー値はユニークなドキュメント オブジェクト識別子です。

独自のクラスター化されたインデックスのキー値を設定できます。あなたのキー:

• ユニークな値を含める必要があります。

• 不変である必要があります。

• 順番に増加する値を含める必要があります。これは必須ではありませんが、挿入のパフォーマンスが向上します。

• サイズはできるだけ小さくする必要があります。

  • クラスター化されたインデックスは最大 8 MB のサイズのキーをサポートしますが、それよりはるかに小さいクラスター化されたインデックスのキーの方が最適です。

  • クラスター化されたインデックスのキーが大きいと、クラスター化されたコレクションのサイズが大きくなり、セカンダリインデックスも大きくなります。これにより、クラスター化されたコレクションのパフォーマンスとストレージの利点が低下します。

  • 大きなクラスター化されたインデックスのキーを持つクラスター化されたコレクションのセカンダリインデックスは、クラスター化されていないコレクションのセカンダリインデックスと比較してより多くの領域を使用する場合があります。

例

このセクションでは、クラスター化されたコレクションの例を示します。

db.runCommand( {
   create: "products",
   clusteredIndex: { "key": { _id: 1 }, "unique": true, "name": "products clustered key" }
} )

db.createCollection(
   "stocks",
   { clusteredIndex: { "key": { _id: 1 }, "unique": true, "name": "stocks clustered key" } }
)

db.createCollection(
   "orders",
   { clusteredIndex: { "key": { _id: 1 }, "unique": true, "name": "orders clustered key" } }
)

db.orders.insertMany( [
   { _id: ISODate( "2022-03-18T12:45:20Z" ), "quantity": 50, "totalOrderPrice": 500 },
   { _id: ISODate( "2022-03-18T12:47:00Z" ), "quantity": 5, "totalOrderPrice": 50 },
   { _id: ISODate( "2022-03-18T12:50:00Z" ), "quantity": 1, "totalOrderPrice": 10 }
] )

db.orders.find( { _id: { $gt: ISODate( "2022-03-18T12:47:00.000Z" ) } } )

[
   {
      _id: ISODate( "2022-03-18T12:50:00.000Z" ),
      quantity: 1,
      totalOrderPrice: 10
   }
]

db.runCommand( { listCollections: 1 } )

...
name: 'orders',
type: 'collection',
options: {
   clusteredIndex: {
      v: 2,
      key: { _id: 1 },
      name: 'orders clustered key',
      unique: true
   }
},
...