Atualmente estamos cada vez mais partindo para arquiteturas de sistemas distribuídas e a complexidade dos nossos projetos aumenta, aumenta e aumenta… 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.

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:

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.

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)

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.