⚡ OLTP vs OLAP
Dois paradigmas fundamentais de bancos de dados. OLTP processa transacoes em tempo real (INSERT, UPDATE, DELETE). OLAP analisa grandes volumes de dados historicos (SELECT com agregacoes massivas). Misturar os dois no mesmo banco e receita para desastre.
🎯 Transacional vs Analitico
OLTP (Online Transaction Processing) e otimizado para operacoes rapidas e pontuais: cadastrar um cliente, registrar uma venda, atualizar estoque. Usa row-store (dados organizados por linha).
OLAP (Online Analytical Processing) e otimizado para varrer milhoes de registros e gerar agregacoes: "qual o faturamento por regiao nos ultimos 3 anos?". Usa column-store (dados organizados por coluna), o que permite comprimir e ler apenas as colunas necessarias.
- • Row-store: Otimo para buscar um registro inteiro (SELECT * WHERE id = X). PostgreSQL, MySQL, Oracle.
- • Column-store: Otimo para agregar uma coluna inteira (SUM, AVG, COUNT). BigQuery, Redshift, ClickHouse.
- • Hibrido (HTAP): Tenta combinar ambos. TiDB, CockroachDB, AlloyDB. Complexo mas promissor.
✅ FACA
- • Separe cargas OLTP e OLAP em bancos distintos
- • Use replicas de leitura para queries analiticas
- • Avalie column-store para dashboards pesados
- • Defina SLAs diferentes para cada carga
❌ NAO FACA
- • Rodar relatorios pesados no banco de producao
- • Achar que um unico banco resolve tudo
- • Ignorar latencia de escrita em sistemas OLAP
- • Confundir row-store lento com "banco ruim"
📦 Particionamento
Particionamento divide uma tabela grande em pedacos menores (particoes) baseados em um criterio. O banco sabe em qual particao buscar, evitando varrer a tabela inteira. Essencial para tabelas com milhoes ou bilhoes de linhas.
💻 Particionamento por Range (PostgreSQL)
CREATE TABLE pedido (
id SERIAL,
total NUMERIC,
criado_em DATE
) PARTITION BY RANGE (criado_em);
CREATE TABLE pedido_2024 PARTITION OF pedido
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
CREATE TABLE pedido_2025 PARTITION OF pedido
FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');🔍 Tipos de Particionamento
Range
Divide por faixas de valor (datas, IDs). O mais comum. Ideal para dados temporais.
Hash
Distribui uniformemente por hash de uma coluna. Bom para balancear carga entre particoes.
List
Divide por valores discretos (pais, status, categoria). Cada valor vai para sua particao.
💡 Dica Pratica
Particione somente tabelas com milhoes de registros. Tabelas pequenas nao se beneficiam e o overhead de gerenciar particoes nao vale. A coluna de particao deve estar presente em praticamente todas as queries com WHERE para que o partition pruning funcione.
🗄️ Arquivamento e Retencao
Dados nao podem ficar no banco para sempre. Politicas de retencao definem quanto tempo manter cada tipo de dado. Arquivamento move dados antigos para storage mais barato. E questao de compliance, custo e performance.
🎯 Compliance: LGPD e GDPR
Leis de protecao de dados exigem que dados pessoais sejam mantidos apenas pelo tempo necessario. Guardar dados alem do necessario e risco juridico e financeiro.
- • LGPD (Brasil): Dados pessoais devem ser eliminados quando a finalidade for atingida ou o consentimento revogado
- • GDPR (Europa): Principio de minimizacao - colete e retenha apenas o estritamente necessario
- • Cold Storage: Dados historicos podem ir para storage barato (S3 Glacier, Azure Archive) com acesso eventual
- • Purge Jobs: Jobs agendados que removem dados expirados automaticamente. Sem purge, o banco so cresce.
💡 Dica Pratica
Crie uma tabela de politicas de retencao que mapeie cada tipo de dado ao seu prazo maximo. Implemente um cron job (ou pg_cron) que roda semanalmente, verifica os prazos e executa o arquivamento/purge automaticamente. Documente tudo - auditorias vao pedir.
📊 Data Warehouse
Um Data Warehouse e um repositorio centralizado otimizado para consultas analiticas. Enquanto bancos OLTP servem a aplicacao, o DW serve o business intelligence. Dados de multiplas fontes sao consolidados em um modelo otimizado para analise.
🎯 Star Schema
O modelo mais usado em Data Warehouses. Uma tabela fato central (metricas, eventos) cercada por tabelas dimensao (contexto descritivo).
Tabela Fato (fact)
Contem metricas quantitativas: valor da venda, quantidade, custo. Chaves estrangeiras para dimensoes. Muitas linhas, poucas colunas.
Tabela Dimensao (dim)
Contem atributos descritivos: nome do produto, cidade, categoria. Poucas linhas, muitas colunas. Responde "quem, o que, onde, quando".
🔍 Ecossistema Data Warehouse
- BigQuery (Google): Serverless, column-store, paga por query. Escala automaticamente.
- Redshift (AWS): Cluster gerenciado, column-store, integracao nativa com S3.
- Snowflake: Multi-cloud, separa storage de compute, concurrency nativa.
- ClickHouse: Open source, extremamente rapido para agregacoes, usado por Cloudflare e Uber.
🔄 ETL e Pipelines
ETL (Extract, Transform, Load) e o processo de mover dados entre sistemas. Dados brutos saem da origem, sao limpos e transformados, e carregados no destino. Sem pipeline confiavel, seu Data Warehouse e lixo com interface bonita.
🔍 ETL vs ELT
ETL (classico)
Transforma antes de carregar. Dados chegam limpos no destino. Mais controle, mais lento. Ferramentas: Airflow, Informatica, Talend.
ELT (moderno)
Carrega bruto e transforma no destino (que tem poder computacional). Mais rapido, mais flexivel. Ferramentas: dbt, Fivetran + BigQuery.
🔄 Pipeline ETL em 3 Etapas
Extract (Extrair)
Coleta dados das fontes: APIs, bancos OLTP, arquivos CSV, logs, webhooks. O objetivo e capturar tudo sem perder nada. Incremental e melhor que full load.
Transform (Transformar)
Limpa, normaliza, agrega e enriquece os dados. Remove duplicatas, padroniza formatos, calcula metricas derivadas. dbt e a ferramenta referencia para transformacoes em SQL.
Load (Carregar)
Insere os dados transformados no destino (Data Warehouse, Data Lake). Pode ser batch (diario/horario) ou streaming (tempo real com Kafka/Kinesis).
💡 Dica Pratica
Comece com Airflow para orquestrar pipelines e dbt para transformacoes SQL. Ambos sao open source e o padrao de mercado. Sempre implemente data quality checks entre as etapas - dados ruins propagados pelo pipeline contaminam tudo downstream.
📡 Observabilidade
Observabilidade e a capacidade de entender o estado interno do banco atraves de sinais externos. Os tres pilares: metricas, logs e traces. Banco sem monitoramento e bomba-relogio. Quando o incidente acontecer - e vai acontecer - voce precisa saber onde olhar.
🎯 Os 3 Pilares da Observabilidade
Metricas
Numeros ao longo do tempo: latencia p95/p99, throughput (queries/s), conexoes ativas, uso de disco, cache hit ratio. pg_stat_statements e essencial.
Logs
Registros de eventos: queries lentas, erros, deadlocks, autovacuum. Configure log_min_duration_statement para capturar slow queries automaticamente.
Traces
Rastreamento fim-a-fim de uma requisicao: do frontend ao banco e volta. Identifica gargalos na cadeia completa. OpenTelemetry e o padrao.
🚨 Falhas Comuns de Monitoramento
- • Alertas so para "disco cheio": Quando o alerta dispara, ja e tarde. Monitore taxa de crescimento, nao apenas uso absoluto.
- • Sem baseline: Se voce nao sabe o que e "normal", nao consegue detectar anomalias. Colete metricas por semanas antes de definir thresholds.
- • Alert fatigue: 200 alertas/dia = zero alertas uteis. Priorize e silencie ruido. Menos alertas, mais acao.
- • Monitorar so o banco: O problema pode estar na rede, na app, no connection pool. Observabilidade e fim-a-fim.
🏛️ Governanca
Governanca de dados e o framework de politicas, processos e responsabilidades que garante que dados sejam tratados como ativo estrategico. Sem governanca, dados viram lixo caro. Qualidade, seguranca e compliance dependem dela.
🎯 Pilares da Governanca
- • Data Catalog: Inventario de todos os datasets, tabelas, colunas, owners e descricoes. "Que dados temos e onde estao?" DataHub, Amundsen, OpenMetadata.
- • Data Lineage: Rastreamento da origem e transformacao dos dados. "De onde veio esse numero no relatorio?" Essencial para auditoria e debug.
- • RBAC (Role-Based Access Control): Cada pessoa/sistema acessa apenas o que precisa. Principio do menor privilegio. GRANT/REVOKE no PostgreSQL.
- • Classificacao de dados: Publico, interno, confidencial, restrito. Cada nivel com regras de acesso, retencao e criptografia diferentes.
- • Auditoria: Logs de quem acessou o que, quando e por que. Requisito legal (LGPD/GDPR) e base para investigacao de incidentes.
💡 Dica Pratica
Governanca nao precisa comecar grande. Primeiro passo: documente quem e o owner de cada tabela/dataset. Segundo: implemente RBAC basico com roles no banco. Terceiro: ligue audit logging. Esses tres passos ja cobrem 80% do que auditorias pedem.