Bagaimana Anda mempartisi satu tabel dengan miliaran baris?

Question

IT Interview Practice · Accepted Answer

**Pecah tabel raksasa menjadi child table fisik yang lebih kecil berdasarkan partition key, sehingga setiap query hanya menyentuh partisi yang dibutuhkan (partition pruning) alih-alih men-scan miliaran baris.** Sebuah tabel dengan 5 miliar baris order tetap berlaku seperti satu tabel logis, tetapi engine melewati 99%-nya ketika `WHERE` Anda memfilter pada partition key.

## Bentuk sebuah tabel terpartisi

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

## Memilih strategi partisi

- **Range** — berdasarkan rentang tanggal/id. Terbaik untuk time-series (order, log, event); data terbaru tetap panas dan range lama mudah dibuang.
- **Hash** — sebaran merata ke N partisi berdasarkan `hash(key) % N`. Gunakan saat tidak ada range natural dan Anda ingin beban seimbang (mis. `user_id`).
- **List** — bucket eksplisit (`region IN ('EU','US')`). Baik untuk isolasi tenant atau region.

```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, index, maintenance

- **Partition pruning** hanya bekerja jika query memfilter pada **partition key**. Filter pada hal lain dan Anda men-scan setiap partisi — kesalahan #1.
- **Local index** = satu index per child (default di Postgres); murah dibangun dan dibuang bersama partisinya. **Global index** (Oracle) membentang semua partisi — membantu unique lookup lintas partisi tetapi harus dibangun ulang saat Anda membuang satu.
- **Maintenance** menjadi O(partisi): arsipkan data lama dengan `DROP TABLE orders_2019` (instan, tanpa `DELETE` raksasa), dan `ATTACH`/`DETACH` untuk rolling window.

## Perspektif wawancara

Pewawancara menyelidiki apakah Anda memahami bahwa **partisi bukan indexing** — ia mengurangi data yang di-scan, sebuah index mengurangi baris yang diperiksa dalam sebuah scan; Anda sering butuh keduanya. Jawaban baik menyebut range/hash/list; jawaban hebat menekankan bahwa **partition key harus cocok dengan filter query dominan Anda**, memperingatkan bahwa key yang salah mematikan pruning, dan menyebut arsip murah via `DROP`.

**Trade-off:** query lintas-partisi (tanpa filter key, atau unique constraint lintas partisi) menjadi lebih lambat dan penegakan unique lebih sulit. Jangan mempartisi tabel 10 juta baris — Anda menambah kompleksitas operasional tanpa manfaat. Partisi ketika tabel raksasa **dan** query secara natural di-scope oleh key-nya.

Bentuk sebuah tabel terpartisi

Memilih strategi partisi

Pruning, index, maintenance

Perspektif wawancara

Pertanyaan terkait