Database

Escopo: transversal. Aplica-se a qualquer linguagem ou stack do projeto.

O banco de dados é o componente que mais afeta o desempenho, e o mais caro de corrigir depois que o produto está no ar. Trocar o modelo de dados com a tabela cheia custa migração, janela de manutenção e risco.

Três decisões respondem pela maior parte do resultado: escolher o modelo certo no começo, escrever queries que o banco consegue otimizar e encontrar o gargalo antes que ele chegue à produção.

Duas perguntas decidem a escolha: qual é o formato dos seus dados e como o sistema vai lê-los no dia a dia. A idade da tecnologia fica de fora da conta.

Os dados moram em tabelas com schema definido, as relações entre entidades aparecem como foreign keys e as transações trazem as garantias ACID.

Exemplos: PostgreSQL, SQL Server, MySQL, SQLite.

Quando usar: o domínio tem entidades que se relacionam, a operação precisa de consistência transacional e as queries ainda vão surgir com o produto, sem estarem todas conhecidas no desenho inicial.

Quatro modelos principais, cada um afiado para um padrão de acesso diferente:

Quando usar: o volume de escrita passa do que um banco relacional absorve, o schema dos dados varia de registro para registro, o acesso é sempre o mesmo e já se conhece de antemão (busca por chave, leitura do documento inteiro), ou o grafo é a forma natural dos dados.

O que não fazer: adotar NoSQL pela fama de "escalar melhor", sem medir nada. Um banco relacional bem indexado aguenta um volume muito maior do que a maioria dos projetos vai atingir, e o NoSQL adiciona complexidade operacional real.

O gargalo quase sempre vem da query mal escrita ou do índice ausente. Trocar o hardware custa caro e adia o problema por alguns meses.

O índice é uma estrutura auxiliar que o banco consulta para achar as linhas sem varrer a tabela inteira.

-- índice simples: acelera buscas por email
CREATE INDEX idx_users_email ON users(email);

-- índice composto: acelera WHERE status = ? AND created_at > ?
CREATE INDEX idx_orders_status_created ON orders(status, created_at);

Regras:

Padrões com BAD/GOOD completos: sql/conventions/advanced/performance.md.

O NoSQL tem os próprios anti-padrões, e o princípio que os resolve é o mesmo do SQL: filtrar e projetar no servidor sai mais barato do que trazer o dado pela rede para descartar no cliente.

Guia completo por SGBD: docs/nosql/. Convenções de CRUD (Create Read Update Delete · Criar Ler Atualizar Excluir), naming e performance: nosql/conventions/.

const user = await database.collection('users').findOne({ email });
const userName = user.name;

class UserRepository {
  async findByEmail(email) {
    const user = await this.collection.findOne(
      { email },
      { projection: { name: 1, _id: 0 } }
    );

    return user;
  }
}

const allOrders = await database.collection('orders').find({}).toArray();
const pendingOrders = allOrders.filter(order => order.status === 'pending');

class OrderRepository {
  async findPending() {
    const pendingOrders = await this.collection
      .find({ status: 'pending' })
      .project({ id: 1, customerId: 1, total: 1 })
      .toArray();

    return pendingOrders;
  }
}

const orders = await database.collection('orders').find({ userId }).toArray();

const enrichedOrders = await Promise.all(
  orders.map(async order => {
    const product = await database.collection('products').findOne({ _id: order.productId });

    return { ...order, product };
  })
);

class OrderRepository {
  async findByUserWithProduct(userId) {
    const enrichedOrders = await this.collection.aggregate([
      { $match: { userId } },
      {
        $lookup: {
          from: 'products',
          localField: 'productId',
          foreignField: '_id',
          as: 'product',
        },
      },
      { $unwind: '$product' }, // drops orders with no matching product: use preserveNullAndEmptyArrays: true if product can be missing
    ]).toArray();

    return enrichedOrders;
  }
}

A operação em lote junta várias linhas em uma instrução só, ou parte uma operação enorme em ciclos menores. São dois objetivos diferentes: o primeiro aumenta o volume que passa por segundo em uma carga inicial, e o segundo evita que uma manutenção segure a tabela travada por minutos.

Nenhum número serve para todos os casos. O que decide é quanto tempo de lock o seu sistema tolera.

O job em lote que roda em produção precisa ser idempotente: se ele cair no meio, a execução seguinte retoma de onde parou, sem duplicar nem corromper dado. O jeito mais simples de conseguir isso é usar o próprio filtro do UPDATE ou do DELETE como cursor, porque o WHERE já deixa de fora as linhas que as iterações anteriores processaram.

Padrões de query: sql/conventions/advanced/batch.md.

Recursos específicos por banco: SQL Server | PostgreSQL.

O plano de execução mostra o caminho que o banco vai seguir para responder a query: quais índices ele usa, como resolve cada join e quanto estima gastar em cada passo.

Antes de levar qualquer query a uma tabela grande em produção, leia o plano.

Sintaxe por banco: PostgreSQL | SQL Server.

-- exemplo de saída EXPLAIN (PostgreSQL)
Seq Scan on orders  (cost=0.00..4521.00 rows=150000 width=16)
  Filter: ((status)::text = 'pending'::text)

Um Seq Scan com Filter em tabela grande é o sinal mais claro de índice ausente.

A investigação começa aqui. Ligue o log de queries lentas e deixe o banco apontar quais consultas passaram do tempo limite que você definiu.

Configuração por banco: PostgreSQL | SQL Server.

O N+1 é difícil de ver no código e fácil de ver no log de queries. O sinal é uma sequência rápida de consultas idênticas, com o ID mudando a cada linha.

-- sinal de N+1 no log
SELECT * FROM customers WHERE id = 1  -- 0.1ms
SELECT * FROM customers WHERE id = 2  -- 0.1ms
SELECT * FROM customers WHERE id = 3  -- 0.1ms
... (100 vezes)

Ferramentas que denunciam o N+1 sozinhas: Bullet (Rails), Hibernate Statistics, EF Core logging, Sequelize logging mode.

Com todas as conexões do pool ocupadas, a requisição nova entra na fila e espera. O sintoma é enganoso: requisições simples, que sempre foram rápidas, começam a estourar timeout, enquanto a CPU (Central Processing Unit · Unidade Central de Processamento) permanece baixa e as queries mantêm o tempo de sempre.

Diagnóstico por banco: PostgreSQL | SQL Server.

Causas comuns: query longa segurando a conexão, transação que ninguém fechou, pool dimensionado abaixo da carga, pico de tráfego fora do previsto.

O lock faz parte do funcionamento normal: ele é o mecanismo que mantém a consistência. O problema aparece quando o lock dura demais ou vira deadlock.

Identificar locks ativos: PostgreSQL | SQL Server.

O deadlock chega ao log com mensagem própria, e a causa costuma ser sempre a mesma: duas transações tocam as mesmas linhas em ordem trocada, e cada uma fica esperando o lock que a outra segura. A saída é padronizar a ordem de acesso.

-- padrão que gera deadlock
Transação A: lock em orders(1) → tenta lock em payments(1)
Transação B: lock em payments(1) → tenta lock em orders(1)  ← deadlock

-- solução: sempre adquirir locks na mesma ordem
Transação A: lock em orders(1) → lock em payments(1)
Transação B: lock em orders(1) → lock em payments(1)  ← espera A terminar

Quando alguém chegar dizendo que "o banco está lento", percorra esta ordem:

DoDocs v3.7.0 · Desenvolvido por @thiagocajadev · Baseado no trabalho de pmndrs/docs · Poimandres.