Clustered Collections

Benefícios

As coleções clusterizadas têm os seguintes benefícios em comparação com as coleções não clusterizadas:

• Consultas mais rápidas sobre coletas agrupadas sem a necessidade de um índice secundário, como consultas com varreduras de faixa e comparações de igualdade na chave de índice agrupada.

• As Clustered collections têm um tamanho de armazenamento menor, o que melhora o desempenho para queries e inserções em massa.

• Clustered collections podem eliminar a necessidade de um índice secundário TTL (Time to Live).

  • Um índice clusterizado também é um índice TTL se você especificar o campo expireAfterSeconds.

  • Para ser utilizado como um índice TTL, o campo _id deve ser um tipo de data compatível. Consulte Índices TTL.

  • Se você utilizar um índice clusterizado como índice TTL, ele melhorará o desempenho da exclusão de documentos e reduzirá o tamanho do armazenamento da clustered collection.

• As Clustered collections têm melhorias de desempenho adicionais para entradas, atualizações, exclusões e queries.

  • Todas as coletas possuem um índice _id.

  • Uma coleta não agrupada armazena o índice _id separadamente dos documentos. Isso requer duas gravações para inserções, atualizações e exclusões e duas leituras para consultas.

  • Uma coleta agrupada armazena o índice e os documentos juntos em _id ordem de valor. Isso requer uma gravação para inserções, atualizações e exclusões e uma leitura para consultas.

Comportamento

Coleções clusterizadas armazenam documentos ordenados pelo valor-chave do índice clusterizado. A chave do índice clusterizado deve ser { _id: 1 }.

Você só pode ter um índice clusterizado em uma collection porque os documentos só podem ser armazenados em uma ordem. Somente coleções com um índice clusterizado armazenam os dados em uma ordem definida.

Você pode ter um índice clusterizado e adicionar índices secundários a uma clustered collection. Os índices clusterizados são diferentes dos índices secundários:

• Um índice agrupado só pode ser criado quando você criar a coleta.

• As chaves do índice clusterizado são armazenadas com a collection. O tamanho da collection retornado pelo comando collStats inclui o tamanho do índice clusterizado.

A partir do MongoDB 6.0.7, se existir um índice clusterizado utilizável, o planejador de query do MongoDB avaliará o índice clusterizado em relação aos índices secundários no processo de planejamento de query. Quando uma query utiliza um índice clusterizado, o MongoDB executa uma verificação limitada da coleção .

Antes do MongoDB 6.0.7, se um índice secundário existisse em uma coleção clusterizada e o índice secundário pudesse ser usado por sua query, o planejador de queries selecionava o índice secundário em vez do índice clusterizado por padrão. No MongoDB 6.1 e versões anteriores, para utilizar o índice clusterizado, você deve fornecer uma dica, pois o otimizador de query não seleciona automaticamente o índice clusterizado.

Limitações

Limitações da clustered collection:

• A chave do índice clusterizado deve ser { _id: 1 }.

• Não é possível transformar uma collection não clusterizada em uma clustered collection ou vice-versa. Em vez disso, você pode:

  • Ler documentos de uma collection e escrever em outra usando um aggregation pipeline com uma etapa $out ou uma etapa $merge.

  • Exportar os dados da coleção com o mongodump e importar os dados para outra coleção com mongorestore.

• Não é possível ocultar um índice clusterizado. Consulte Índices ocultos.

• Se houver índices secundários para a coleta agrupada, a coleta terá um tamanho de armazenamento maior. Isso ocorre porque os índices secundários em uma coleta clusterizada com chaves de índice clusterizadas grandes podem ter um tamanho de armazenamento maior do que os índices secundários em uma coleta não clusterizada.

• Coletas agrupadas não podem ser coletas mapeadas.

Definir seus próprios valores-chave de índice clusterizado

Por padrão, os valores de chave de índice clusterizados são os identificadoresexclusivos de objeto de documento.

É possível definir seus próprios valores de chave de índice clusterizado. Sua chave:

• Deve conter valores únicos.

• Deve ser imutável.

• Deve conter valores crescentes sequencialmente. Isso não é obrigatório, mas melhora o desempenho da inserção.

• Deve ter o menor tamanho possível.

  • Um índice agrupado suporta chaves de até 8 MB em tamanho, mas uma chave de índice agrupada muito menor é melhor.

  • Uma chave de índice clusterizada grande faz com que a clustered collection aumente de tamanho, e os índices secundários também são maiores. Isso reduz os benefícios de desempenho e armazenamento da clustered collection.

  • Índices secundários em coletas clusterizadas com chaves de índice clusterizadas grandes podem usar mais espaço em comparação com índices secundários em coletas não clusterizadas.

Exemplos

Esta seção mostra exemplos de coleta clusterizadas.

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
   }
},
...