Melhores práticas para modelagem de dados no MongoDB

O modelo de dados flexível do MongoDB permite equilibrar estrategicamente desempenho e adaptabilidade, garantindo a consistência e a integridade dos dados. Além da orientação geral sobre planejamento de esquema, considere as seguintes práticas recomendadas para otimizar seu modelo de dados e determinar qual padrão de design de esquema pode ser mais adequado para o caso de uso do seu aplicação .

Planeje seu esquema com antecedência e itere

É melhor fazer o planejamento e o design do esquema no início do processo de desenvolvimento do aplicação . Iniciar seu aplicação com boas práticas de modelagem de dados ajuda a evitar problemas de desempenho à medida que seu aplicação cresce. Quando você segue as práticas recomendadas de modelagem de dados antecipadamente e de forma adequada, pode obter um melhor desempenho e facilitar o dimensionamento do seu aplicação no futuro.

Observação

Dependendo do seu aplicação e da importância da otimização, convém priorizar o estabelecimento de um modelo de dados simples e funcional que abranja a funcionalidade básica antes de perder tempo com otimizações.

Modifique seu Modelo de Dados

À medida que as necessidades do aplicação mudam, você deve projetar o esquema iterativamente e modificá-lo. O MongoDB oferece maneiras de modificar seu esquema perfeitamente, sem tempo de inatividade. No entanto, ainda pode ser difícil modificar esquemas de grande escala usados na produção.

Considere o seguinte exemplo:

Você tem a tarefa de criar o backend de uma plataforma online de aprendizado de usuários que armazena informações sobre cursos e suas lições. Inicialmente, a plataforma só precisa armazenar as seguintes informações básicas para cada curso:

Título do curso
Instrutor
Descrição
Lições, incorporadas como uma array de subdocumentos dentro de cada documento do curso. No momento, cada subdocumento de lição contém apenas um título, uma descrição e diafragmas de apresentação.

À medida que a plataforma cresce, cada curso precisa de formatos adicionais de aprendizado e teste, como vídeos, questionários, tarefas e links de recursos externos. Incorporar todos esses novos dados em cada documento de curso tornaria o modelo de dados muito complexo.

Em vez disso, considere criar uma lessons collection separada. Dessa forma, você pode vincular as course lessons coleção e usando IDs de referência. Ao usar referências, cada lição pode incluir diferentes tipos de conteúdo e ser mais flexível para futuras alterações de formato.

Vincular dados relacionados

Ao projetar seu modelo de dados no MongoDB, considere a estrutura de seus documentos e as maneiras como seu aplicativo usa dados de entidades relacionadas.

Para vincular dados relacionados, você pode:

Incorpore dados relacionados em um único documento.
Dados relacionados à referência armazenados em uma coleção separada.

Para obter exemplos de quando usar incorporação ou referência, consulte a tabela a seguir:

Cenário	Método de vinculação
Manter dados relacionados juntos levará a um modelo e código de dados mais simples.	Incorporação
Você tem um relacionamento "has-a" ou "contém" entre entidades.	Incorporação
Seu aplicação query partes de informações juntas.	Incorporação
Você tem dados que geralmente são atualizados juntos.	Incorporação
Você tem dados que devem ser arquivados ao mesmo tempo.	Incorporação
O lado filho do relacionamento tem alta cardinalidade.	Referências
A duplicação de dados é muito complicada de gerenciar e não é preferida.	Referências
O tamanho combinado dos dados ocupa muita memória ou largura de banda de transferência para o aplicação.	Referências
Seus dados incorporados crescem sem limites.	Referências
Seus dados são gravados em momentos diferentes em uma carga de trabalho de gravação pesada.	Referências
Para o lado filho do relacionamento, seus dados podem existir por si mesmos sem um pai.	Referências

Para saber mais sobre casos de uso, considerações de desempenho e benefícios de cada método de vinculação de dados, consulte:

Duplicate Data

Ao incorporar dados relacionados em um único documento, você pode duplicar dados entre duas collections. A duplicação de dados permite que o seu aplicativo consulte informações relacionadas a várias entidades em uma única query, separando logicamente as entidades no seu modelo.

