Visualizações materializadas

A representação materializada (MV) é o resultado fisicamente salvo da consulta (agregação/projeção), atualizado periodicamente ou permanentemente e disponível para leituras rápidas. Basicamente, são dados «pré-contados», com o frescor e o custo de leitura controlados.

• Estabilizar a latência da leitura (p95/p99).
• Descarregar tabelas OLTP «quentes».
• Dar um SLA previsível para analistas, API e fic (recomendações, contadores, diretórios).

1) Quando usar MV (e quando não)

• Pedidos pesados frequentemente repetidos (join/agg/window) com atrasos de atualização válidos.
• CQRS/projeções de produto: dashboards, diretórios, listas classificadas, contadores.
• Leitura regional multi: cópias «locais» do resultado.

• A relevância superestrela «por cada gravação» sem uma lógica de compensação → melhores índices/OLTP + dinheiro/streaming.
• Invariantes transacionados complexos ao gravar → MV não substituem transações.

2) MV vs dinheiro vs projeção

Dinheiro: «cópia da resposta», controlado por TTL/deficiência no nível do aplicativo; não há esquema.
MV: «cópia de dados», controlado por DBD/motor; há esquema, índices, transacionalidade refresh.
Projeção (event surcing/CQRS): calculado a partir de eventos; muitas vezes implementado como uma tabela + updates incorporados (isto é, basicamente «MV manual»).

3) Formas de atualização

3. 1 REFRESH de lote (periódico)

Programador (cron/skedooler): 'REFRESH MATERIALIZED VIEW...'.
Os benefícios são apenas previsíveis, baratos. Contras, janelas de descontração.

3. 2 Refresh Enfatal

Delta de chave/janela temporária, upsert's em MV.
Fonte de alterações: CDC (Debezium, logical replication), streaming (Kafka/Flink/Spark), desencadeadores.
Os benefícios são um pequeno atraso e custo. Contras: código mais complicado e consistência.

3. 3 Contínuo (streaming MV)

Em invertebrados/streaming de TCE: fluxos/tabelas materializados (ClickHouse/Kafka, Flink SQL, Materialize, BigQuery MV).
Os benefícios são segundos ou menos. Contras: requer infra estrim e chaves claras/marcas de água.

4) Consistência e «frescura»

A forte consistência do MV acontece quando o refresh é «atômico» (read-switch para a nova versão).
Com mais frequência, bounded estaleness: «no máximo, não mais do que o t/janela». Comunique isso nos contratos API/UX.
Para pagamentos/invariantes rigorosos, mantenha o núcleo de COP no OLTP e use o MV como read-plane.

5) Simulação e esquema

Faça com que o MV seja uma tarefa estreita: uma tarefa é MV.
Guarde as chaves temporárias (event _ time/watermark) e as chaves de negócios (tenant _ id, entity _ id).
Índices sob filtros/triagem frequentes; invertebrados SUBD - sob máquinas/rochas.
Particionamento por data/tenante/região para refresh rápido e retenção.

6) Updates incorporados: pattern upsert projeções

1. Vem uma alteração (CDC/evento).
2. Consideramos o delta para a linha MV (recompute/merge).
3. 'UPSERT' por chave ('tenant _ id, entity _ id, bucket').
4. Atualizamos os metadados de frescura.

A Idempotação é obrigatória, a repetição do delta não deve quebrar o resultado.

7) Exemplos (conceitualmente)

PostgreSQL (refresh de bateria)

sql
CREATE MATERIALIZED VIEW mv_sales AS
SELECT date_trunc('day', created_at) AS day,
tenant_id,
SUM(amount) AS revenue,
COUNT()  AS orders
FROM orders
GROUP BY 1,2;

-- Быстрые чтения
CREATE INDEX ON mv_sales (tenant_id, day);

-- Без блокировок чтения при обновлении
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_sales;

ClickHouse (streaming MV из Kafka)

sql
CREATE TABLE events_kafka (..., ts DateTime, tenant_id String)
ENGINE = Kafka SETTINGS kafka_broker_list='...',
kafka_topic_list='events',
kafka_format='JSONEachRow';

CREATE MATERIALIZED VIEW mv_agg
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(ts)
ORDER BY (tenant_id, toStartOfMinute(ts)) AS
SELECT tenant_id,
toStartOfMinute(ts) AS bucket,
sumState(amount) AS revenue_state
FROM events_kafka
GROUP BY tenant_id, bucket;

