Bagaimana anda men-partition satu jadual dengan berbilion baris?

Question

IT Interview Practice · Accepted Answer

**Pecahkan jadual gergasi menjadi child table fizikal yang lebih kecil mengikut partition key, supaya setiap query hanya menyentuh partition yang diperlukannya (partition pruning) dan bukannya mengimbas berbilion baris.** Sebuah jadual dengan 5B baris order masih berkelakuan seperti satu jadual logik, tetapi enjin melangkau 99% daripadanya apabila `WHERE` anda menapis pada partition key.

## Bentuk jadual yang di-partition

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

- **Range** — mengikut julat tarikh/id. Terbaik untuk time-series (order, log, peristiwa); data terkini kekal panas dan range lama mudah digugurkan.
- **Hash** — taburan sekata merentas N partition mengikut `hash(key) % N`. Guna apabila tiada range semula jadi dan anda mahu beban seimbang (cth. `user_id`).
- **List** — bucket eksplisit (`region IN ('EU','US')`). Baik untuk pengasingan tenant atau wilayah.

```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, penyelenggaraan

- **Partition pruning** hanya berfungsi jika query menapis pada **partition key**. Tapis pada sesuatu yang lain dan anda mengimbas setiap partition — kesilapan #1.
- **Local index** = satu index bagi setiap child (lalai dalam Postgres); murah untuk dibina dan digugurkan bersama partition. **Global index** (Oracle) merentangi semua partition — membantu carian unik merentas partition tetapi mesti dibina semula apabila anda menggugurkan satu.
- **Penyelenggaraan** menjadi O(partition): arkib data lama dengan `DROP TABLE orders_2019` (serta-merta, tiada `DELETE` gergasi), dan `ATTACH`/`DETACH` untuk tingkap bergolek.

## Perspektif temu duga

Penemu duga menyiasat sama ada anda memahami bahawa **partitioning bukan indexing** — ia mengurangkan data yang diimbas, sebuah index mengurangkan baris yang diperiksa dalam satu imbasan; anda selalunya memerlukan kedua-duanya. Jawapan yang baik menyebut range/hash/list; jawapan yang hebat menekankan bahawa **partition key mesti sepadan dengan penapis query dominan anda**, memberi amaran bahawa key yang salah membunuh pruning, dan menyebut pengarkiban murah melalui `DROP`.

**Pertukaran:** query rentas partition (tiada penapis key, atau constraint unik merentas partition) menjadi lebih perlahan dan penguatkuasaan unik lebih sukar. Jangan partition jadual 10J baris — anda menambah kerumitan operasi tanpa manfaat. Partition apabila jadual gergasi **dan** query secara semula jadi diskop mengikut key.

Bentuk jadual yang di-partition

Memilih strategi partition

Pruning, index, penyelenggaraan

Perspektif temu duga

Soalan berkaitan