Pular para o conteúdo
thiagoetipadrões

Contatos

apps/data-patterns/materialized-view

085 · Dados & Persistência · ≈ 5 min de estudo

Materialized View

A view materializada guarda o resultado de uma agregação cara como tabela, recalculada só no refresh. O dashboard lê o número pronto em vez de agregar milhares de lançamentos a cada acesso; o preço é ler dado da última atualização. É um read model do CQRS mantido pelo próprio PostgreSQL.

passos
5
arquivos
7
teste
1
tecnologias
4
Infraestrutura realTypeScriptBunPostgreSQLDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Banco digital com dashboard de movimentação: por conta, total, quantidade e ticket médio de cada mês, e o ranking das contas que mais movimentaram no mês. Agregar 100 mil lançamentos a cada acesso é caro; a view pré-computa o agregado e o job o atualiza a cada minuto.

Planta

Sequência
7/7
INSERT PIX, TED, boleto1resumo mensal da conta2números do último refresh e refreshedAt3REFRESH MATERIALIZED VIEW CONCURRENTLY4leituras continuam na versão anterior durante o refreshregistra o refresh em summary_refreshes5resumo mensal da conta6números novos7Core bancáriotransactionsJob de refreshtransaction_monthly_summaryDashboard
7

7 passos — reproduza para seguir o fluxo

Como funciona

5 passos

Consulta pré-calculada, pronta para leitura.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    transactions recebe os lançamentos em centavos; é a fonte da verdade

  2. 02

    transaction_monthly_summary agrega por conta e mês no fuso de São Paulo, com índice único (account_id, month)

  3. 03

    O job roda REFRESH ... CONCURRENTLY: monta o resultado novo à parte e aplica só a diferença, sem bloquear leitores — o índice único é o que permite isso

  4. 04

    Cada refresh fica em summary_refreshes; a consulta devolve refreshedAt para o dashboard mostrar a idade do dado

  5. 05

    Lançamento novo ou apagado só aparece no próximo refresh

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

  • Leitura de agregado pesado em milissegundos

  • Refresh concorrente não bloqueia leitores

  • Sem código de sincronização: o banco mantém

Custos

  • Dado tem a idade do último refresh

  • Refresh recalcula tudo: custo cresce com o volume

  • Exige índice único para o modo concorrente

apps/data-patterns/materialized-view

7 arquivos

sql/

  • 01_schema.sqlschematransactions, a view materializada com índice único e summary_refreshes

src/

  • refresh_summary.tsRefresh concorrente e registro do horário
  • query_summary.tsResumo da conta com refreshedAt
  • seed_transaction.tsVolume de lançamentos gerado pelo banco
  • demo.tsdemoRanking ao vivo contra a view e dado desatualizado até o refresh
  • refresh_summary.test.tstesteDesatualização, igualdade com a agregação ao vivo, leitura durante refresh contra PostgreSQL real

src/config_summary.ts / src/

  • pool_summary.tsAmbiente validado e pool

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. bun install# dependências
  3. bun run demo# roda o cenário
  4. bun run test# integração contra o serviço real

Job contínuo: bun run refresh.

Requisitos
BunDocker
Sobe junto
PostgreSQL

Relações

Onde ele se encaixa

Mapa
  1. vem antesCQRS
  2. Materialized View
  • Vem antes1
  • Combina com2

L5Eventos e histórico· estação 6 de 6

← CQRSfim da linha

Por que se relacionam

Vem antes

Combina com

Teste rápido

Qual padrão vem antes de Materialized View?

Próximo projeto · Dados & PersistênciaChange Data Capture (CDC)
Esc

↑ ↓ navegarEnter abrir191 resultados