Antes de duplicar dados, considere os seguintes fatores:

O benefício em desempenho das leituras quando os dados estiverem duplicados. A duplicação de dados pode eliminar a necessidade de realizar junções em várias coleções, o que pode melhorar o desempenho do aplicativo.
Com que frequência os dados duplicados precisam ser atualizados. A lógica extra necessária para lidar com atualizações pouco frequentes é menos dispendiosa do que realizar junções (pesquisas) em operações de leitura. No entanto, atualizar dados duplicados com frequência pode causar volumes de trabalho pesados e problemas de desempenho.

A tabela a seguir lista os diferentes tipos de dados duplicados que podem existir em seu esquema:

Tipo de dados duplicados	Descrição	Exemplo
Imutável	Dados que nunca mudam. Dados imutáveis são bons candidatos à duplicação de dados	A data em que uma conta de usuário foi criada.
Temporal	Dados que podem mudar ao longo do tempo, mas onde é importante preservar o valor histórico dos dados.	O endereço de um cliente no momento em que ele fez um pedido. Se o cliente se mudar para um novo endereço, isso não afetará os endereços registrados para onde os pedidos anteriores foram enviados.
Sensível à obsolescência	Dados que exigem atualizações frequentes para garantir que todas as ocorrências dos dados sejam consistentes. Os aplicativos podem usar transações ou triggers para atualizar todas as ocorrências.	O número de itens em estoque para um determinado produto, que precisa ser atualizado toda vez que um cliente faz um pedido do produto.
Não sensível à obsolescência	Dados que podem tolerar a obsolescência por um longo período de tempo. Os aplicativos podem usar um tarefa em segundo plano para atualizar periodicamente todas as ocorrências dos dados com base na obsolescência aceitável e no custo das atualizações.	Uma lista de produtos recomendados para um cliente, que não precisa ser recalculada toda vez que um novo produto é adicionado ao sistema.

Se você não precisar atualizar os dados duplicados com frequência, o trabalho adicional mínimo seria necessário para manter as duas collections consistentes. No entanto, se os dados duplicados forem atualizados com frequência, usar uma referência para vincular dados relacionados pode ser uma abordagem melhor.

Para obter exemplos sobre como a duplicação de dados relacionados pode ajudar a otimizar seu modelo de dados, consulte Gerenciar dados duplicados.

Reforçar a consistência de dados

Se você duplicar dados em seu esquema, precisará decidir como manter seus dados consistentes em várias coleções. Por exemplo, uma plataforma e-commerce provavelmente requer dados atualizados continuamente para fornecer o status em tempo real de seu estoque de produtos. Por outro lado, aplicativos que lidam com dados para decisões estratégias de longo prazo, como análises de mídia social, podem tolerar a leitura de dados ligeiramente obsoletos.

Você pode impor a consistência dos dados em seu aplicação com qualquer um dos seguintes métodos:

Para saber mais sobre cada método de imposição de consistência de dados, seus casos de uso e suas compensações de desempenho, consulte Consistência de dados.

Aplique o esquema com regras de validação

As necessidades de validação de esquema dependem de como os usuários usam seu aplicação. O esquema flexível do MongoDB facilita a evolução do seu modelo de dados, especialmente nos estágios iniciais de desenvolvimento. No entanto, à medida que seu modelo de dados se estabiliza, a validação de esquema pode ser uma maneira útil de garantir que os dados tenham a aparência desejada. A validação de esquema é mais útil para um aplicação estabelecido em que você tem uma boa noção de como organizar seus dados.

Observação

As regras de validação de esquema também são flexíveis, portanto, não precisam cobrir todos os campo de um documento, a menos que seu aplicação exija que o façam.

Você pode usar a validação de esquema nos seguintes cenários:

Para uma coleção events, certifique-se de que o campo start_date seja armazenado apenas como uma data e não como uma string, portanto, os aplicativos de conexão não usam tipos inesperados.
Para uma collection do store, certifique-se de que o campo accepted_credit_cards pertença a uma lista de cartões de crédito aceitos pela sua loja, como ["Visa", "MasterCard", "American Express"]. Essa validação impede que um usuário insira um valor de cartão de crédito não suportado.
Para uma coleta de alunos, certifique-se de que o campo gpa seja sempre um número de ponto flutuante positivo. Esta validação evita erros durante a entrada de dados.