BigQuery MV (atualização automática)

sql
CREATE MATERIALIZED VIEW dataset.mv_top_products
AS SELECT product_id, SUM(amount) AS revenue
FROM dataset.orders
WHERE _PARTITIONDATE BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) AND CURRENT_DATE()
GROUP BY product_id;

8) Frescura em interfaces/contratos

Devolva 'X-Data-Freshness: <segunds> '/campo' as _ of '.
Para telas críticas, o botão Atualizar e o crachá atualizado N para trás.
Na API, especifique o SLO de frescura (por exemplo, p95 ≤ 60 c).

9) Multi-tenante e regiões

A chave 'tenant _ id' em MV é obrigatória.
Fairness: quotas de refresh/estirpe por locatário; shedooling grandes MV noite per tenant.
Residency: MV vive na mesma região dos dados primários; A Região Cruzada é só uma unidade.

10) Observabilidade

• `freshness_age_ms` (p50/p95/p99), `refresh_latency_ms`, `rows_processed/s`, `refresh_errors`.
• Tamanho MV/partições, custos de armazenamento.
• Para streaming: liga conector, «água» (watermark), late events.

• Теги: `mv_name`, `tenant_id`, `partition`, `refresh_id`, `delta_size`.
• Relatórios de «recontagens» e feeds por razões (schema mismatch, timeout).

11) Testes e caos

Cortness: comparação de origem MV vs em pré-seleções; Somas de controlo.
Freshness under load: carga de gravação + garantia de frescura SLO.
Schema evolution: adição/renomeamento de campos, «queda» do conector CDC.
Late/Out-of-order: réplicas de eventos, alteração de marca d' água.
Idempotidade: reaproveitamento de delta/batches.

12) Retenschn e custo

Guarde apenas as janelas desejadas (por exemplo, 90 dias); antigas partitações arquivem.
Vácuo regular/merj (por motor).
Reduza o MV para uma API/página específica, evitando o «monstro universal».

13) Segurança e conformidade

Herda políticas de acesso de origem (RLS/LCA) - Não espalhe MV mais amplo do que as tabelas de origem.
Disfarce o PII na construção do MV, especialmente para analistas/logs.
Auditoria de refresh/redraves.

14) Erros típicos

«Um MV enorme para tudo» → caro refresh e fraco isolamento.
Sem índices/partituras, p99 salta, refresh sufoca o cluster.
Uma recontagem completa em vez de delta onde puder ser aumentada.
Frescura não declarada na API/UX → reclamações dos usuários sobre dados «obsoletos».
Ignorar erros schema evolution/CDC → perda de coerência.
Tentar substituir MV por transações: MV - sobre leitura, não sobre operações de gravação rigorosas.

15) Receitas rápidas

Produto de dashboard: MV por minutos/relógio, refresh em + on-demand para VIP, p95 frescura ≤ 60 s.
Catálogo/pesquisa: Projeção incorporada de CDC (upsert), índices de filtros, lag ≤ 5-15 s.
Relatórios Fin: MV de lote com atômico 'REFRESH CONCURRENTLY', somas de controle, 'as _ of' nas respostas.
SaaS global: MV regional, agregação cruzada-regional asincrona.

16) Folha de cheque antes de vender

• O SLA de frescura é definido e está refletido em API/UX.
• O modo selecionado é batch refresh/incorporativo/streaming; são descritas as fontes (CDC/eventos).
• O MV foi projetado «por tarefa», há índices e partituras, o armazenamento é limitado por janela.
• A idempotidade upsert/equipamentos é confirmada por testes; processamento late/out-of-order.
• Observabilidade: métricas de frescura/laje, alertas, trailing refresh.
• Playbooks: Recontagem da partição, redrave após falha no conector, evolução do esquema.
• O acesso e o PII correspondem ao fonte; a auditoria está ativada.
• Custo sob controle: retenha, compressão, tempo da janela de refresh.
• Documentação: o que em MV é verdade, o que é uma camada derivada, a expectativa do negócio.

Conclusão

As apresentações materializadas são um compromisso de engenharia entre a velocidade da leitura e a atualidade. Com um SLA claro de frescura, um padrão correto, atualizações intensificadas e telemetria normal, os MV transformam os pedidos pesados em milissegundos previsíveis - sem sacrifícios de confiabilidade e controle de custos.