Banco de dados

Folha de revisão · 3 temas · Engenharia de Analytics

Feita para a véspera. Imprimir esta página tira o menu e as abas.

Relacional e NoSQL: ACID, BASE e a escolha real

É o tema em que se vê se a pessoa decide por moda ou por requisito. A banca pergunta 'quando você usaria NoSQL' esperando ouvir padrão de acesso, escala e tolerância a inconsistência temporária, não 'quando o dado não tem esquema'. Erro comum é explicar CAP errado, dizendo que se escolhe duas das três.

Como cai: Quando você usaria um banco NoSQL em vez de um relacional, e o que perderia?

Erros comuns

Dizer que o teorema CAP permite escolher duas das três propriedades. Em sistema distribuído, partição de rede acontece; a escolha real é entre consistência e disponibilidade quando ela ocorre.
Achar que NoSQL significa 'sem esquema'. Significa que o esquema não é imposto pelo banco; ele continua existindo, e passa a ser responsabilidade da aplicação e da governança.
Tratar BASE como ausência de garantias. É um conjunto diferente: disponibilidade em primeiro lugar e consistência que converge com o tempo, o que é adequado para muitos casos e inadequado para transferência de dinheiro.
Escolher NoSQL por volume sem olhar o padrão de acesso. O ganho vem de conhecer a consulta antes de modelar; sem isso, o mesmo volume vira consulta cara e varredura.
Esquecer que bancos relacionais escalam bem verticalmente e com réplicas de leitura. Nem todo problema de escala exige trocar de paradigma.
Dizer que relacional não serve para JSON. Postgres e outros tratam JSON com índices há anos; a escolha é de padrão de acesso e escala, não de formato.

Vocabulário

BASE: — Basically Available, Soft state, Eventually consistent. Prioriza responder sempre, aceitando que as réplicas fiquem temporariamente diferentes e convirjam depois.

SQL para engenharia de dados

SQL é o único tema em que a banca pode pedir para você escrever ou descrever a consulta na hora. É teste de fluência: quem hesita entre ROW_NUMBER e GROUP BY entrega que usa SQL só para conferir resultado, não para transformar dado.

Como cai: Como você pegaria a última transação de cada conta?

Erros comuns

Usar NOT IN com subconsulta que pode retornar NULL. Um único NULL faz a condição virar desconhecida e o resultado volta vazio. NOT EXISTS não tem esse problema.
Achar que GROUP BY resolve 'a última transação de cada conta'. GROUP BY colapsa a linha e você perde as outras colunas; o certo é ROW_NUMBER particionado pela conta.
Filtrar window function no WHERE. A janela é avaliada depois do WHERE; ou você envolve numa CTE e filtra fora, ou usa QUALIFY onde o motor suporta.
Confundir RANK com DENSE_RANK e com ROW_NUMBER. Em empate, ROW_NUMBER desempata arbitrariamente, RANK pula posições e DENSE_RANK não pula.
Pedir índice para tabela analítica em Parquet. Em Spark SQL e Athena não existe índice como no OLTP; o que ganha é particionamento, ordenação de arquivos e poda por estatística.
Empilhar subquery aninhada onde uma CTE resolveria. Além de ilegível, dificulta reaproveitar o mesmo bloco e conversar sobre o plano com outra pessoa.

Vocabulário

window function: — Função que calcula um valor por linha olhando um conjunto de linhas relacionadas (a janela), sem colapsar o resultado como o GROUP BY faz.

Modelagem de dados

Modelagem é onde a banca vê se você pensa antes de escrever pipeline. Perguntar o grão de um fato é o teste mais rápido para saber se a pessoa já modelou de verdade ou só consumiu tabela pronta.

Como cai: Modele o fato de transações de cartão: qual é o grão?

Erros comuns

Começar pela lista de colunas em vez do grão. Sem declarar o grão, você não consegue decidir o que é medida, o que é dimensão e nem validar duplicidade depois.
Normalizar o modelo analítico até 3NF. Cada junção a mais custa leitura e shuffle; o modelo dimensional troca redundância controlada por velocidade e clareza.
Chamar de star um modelo com dimensão em vários níveis. Se a dimensão está quebrada em subtabelas, é snowflake, e você precisa justificar a escolha.
Usar SCD tipo 1 onde o negócio precisa de histórico. Sobrescrever o endereço do cliente reescreve o passado: a análise de risco por região do ano anterior muda sozinha.
Ligar o fato à chave natural do cliente numa dimensão SCD tipo 2. A chave tem que ser a substituta da versão vigente na data do evento, senão o histórico não fecha.
Adotar One Big Table por padrão. Ela é ótima para consulta e péssima para manter regra de negócio única; o custo aparece na terceira mudança de definição.

Vocabulário

grão: — A frase que define o que uma linha da tabela fato representa. "Uma linha por autorização de cartão" é um grão; "dados de cartão" não é.