Matheus Castiglioni

Views virtuais e materializadas

Atualmente estamos cada vez mais partindo para arquiteturas de sistemas distribuídas e a complexidade dos nossos projetos aumentam, aumentam e aumentam… Em determinados momentos nossos projetos passam de dezenas de registros para milhões (ou mais), porém, os requisitos de negócio permanecem os mesmos, ou seja, ainda precisamos computador e derivar esses milhões de registros.

Provavelmente o que funciona em poucos segundos ou milissegundos (também poderia ser menos ou mais, trata-se apenas de exemplos) com dezenas de registros passou a funcionar em minutos ou horas (também poderia ser menos ou mais, trata-se apenas de exemplos) com milhões de registros.

Para o exemplo e contexto desse post vamos ter o seguinte cenário:

Precisamos informar a quantidade de vendas para nossos produtos, individualmente um por um

Isso poderia ser feito de N maneiras, seja em uma arquitetura distribuída ou não, por exemplo:

Comunicação através de rede com HTTP

Exemplo pedindo dados para um microsserviço

Como vemos na imagem, poderíamos realizar uma requisição HTTP para o serviço responsável por pedidos e aguardar a resposta enquanto eles computam o dado do banco de dados.

Comunicação através do banco de dados

Exemplo conectando em um banco de dados único

Já nesse outro exemplo, ambos os serviços conectam-se em uma única fonte de dados, temos serviços distribuídos, mas, a base de dados permanece única.

Exemplo de monolitico

Por fim e não menos importante, aqui temos um serviço único com base de dados única.

Poderiam haver N outras formas de se desenhar tal fluxo, o ponto aqui não é o fluxo em si, mas, como a informação é obtida. Repare que em todas as situações foi necessário executar uma query para o banco de dados passando a informação do produto e contando todos os pedidos realizados para o mesmo (também existem N soluções, para o contexto do post vamos focar na utilização de views).

Virtual

Uma primeira abordagem poderia ser: Vamos criar uma view virtual no banco de dados que vai realizar tal contagem para nós e deixará o valor salvo. Apesar de ser uma boa solução ela possuí dois pontos negativos, sendo:

  1. Aumentará o tempo de escrita, pois, quando houver a escrita a engine do banco de dados precisará atualizar tal valor.
  2. Views virtuais são atalhos para queries que irão executar e expandir, sendo assim, ainda teríamos problemas de performance.

Exemplo usando view virtual

Materializada

Uma outra abordagem seria a gente criar a trabalhar com views materializadas (materialized views), a única diferença seria que nesse caso os dados seriam replicados e copiados fisicamente para uma outra tabela, dessa forma, quando a busca for realizada apenas essa única tabela será processada e podemos ainda filtrar por produto utilizando índices. Mas, aqui também nem tudo são flores, ainda temos pontos negativos para cada estilo de arquitetura, sendo:

  1. Complexidade para sincronização dos dados
  2. Duplicação e desnormalização dos dados
  3. Possíveis inconsistências eventuais (principalmente para arquiteturas distribuídas)
  4. Possíveis inconsistências de dados (principalmente para arquiteturas distribuídas)

Exemplo usando view materializada

Conclusão

Nesse post entendemos as diferenças e motivações para utilização de views virtuais ou materializadas, cada abordagem possuí seus conjuntos de trade-offs que devem ser analisados e avaliados com calma, as vezes a virtualização fará mais sentido e outras a materialização será mais coerente.

Abraços, até a próxima.

Matheus Castiglioni

Matheus Castiglioni

Apaixonado pelo mundo dos códigos e um eterno estudante, gosto de aprender e saber um pouco de tudo, aquela curiosidade de saber como tudo funciona, tento compartilhar o máximo de conhecimentos adquiridos e ajudar todos aqueles que sou capaz.

comments powered by Disqus