Como você particiona uma única tabela com bilhões de linhas?

Question

IT Interview Practice · Accepted Answer

**Divida a tabela gigante em tabelas filhas físicas menores por uma partition key, para que cada consulta toque apenas as partições de que precisa (partition pruning) em vez de escanear bilhões de linhas.** Uma tabela com 5B de linhas de pedidos ainda se comporta como uma tabela lógica, mas o engine pula 99% dela quando seu `WHERE` filtra pela partition key.

## O formato de uma tabela particionada

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## Escolhendo uma estratégia de particionamento

- **Range** — por ranges de data/id. Melhor para time-series (pedidos, logs, eventos); dados recentes ficam quentes e ranges antigos são fáceis de dropar.
- **Hash** — espalhamento uniforme por N partições via `hash(key) % N`. Use quando não há range natural e você quer carga balanceada (ex. `user_id`).
- **List** — buckets explícitos (`region IN ('EU','US')`). Bom para isolamento de tenant ou região.

```sql
-- Postgres: range partition by month, prune on created_at
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- This scans ONLY orders_2025_01, not the whole table
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, índices, manutenção

- **Partition pruning** só funciona se a consulta filtrar pela **partition key**. Filtre por outra coisa e você escaneia toda partição — o erro nº 1.
- **Local index** = um índice por filho (padrão no Postgres); barato de construir e dropar com a partição. **Global index** (Oracle) abrange todas as partições — ajuda em lookups únicos entre partições mas deve ser reconstruído quando você dropa uma.
- **Manutenção** vira O(partição): arquive dados antigos com `DROP TABLE orders_2019` (instantâneo, sem `DELETE` gigante), e `ATTACH`/`DETACH` para janelas móveis.

## Perspectiva de entrevista

O entrevistador sonda se você entende que **particionamento não é indexação** — ele reduz os dados escaneados, um índice reduz as linhas examinadas dentro de um scan; você frequentemente precisa de ambos. Boa resposta nomeia range/hash/list; ótima resposta enfatiza que **a partition key deve corresponder ao seu filtro de consulta dominante**, alerta que uma chave errada mata o pruning, e menciona arquivamento barato via `DROP`.

**Trade-off:** consultas cross-partition (sem filtro de chave, ou constraints únicas entre partições) ficam mais lentas e a imposição de unicidade é mais difícil. Não particione uma tabela de 10M de linhas — você adiciona complexidade operacional sem ganho. Particione quando a tabela é enorme **e** as consultas são naturalmente escopadas pela chave.

O formato de uma tabela particionada

Escolhendo uma estratégia de particionamento

Pruning, índices, manutenção

Perspectiva de entrevista

Perguntas relacionadas