Fatores operacionais e modelos de dados

Atomicidade

No MongoDB, uma operação de escrita é atômica no nível de um único documento, mesmo que a operação modifique vários documentos incorporados em um único documento. Quando uma única operação de gravação modifica vários documentos (por exemplo, db.collection.updateMany()), a modificação de cada documento é atômica, mas a operação como um todo não é atômica.

Fragmentação

O MongoDB usa fragmentação para fornecer dimensionamento horizontal. Esses clusters oferecem suporte a implantações com grandes conjuntos de dados e operações de alta taxa de transferência. A fragmentação permite que os usuários particionem uma coleção em um banco de dados para distribuir os documentos da coleção em uma série de instâncias mongod ou fragmentos.

Para distribuir dados e tráfego de aplicativos em uma coleção fragmentada, o MongoDB usa a chave de fragmento. A seleção da chave de fragmento adequada tem implicações significativas para o desempenho e pode habilitar ou impedir o isolamento da query e o aumento da capacidade de gravação. Embora você possa alterar sua chave de fragmento mais tarde, é importante considerar cuidadosamente sua escolha de chave de fragmento.

Consulte Fragmentação e Chaves de fragmento para obter mais informações.

Indexes

Use índices para melhorar o desempenho de querys comuns. Construa índices em campos que aparecem com frequência em queries e para todas as operações que retornam resultados classificados. O MongoDB cria automaticamente um índice único no campo _id .

Ao criar índices, considere os seguintes comportamentos de índices:

• Cada índice exige pelo menos 8 kB de espaço para dados.

• Adicionar um índice tem algum impacto negativo no desempenho para operações de gravação. Eles são caros para coleções com alta taxa de gravação para leitura, porque cada inserção também deve atualizar quaisquer índices.

• Coleções com alta taxa de leitura para gravação geralmente se beneficiam de índices adicionais. Os índices não afetam as operações de leitura não indexadas.

• Quando ativo, cada índice consome espaço em disco e memória. Esse uso pode ser significativo e deve ser rastreado para o planejamento de capacidade, especialmente para preocupações com o tamanho do conjunto de trabalho.

Consulte Estratégias de indexação para obter mais informações sobre índices, bem como Analisar o desempenho da consulta. Além disso, o analisador de banco de dados MongoDB pode ajudar a identificar queries ineficientes.

Grande número de coleções

Em determinadas situações, você pode optar por armazenar informações relacionadas em várias coleções em vez de em uma única coleção.

Considere uma coleção de amostras logs que armazena documentos de log para vários ambientes e aplicativos. A coleção logs contém documentos com o seguinte formato:

{ log: "dev", ts: ..., info: ... }
{ log: "debug", ts: ..., info: ...}

Se o número total de documentos for baixo, é possível agrupar os documentos em coleções por tipo. Para logs, considere manter coleções distintas de log, por exemplo, logs_dev e logs_debug. A coleção logs_dev conteria somente os documentos relacionados ao ambiente de desenvolvimento.

Geralmente, ter um grande número de coleções não tem penalidade de desempenho significativa e resulta em um desempenho muito bom. Coleções distintas são muito importantes para o processamento em lote de alta taxa de transferência.

Ao usar modelos que têm um grande número de coleções, considere os seguintes comportamentos:

• Cada coleção tem uma sobrecarga mínima de alguns kilobytes.

• Cada índice, incluindo o índice em _id, requer pelo menos 8 kB de espaço de dados.

• Para cada banco de dados, um único arquivo de namespace (ou seja, <database>.ns) armazena todos os metadados desse banco de dados, e cada índice e coleção tem sua própria entrada no namespace. Consulte limites de comprimento de namespace de locais para saber limitações específicas.

Coleção contém grande número de documentos pequenos

Se você tiver uma coleção com um grande número de documento pequenos, deve considerar a incorporação pensando no desempenho. Se for possível agrupar esses documento pequenos por algum relacionamento lógico e se você recupera os documentos desse agrupamento com frequência, é possível pensar em "acumular" os documento pequenos em documento maiores que contenham um array de documentos incorporados.