Para saber mais, consulte Validação de esquema.

Indexe campos comumente sujeitos a queries

Ao projetar seu modelo de dados, considere como você acessa e armazena seus dados. Se você frequentemente consultar, filtrar, classificar ou unir campos específicos, considere a criação de índices nesses campos. Com índices, o MongoDB pode:

Retornar resultados da query mais rapidamente
Classifique os resultados com mais eficiência
Otimizar $lookup e $group operações
Reduzir o uso da CPU e da E/S

À medida que seu aplicação cresce, monitore o uso do índice da implantação para garantir que os índices ainda suportem consultas relevantes.

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

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.

Para obter mais informações sobre índices, consulte Estratégias de indexação.

Considerações adicionais

Ao desenvolver um modelo de dados, analise todas as operações de leitura e gravação do seu aplicativo em conjunto com as seguintes considerações.

Atomicidade

No MongoDB, uma operação de gravação é atômica no nível de um único documento, mesmo que a operação modifique vários documentos incorporados em um único documento. Isso significa que, se uma operação de atualização afetar vários subdocumentos, todos esses subdocumentos serão atualizados ou a operação falhará inteiramente e nenhuma atualização ocorrerá.

Um modelo de dados desnormalizado que usa documentos e arrays incorporados combina todos os dados relacionados em um único documento , em vez de normalizar vários documentos e collection. Este modelo de dados permite operações atômicas, em contraste com um modelo normalizado onde as operações afetam vários documentos e collection. Para obter um exemplo de modelo de dados que fornece atualizações atômicas para um único documento, consulte Dados de modelo para operações atômicas.

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.

Gerenciamento do ciclo de vida dos dados

O gerenciamento do ciclo de vida de dados refere-se ao processo de gerenciar dados, desde a criação e o armazenamento até o arquivamento e exclusão. Para garantir a eficiência de custos, o desempenho e a segurança do esquema, considere o gerenciamento do ciclo de vida dos dados ao tomar decisões sobre a modelagem de dados.

Se o seu aplicação exigir que alguns dados persistam no banco de dados por um período limitado de tempo, considere usar o recurso Time to Live ou TTL. Por exemplo, as collections TTL podem ser úteis para gerenciar sessões de login do usuário em um aplicação da web, onde as sessões são definidas para expirar automaticamente após 30 minutos de inatividade. Isso significa que o MongoDB exclui automaticamente os documentos da sessão após o período de tempo especificado, ajudá-lo a manter uma coleção de sessões pequena para uma consulta eficiente.

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.

Restrições de hardware

Ao projetar o schema, considere o hardware do sistema, especialmente a quantidade de RAM disponível. Larger documentos usam mais RAM, o que pode fazer com que seu aplicativo leia do disk e diminua o performance. Quando possível, projete seu esquema para que somente os campos relevantes sejam retornados pelas consultas. Esta prática garante que o conjunto de trabalho da seu aplicativo não cresça desnecessariamente.

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 do armazenamento, você pode especificar explicitamente um valor para o campo _id ao inserir documentos na coleção. Essa estratégia permite que os aplicativos armazenem um valor no campo _id que 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 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
Embora a redução dos nomes dos campo possa reduzir o tamanho do BSON no MongoDB, geralmente é mais eficaz modificar o modelo geral do documento para reduzir o tamanho do BSON. Encurtar os nomes dos campo pode reduzir a expressão e não afeta o tamanho dos índices, pois os índices têm uma estrutura predefinida que não incorpora nomes de campo .
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 consultar incorporar documentos em outros documentos e na sobrecarga por documento. Veja coleções com um grande número de documentos pequenos.

Saiba mais

Para saber mais sobre como estruturar seus documentos e definir seu esquema, consulte o curso Modelagem de dados da Universidade MongoDB .

Voltar

Modelagem de dados

Dados incorporados