Fatores operacionais e modelos de dados
Nesta página
A modelagem de dados de aplicação para o MongoDB deve considerar vários fatores operacionais que impacto o desempenho do MongoDB. Por exemplo, Modelo de dados Realm diferentes podem permitir query 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 asoperaçõ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 incorporados
O modelo de dados Realm combina todos os dados relacionados em um único documento, em vez de se normalizar em vários documentos e collections. 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 multi-documento
Para modelos de dados que armazenam referências entre partes de dados relacionadas, o aplicativo deve emitir operações separadas de leitura e gravação para recuperar e modificar essas partes de dados relacionadas.
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 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
_idexplicitamente.Os clientes MongoDB adicionam automaticamente um campo
_ida cada documento e geram um 12 ObjectId exclusivo de bytes para o_idcampo. 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
_idexplicitamente 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_nameparalnamee o campo denominadobest_scoreparascore, como a seguir, 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 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.