"Acumular" esses pequenos documentos em agrupamentos lógicos significa que as queries para recuperar um grupo de documentos envolvem leituras sequenciais e menos acessos aleatórios ao disco. Além disso, "acumular" documentos e mover campos comuns para um documento maior beneficia o índice desses campos. Haveria menos cópias dos campos comuns e menos entradas de chave associadas no índice correspondente. Consulte a página Índices para obter mais informações.

No entanto, se você muitas vezes só precisa recuperar um subconjunto dos documentos dentro do grupo, então "enrolar" os documentos pode não fornecer melhor desempenho. Além disso, se documentos pequenos e separados representarem o modelo natural para os dados, você deve manter esse modelo.

Otimização de armazenamento para documentos pequenos

Cada documento MongoDB contém uma certa quantidade de sobrecarga. Este a sobrecarga é normalmente insignificante, mas torna-se significativa se todos Os documentos são apenas alguns bytes, como pode ser o caso se os documentos em sua coleção tem apenas um ou dois campos.

Considere as seguintes sugestões e estratégias para otimizar a utilização do armazenamento para essas coleções:

• Use o campo _id explicitamente.

  Os clientes MongoDB adicionam automaticamente um campo _id a cada documento e geram um 12 ObjectId exclusivo de bytes para o _id campo. Além disso, o MongoDB sempre indexa o campo _id. Para documentos menores, isso pode representar uma quantidade significativa de espaço.

  Para otimizar o uso de armazenamento, os usuários podem especificar um valor para o campo _id explicitamente ao inserir documento na coleção. Essa estratégia permite que os aplicativos armazenem um valor que teria ocupado espaço em outra parte do documento no campo _id.

  Você pode armazenar qualquer valor no campo _id, mas como esse valor serve como chave primária para documentos na coleção, ele deve identificá-los de forma exclusiva. Se o valor do campo não for exclusivo, ele não poderá servir como chave primária, pois haveria colisões na coleção.

• Use nomes de campo mais curtos.

  Observação

  Encurtar nomes de campos reduz a expressividade e não fornece benefício considerável para documentos maiores e onde documento A sobrecarga não é motivo de preocupação significativa. Os nomes de campo mais curtos não reduzem o tamanho dos índices, pois os índices têm uma estrutura pré-definida.

  Em geral, não é necessário usar nomes de campos curtos.

  O MongoDB armazena todos os nomes de campo em todos os documentos. Para a maioria documentos, isso representa uma pequena fração do espaço usado por um documento; no entanto, para documentos pequenos, os nomes dos campos podem representar uma quantidade proporcionalmente grande de espaço. Considere uma coleção de pequeno documento semelhante ao seguinte:

  { last_name : "Smith", best_score: 3.9 }

  Se você reduzir o campo denominado last_name para lname e o campo denominado best_score para score, como a seguir, você poderá salvar 9 bytes por documento.

  { lname : "Smith", score : 3.9 }

• Incorporar documentos.

  Em alguns casos, você pode querer incorporar documentos em outros documentos e salvar na sobrecarga por documento. Consulte Coleção que contém um grande número de documentos pequenos.

Gerenciamento do ciclo de vida dos dados

As decisões de modelagem de dados devem levar em consideração o gerenciamento do ciclo de vida dos dados.

O recurso Time to Live ou TTL das coleções expira os documentos após um período de tempo. Considere usar o recurso TTL se o seu aplicativo exigir que alguns dados persistam no banco de dados por um período limitado de tempo.

Além disso, se seu aplicativo usa apenas documentos inseridos recentemente, considere usar Coleções limitadas. Coleções limitadas oferecem gerenciamento “Primeiro a entrar, primeiro a sair” (PEPS) — em inglês, first-in-first-out (FIFO) — para documento inseridos e suportam com eficiência operações que inserem e leem documentos com base na ordem de inserção.