Cum partiționezi o singură tabelă cu miliarde de rânduri?

Question

IT Interview Practice · Accepted Answer

**Împarte tabela gigantică în tabele-copil fizice mai mici după o cheie de partiție, astfel încât fiecare interogare să atingă doar partițiile de care are nevoie (partition pruning) în loc să scaneze miliarde de rânduri.** O tabelă cu 5B rânduri de comenzi se comportă în continuare ca o singură tabelă logică, dar motorul sare peste 99% din ea când `WHERE`-ul tău filtrează pe cheia de partiție.

## Forma unei tabele partiționate

```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)
```

## Alegerea unei strategii de partiționare

- **Range** — după range-uri de dată/id. Cel mai bun pentru time-series (comenzi, log-uri, evenimente); datele recente rămân hot, iar range-urile vechi sunt ușor de eliminat.
- **Hash** — distribuție uniformă pe N partiții după `hash(key) % N`. Folosește când nu există un range natural și vrei încărcare echilibrată (de ex. `user_id`).
- **List** — bucket-uri explicite (`region IN ('EU','US')`). Bun pentru izolare de tenant sau regiune.

```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, indecși, mentenanță

- **Partition pruning** funcționează doar dacă interogarea filtrează pe **cheia de partiție**. Filtrează pe altceva și scanezi fiecare partiție — greșeala #1.
- **Local index** = un index per copil (implicit în Postgres); ieftin de construit și eliminat odată cu partiția. **Global index** (Oracle) se întinde pe toate partițiile — ajută lookup-urile unice între partiții, dar trebuie reconstruit când elimini una.
- **Mentenanța** devine O(partiție): arhivează datele vechi cu `DROP TABLE orders_2019` (instantaneu, fără `DELETE` gigantic) și `ATTACH`/`DETACH` pentru ferestre glisante.

## Perspectiva de interviu

Intervievatorul sondează dacă înțelegi că **partiționarea nu este indexare** — ea reduce datele scanate, un index reduce rândurile examinate în cadrul unui scan; adesea ai nevoie de amândouă. Un răspuns bun numește range/hash/list; un răspuns excelent subliniază că **cheia de partiție trebuie să se potrivească cu filtrul dominant al interogării**, avertizează că o cheie greșită omoară pruning-ul și menționează arhivarea ieftină prin `DROP`.

**Compromis:** interogările cross-partition (fără filtru pe cheie, sau constrângeri unice între partiții) devin mai lente, iar aplicarea unicității este mai grea. Nu partiționa o tabelă de 10M de rânduri — adaugi complexitate operațională fără câștig. Partiționează când tabela este uriașă **și** interogările sunt natural delimitate de cheie.

Forma unei tabele partiționate

Alegerea unei strategii de partiționare

Pruning, indecși, mentenanță

Perspectiva de interviu

Întrebări conexe