Jak spartycjonować pojedynczą tabelę z miliardami wierszy?

Question

IT Interview Practice · Accepted Answer

**Podziel gigantyczną tabelę na mniejsze fizyczne tabele potomne po kluczu partycji, tak aby każde zapytanie dotykało tylko potrzebnych partycji (partition pruning), zamiast skanować miliardy wierszy.** Tabela z 5 mld wierszy zamówień wciąż zachowuje się jak jedna logiczna tabela, ale silnik pomija 99% jej, gdy twój `WHERE` filtruje po kluczu partycji.

## Kształt tabeli partycjonowanej

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

## Wybór strategii partycjonowania

- **Range** — po zakresach dat/id. Najlepsze dla szeregów czasowych (zamówienia, logi, zdarzenia); świeże dane pozostają gorące, a stare zakresy łatwo usunąć.
- **Hash** — równomierny rozkład na N partycji po `hash(key) % N`. Użyj, gdy nie ma naturalnego zakresu, a chcesz zrównoważonego obciążenia (np. `user_id`).
- **List** — jawne buckety (`region IN ('EU','US')`). Dobre do izolacji tenantów lub regionów.

```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, indeksy, konserwacja

- **Partition pruning** działa tylko, gdy zapytanie filtruje po **kluczu partycji**. Filtruj po czymś innym, a skanujesz każdą partycję — błąd nr 1.
- **Local index** = jeden indeks na tabelę potomną (domyślnie w Postgres); tani do zbudowania i usunięcia razem z partycją. **Global index** (Oracle) obejmuje wszystkie partycje — pomaga unikatowym lookupom między partycjami, ale musi być przebudowany przy usunięciu jednej.
- **Konserwacja** staje się O(partycja): archiwizuj stare dane przez `DROP TABLE orders_2019` (natychmiast, bez gigantycznego `DELETE`) i `ATTACH`/`DETACH` dla przesuwanych okien.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sonduje, czy rozumiesz, że **partycjonowanie to nie indeksowanie** — redukuje ilość skanowanych danych, indeks redukuje liczbę badanych wierszy w obrębie skanu; często potrzebujesz obu. Dobra odpowiedź nazywa range/hash/list; świetna podkreśla, że **klucz partycji musi pasować do dominującego filtra zapytań**, ostrzega, że zły klucz zabija pruning, i wspomina o tanim archiwizowaniu przez `DROP`.

**Kompromis:** zapytania międzypartycyjne (bez filtra po kluczu lub ograniczenia unikatowe między partycjami) stają się wolniejsze, a egzekwowanie unikatowości trudniejsze. Nie partycjonuj tabeli 10 mln wierszy — dodajesz złożoność operacyjną bez zysku. Partycjonuj, gdy tabela jest ogromna **i** zapytania są naturalnie zakresowane przez klucz.

Kształt tabeli partycjonowanej

Wybór strategii partycjonowania

Pruning, indeksy, konserwacja

Perspektywa rozmowy kwalifikacyjnej

Powiązane pytania