Πώς κάνετε partition έναν μοναδικό πίνακα με δισεκατομμύρια rows;

Question

IT Interview Practice · Accepted Answer

**Σπάστε τον γιγαντιαίο πίνακα σε μικρότερους physical child tables κατά ένα partition key, ώστε κάθε query να αγγίζει μόνο τα partitions που χρειάζεται (partition pruning) αντί να κάνει scan δισεκατομμύρια rows.** Ένας πίνακας με 5 δισ. order rows εξακολουθεί να συμπεριφέρεται σαν ένας λογικός πίνακας, αλλά η μηχανή παρακάμπτει το 99% του όταν το `WHERE` σας φιλτράρει στο partition key.

## Το σχήμα ενός partitioned table

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

## Επιλογή στρατηγικής partition

- **Range** — κατά date/id ranges. Καλύτερο για time-series (orders, logs, events)· τα πρόσφατα δεδομένα μένουν hot και τα παλιά ranges είναι εύκολα να γίνουν drop.
- **Hash** — ομοιόμορφη διάχυση σε N partitions κατά `hash(key) % N`. Χρησιμοποιήστε όταν δεν υπάρχει φυσικό range και θέλετε ισορροπημένο load (π.χ. `user_id`).
- **List** — ρητά buckets (`region IN ('EU','US')`). Καλό για tenant ή region isolation.

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

- **Το partition pruning** δουλεύει μόνο αν το query φιλτράρει στο **partition key**. Φιλτράρετε σε κάτι άλλο και κάνετε scan κάθε partition — το #1 λάθος.
- **Local index** = ένα index ανά child (default στην Postgres)· φθηνό να χτιστεί και να γίνει drop με το partition. **Global index** (Oracle) εκτείνεται σε όλα τα partitions — βοηθά unique lookups πέρα από partitions αλλά πρέπει να ξαναχτιστεί όταν κάνετε drop ένα.
- **Το maintenance** γίνεται O(partition): αρχειοθετήστε παλιά δεδομένα με `DROP TABLE orders_2019` (ακαριαία, όχι γιγαντιαίο `DELETE`), και `ATTACH`/`DETACH` για rolling windows.

## Οπτική συνέντευξης

Ο συνεντευκτής διερευνά αν καταλαβαίνετε ότι **το partitioning δεν είναι indexing** — μειώνει τα δεδομένα που γίνονται scan, ένα index μειώνει τα rows που εξετάζονται μέσα σε ένα scan· συχνά χρειάζεστε και τα δύο. Καλή απάντηση κατονομάζει range/hash/list· εξαιρετική απάντηση τονίζει ότι **το partition key πρέπει να ταιριάζει το κυρίαρχο query filter σας**, προειδοποιεί ότι ένα λάθος key σκοτώνει το pruning, και αναφέρει φθηνή αρχειοθέτηση μέσω `DROP`.

**Trade-off:** τα cross-partition queries (χωρίς key filter, ή unique constraints πέρα από partitions) γίνονται πιο αργά και η επιβολή unique είναι δυσκολότερη. Μην κάνετε partition έναν πίνακα 10M-row — προσθέτετε λειτουργική πολυπλοκότητα χωρίς όφελος. Κάντε partition όταν ο πίνακας είναι τεράστιος **και** τα queries είναι φυσικά scoped κατά το key.

Το σχήμα ενός partitioned table

Επιλογή στρατηγικής partition

Pruning, indexes, maintenance

Οπτική συνέντευξης

Σχετικές ερωτήσεις