Views virtuais e materializadas
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
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.
LEIA TAMBÉM: Angular: rodando a aplicação no Docker
Comunicação através do banco de dados
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.
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).
LEIA TAMBÉM: SQL Server: como identificar e comprimir tabelas e índices sem compressão de dados
Views virtuais
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:
- Aumentará o tempo de escrita, pois, quando houver a escrita a engine do banco de dados precisará atualizar tal valor.
- Views virtuais são atalhos para queries que irão executar e expandir, sendo assim, ainda teríamos problemas de performance.
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:
- Complexidade para sincronização dos dados
- Duplicação e desnormalização dos dados
- Possíveis inconsistências eventuais (principalmente para arquiteturas distribuídas)
- Possíveis inconsistências de dados (principalmente para arquiteturas distribuídas)
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.