Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Fatores operacionais e modelos de dados
Nesta página
A modelagem de dados de aplicativos para o MongoDB deve considerar vários fatores operacionais que afetam o desempenho do MongoDB. Por exemplo, diferentes modelos de dados podem permitir queries mais eficientes, aumentar a taxa de transferência de operações de inserção e atualização ou distribuir atividades para um cluster fragmentado de forma mais eficaz.
Ao desenvolver um modelo de dados, analise todas as operações de leitura e escrita do seu aplicativo em conjunto com as seguintes considerações.
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.
Modelo de dados incorporado
O modelo de dados incorporado combina todos os dados relacionados em um único documento, em vez de normalizar vários documentos e collection. Este modelo de dados facilita as operações atômicas.
Consulte Dados do modelo para operações atômicas para obter um exemplo de modelo de dados que fornece atualizações atômicas para um único documento.
Transação multidocumento
Para modelos de dados que armazenam referências entre partes relacionadas de dados, o aplicativo deve emitir operações separadas de leitura e gravação para recuperar e modificar essas partes relacionadas de dados.
Para situações que exigem atomicidade de leituras e escritos em vários documentos (em uma única coleção ou várias coleções), o MongoDB suporta transações distribuídas, incluindo transações em conjuntos de réplicas e clusters fragmentados.
Para obter mais informações, consulte transações
Importante
Na maioria dos casos, uma transação distribuída incorre em um custo de desempenho maior do que as gravações de um único documento, e a disponibilidade de transações distribuídas não deve substituir o design eficaz do esquema. Em muitos cenários, o modelo de dados desnormalizado (documentos e arrays incorporados) continuará a ser ideal para seus dados e casos de uso. Ou seja, para muitos cenários, modelar seus dados adequadamente minimizará a necessidade de transações distribuídas.
Para considerações adicionais sobre o uso de transações (como limite de tempo de execução e limite de tamanho do oplog), consulte também Considerações de produção.
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 collection em um banco de dados para distribuir os documentos da collection em uma série de instâncias mongod ou shards.
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 shard adequada tem implicações significativas para o desempenho e pode ativar ou impedir o isolamento de queries e o aumento da capacidade de gravação. Embora você possa alterar sua chave de shard posteriormente, é importante considerar cuidadosamente sua escolha de chave de shard.
Consulte Fragmentação e Chaves de fragmentação para obter mais informações.
Índices
Use índices para melhorar o desempenho de queries comuns. Crie í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 dos í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 collections com alta taxa de escrita 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 da 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 Interpretar resultados do plano de explicação. Além disso, a implantação de banco de dados MongoDB pode ajudar a identificar query ineficientes.
Grande número de collections
Em determinadas situações, você pode optar por armazenar informações relacionadas em várias collections em vez de em uma única collection.
Considere uma coleção de amostras logs que armazena documentos de registro para vários ambientes e aplicativos. A coleção logs contém documentos do seguinte formulário:
{ log: "dev", ts: ..., info: ... } { log: "debug", ts: ..., info: ...}
Se o número total de documentos for baixo, você poderá agrupar documentos em coleção por tipo. Para registros, considere manter coleção de registros distintas, como 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 collections não tem multa de desempenho significativa e resulta em desempenho muito bom. Collections 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 collection tem uma sobrecarga mínima de alguns kilobytes.
Cada índice, incluindo o índice no
_id, requer pelo menos 8 kB de espaço para dados.Para cada banco de dados, um único arquivo de namespace (ou seja,
<database>.ns) armazena todos os metadados para esse banco de dados, e cada índice e coleção tem sua própria entrada no arquivo de namespace. Consulte os limites de comprimento do namespace de locais para limitações específicas.
A coleção contém um grande número de documentos pequenos
Considere a incorporação por motivos de desempenho se tiver uma collection com um grande número de documentos pequenos. Se você puder agrupar esses documentos pequenos por algum relacionamento lógico e frequentemente recuperar os documentos por esse agrupamento, considere "enriquecer" os documentos pequenos em documentos maiores que contenham uma array de documentos incorporados.
"Agrupar" 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, "enrolar" documentos e mover campos comuns para o documento maior beneficia o índice nesses campos. Haveria menos cópias dos campos comuns e haverá menos entradas de chave associadas no índice correspondente. Consulte Índices para obter mais informações sobre índices.
No entanto, se, muitas vezes, você só precisa recuperar um subconjunto dos documentos dentro do grupo, "arredondar" os documentos pode não fornecer melhor desempenho. Além disso, se documentos pequenos e separados representam 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. Essa sobrecarga normalmente é insignificante, mas se torna significativa se todos os documentos tiverem apenas alguns bytes, como pode ser o caso se os documentos em sua coleção tiverem apenas um ou dois campos.
Considere as seguintes sugestões e estratégias para otimizar a utilização do armazenamento para essas collections:
Use o campo
_idexplicitamente.Os clientes do MongoDB adicionam automaticamente um campo
_ida cada documento e geram um ObjectId 12-byte exclusivo para o campo_id. 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 do armazenamento, os usuários podem especificar um valor para o campo
_idexplicitamente ao inserir documentos na coleção. Esta estratégia permite que os aplicativos armazenem um valor no campo_idque teria ocupado espaço em outra parte do documento.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 exclusivamente. Se o valor do campo não for único, ele não poderá servir como chave primária, pois haverá colisões na coleção.Use nomes de campo mais curtos.
Observação
Encurtar os nomes dos campos reduz a expressão e não oferece benefícios consideráveis para documentos maiores e quando a sobrecarga do documento não for uma preocupação significativa. Nomes de campo mais curtos não reduzem o tamanho dos índices, pois os índices têm uma estrutura predefinida.
Em geral, não é necessário usar nomes de campo 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_nameparalnamee o campo denominadobest_scoreparascore, como segue, você poderá salvar 9 bytes por documento.{ lname : "Smith", score : 3.9 } Incorporar documentos.
Em alguns casos, você pode consultar incorporar documentos em outros documentos e na sobrecarga por documento. Consulte A coleção 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 documentos após um período de tempo. Considere usar o recurso TTL se seu aplicativo exigir que alguns dados persistam no banco de dados por um período limitado de tempo.
Além disso, se seu aplicativo usar apenas documentos inseridos recentemente, considere Coleções limitadas. As coleções limitadas fornecem gerenciamento primeiro a entrar , primeiro a sair (FIFO) de documentos inseridos e oferecem suporte eficiente a operações que inserem e leem documentos com base na ordem de inserção.