SELECT na tabela de destino são rápidas e leves. Visões incrementais oferecem suporte a todas as funções de agregação e escalam bem — até mesmo para petabytes de dados — porque cada consulta opera sobre um subconjunto pequeno e recente do conjunto de dados que está sendo inserido.
Views materializadas atualizáveis, em contraste, são atualizadas em uma programação definida. Essas visões reexecutam periodicamente a consulta completa e sobrescrevem o resultado na tabela de destino. Isso é semelhante às visões materializadas em bancos de dados OLTP tradicionais, como o Postgres.
A escolha entre views materializadas incrementais e atualizáveis depende em grande parte da natureza da consulta, da frequência com que os dados mudam e de se as atualizações da visão precisam refletir cada linha à medida que ela é inserida ou se uma atualização periódica é aceitável. Entender essas compensações é fundamental para projetar visões materializadas escaláveis e de alto desempenho no ClickHouse.
Quando usar visões materializadas incrementais
- Você precisa de resultados de consulta em tempo real, atualizados a cada inserção.
- Você agrega ou filtra grandes volumes de dados com frequência.
- Suas consultas envolvem transformações ou agregações simples em uma única tabela.
Quando usar visões materializadas atualizáveis
Resumo
- Você precisa de resultados de consultas em cache disponíveis instantaneamente, e pequenos atrasos na atualização são aceitáveis.
- Você precisa do top N de um conjunto de resultados de consulta.
- O tamanho do conjunto de resultados não cresce indefinidamente ao longo do tempo. Caso contrário, o desempenho da view de destino se degradará.
- Você está realizando junções complexas ou desnormalização envolvendo várias tabelas, o que exige atualizações sempre que qualquer tabela de origem mudar.
- Você está criando workflows em lote, tarefas de desnormalização ou dependências entre views semelhantes a DAGs do DBT.
Modo APPEND vs REPLACE
APPEND e REPLACE. Esses modos definem como o resultado da consulta da view é gravado quando ela é atualizada.
REPLACE é o comportamento padrão. Cada vez que a view é atualizada, o conteúdo anterior da tabela de destino é totalmente substituído pelo resultado mais recente da consulta. Isso é adequado para casos de uso em que a view deve sempre refletir o estado mais recente, como ao armazenar em cache um conjunto de resultados.
APPEND, por outro lado, permite adicionar novas linhas ao final da tabela de destino em vez de substituir seu conteúdo. Isso viabiliza casos de uso adicionais, como a captura de snapshots periódicos. APPEND é particularmente útil quando cada atualização representa um ponto específico no tempo ou quando se deseja o acúmulo histórico de resultados.
Escolha o modo APPEND quando:
- Você quiser manter um histórico das atualizações anteriores.
- Estiver criando snapshots ou relatórios periódicos.
- Precisar coletar incrementalmente resultados atualizados ao longo do tempo.
REPLACE quando:
- Você precisar apenas do resultado mais recente.
- Dados desatualizados precisarem ser descartados por completo.
- A view representar um estado atual ou uma consulta de referência.
APPEND ao criar uma arquitetura Medallion.