Construindo com Padrões: Um Resumo

Ao encerrarmos a série Construindo com Padrões, é uma boa oportunidade para recapitular os problemas que os padrões abordados resolvem e destacar alguns dos benefícios e vantagens de cada padrão. A pergunta mais frequente sobre padrões de design de esquema é “Estou projetando um aplicativo para fazer X, como faço para modelar os dados?” Como esperamos que você tenha descoberto ao longo desta série de blogs, há muitas coisas a serem levadas em consideração para responder a isso. No entanto, incluímos exemplos de Charts de casos de uso que consideramos úteis para fornecer pelo menos alguma orientação inicial sobre padrões de modelagem de dados para casos de uso genéricos.

Exemplos de casos de uso

Os Charts abaixo são uma diretriz do que descobrimos após anos de experiência trabalhando com nossos clientes sobre quais padrões de design de esquema são usados em diversos aplicativos. Este não é um conjunto de regras “definidas” sobre qual padrão de design pode ser usado para um tipo específico de aplicação. Certifique-se de observar aqueles que são usados com frequência em seu caso de uso. No entanto, não descarte os outros, eles ainda podem ser aplicados. A maneira como você projeta o esquema de dados do seu aplicativo depende muito dos seus padrões de acesso aos dados.

Resumos de padrões de design

Aproximação

O Padrão de Aproximação é útil quando cálculos caros são feitos com frequência e quando a precisão desses cálculos não é a prioridade mais alta.

Prós

• Menos gravações no banco de dados.
• Mantenha números estatisticamente válidos.

Contras

• Os números exatos não estão sendo representados.
• A implementação deve ser feita na aplicação.

Atributo

O Padrão de Atributo é útil para problemas baseados em documentos grandes com muitos campos semelhantes, mas há um subconjunto de campos que compartilham características comuns e queremos classificar ou consultar esse subconjunto de campos. Quando os campos que precisamos classificar são encontrados apenas em um pequeno subconjunto de documentos. Ou quando ambas as condições forem atendidas nos documentos.

Prós

• Menos índices são necessários.
• As consultas tornam-se mais simples de escrever e geralmente mais rápidas.

Balde

O Bucket Pattern é uma ótima solução para quando você precisa managed dados de streaming, como Time Series, Real-Time Analytics ou aplicativos de Internet das Coisas (IoT).

Prós

• Reduz o número total de documentos em uma collection.
• Melhora o desempenho do índice.
• Pode simplificar o acesso aos dados aproveitando a pré-agregação.

Calculado

Quando há padrões de acesso a dados com muita leitura e esses dados precisam ser computados repetidamente pelo aplicativo, o Padrão Computado é uma ótima opção a ser explorada.

Prós

• Redução na carga de trabalho da CPU para cálculos frequentes.
• As consultas tornam-se mais simples de escrever e geralmente mais rápidas.

Contras

• Pode ser difícil identificar a necessidade desse padrão.
• A aplicação ou uso excessivo do padrão deve ser evitado, a menos que seja necessário.

Versionamento de documentos

Quando você se depara com a necessidade de manter versões anteriores de documentos no MongoDB, o padrão Document Versioning é uma solução possível.

Prós

• Fácil de implementar, mesmo em sistemas existentes.
• Nenhum impacto no desempenho nas consultas da revisão mais recente.

Contras

• Dobra o número de gravações.
• As consultas precisam direcionar a collection correta.

Referência estendida

Você achará o padrão Extended Reference mais útil quando seu aplicativo estiver passando por muitas operações JOIN para reunir dados acessados com frequência.

Prós

• Melhora o desempenho quando há muitas operações JOIN.
• Leituras mais rápidas e redução no número geral de JOINs.

Contras

• Duplicação de dados.

Ponto fora da curva

Você acha que existem algumas consultas ou documentos que não se enquadram no restante dos seus padrões de dados típicos? Essas exceções estão orientando sua solução de aplicativo? Nesse caso, o Padrão Outlier é uma solução maravilhosa para esta situação.

Prós

• Impede que alguns documentos ou consultas determinem a solução de um aplicativo.
• As consultas são adaptadas para casos de uso “típicos”, mas os valores discrepantes ainda são abordados.

Contras

• Muitas vezes adaptado para consultas específicas, portanto, consultas ad hoc podem não ter um bom desempenho.
• Grande parte desse padrão é feito com código de aplicativo.

Pré-alocação

Quando você conhece a estrutura do seu documento e sua aplicação precisa simplesmente preenchê-lo com dados, o Padrão de Pré-Alocação é a escolha certa.

Prós

• Simplificação do design quando a estrutura do documento é conhecida antecipadamente.

Contras

• Simplicidade versus desempenho.

Polimórfico

O Padrão Polimórfico é a solução quando há uma variedade de documentos que possuem mais semelhanças do que diferenças e os documentos precisam ser mantidos em uma única collection.

Prós

• Fácil de implementar.
• As consultas podem ser executadas em uma única collection.

Versionamento de esquema

Praticamente todos os aplicativos podem se beneficiar do Padrão de Versionamento de Esquema, já que alterações no esquema de dados ocorrem frequentemente durante a vida útil de um aplicativo. Esse padrão permite que versões anteriores e atuais de documentos existam lado a lado em uma collection.

Prós

• Não é necessário tempo de inatividade.
• Controle de migração de esquema.
• Redução da dívida técnica futura.

Contras

• Podem ser necessários dois índices para o mesmo campo durante a migração.

Subconjunto

O padrão de subconjunto resolve o problema de o conjunto de trabalho exceder a capacidade da RAM devido a documentos grandes que possuem muitos dos dados do documento que não estão sendo usados pelo aplicativo.

Prós

• Redução no tamanho geral do conjunto de trabalho.
• Menor tempo de acesso ao disco para os dados usados com mais frequência.

Contras

• Devemos managed o subconjunto.
• A obtenção de dados adicionais requer viagens adicionais ao banco de dados.

Árvore

Quando os dados são de uma estrutura hierárquica e são frequentemente consultados, o Tree Pattern é o padrão de design a ser implementado.

Prós

• Maior desempenho evitando múltiplas operações JOIN.

Contras

• As atualizações no gráfico precisam ser managed no aplicativo.

Conclusão

Como esperamos que você tenha visto nesta série, o modelo de documento MongoDB oferece muita flexibilidade na forma como você modela dados. Essa flexibilidade é incrivelmente poderosa, mas esse poder precisa ser aproveitado em termos dos padrões de acesso aos dados do seu aplicativo. Lembre-se de que o design do esquema no MongoDB tem um impacto tremendo no desempenho do seu aplicativo. Descobrimos que os problemas de desempenho podem frequentemente ser atribuídos a um design de esquema inadequado.

Tenha em mente que para aumentar ainda mais o poder do modelo de documento, esses padrões de design de esquema podem ser usados juntos, quando e se fizer sentido. Por exemplo, o Schema Versioning pode ser usado em conjunto com qualquer outro padrão à medida que seu aplicativo evolui. Com os doze padrões de design de esquema abordados, você tem as ferramentas e o conhecimento necessários para aproveitar o poder da flexibilidade do modelo de documento.