Si e partition-oni një tabelë të vetme me miliarda rreshta?

Question

IT Interview Practice · Accepted Answer

**Ndani tabelën gjigante në tabela fëmijë fizike më të vogla sipas një partition key, kështu që çdo query prek vetëm partitions që i duhen (partition pruning) në vend që të skanojë miliarda rreshta.** Një tabelë me 5B rreshta porosish ende sillet si një tabelë e vetme logjike, por engine-i kapërcen 99% të saj kur `WHERE` juaj filtron sipas partition key.

## Forma e një tabele të partition-uar

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

## Zgjedhja e një strategjie partition

- **Range** — sipas range-ve datë/id. Më e mira për time-series (orders, logs, events); të dhënat e fundit mbeten të nxehta dhe range-t e vjetër janë të lehtë të hidhen.
- **Hash** — shpërndarje e njëtrajtshme nëpër N partitions sipas `hash(key) % N`. Përdoreni kur nuk ka range natyror dhe doni ngarkesë të balancuar (p.sh. `user_id`).
- **List** — buckets eksplicite (`region IN ('EU','US')`). Mirë për izolim tenant ose rajoni.

```sql
-- Postgres: range partition sipas muajit, prune mbi 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');

-- Kjo skanon VETËM orders_2025_01, jo të gjithë tabelën
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, indexes, mirëmbajtje

- **Partition pruning** funksionon vetëm nëse query filtron sipas **partition key**. Filtroni mbi diçka tjetër dhe skanoni çdo partition — gabimi #1.
- **Local index** = një index për çdo fëmijë (default në Postgres); i lirë të ndërtohet dhe hidhet me partition-in. **Global index** (Oracle) mbulon të gjithë partitions — ndihmon lookups unike nëpër partitions por duhet të rindërtohet kur hidhni një.
- **Mirëmbajtja** bëhet O(partition): arkivoni të dhënat e vjetra me `DROP TABLE orders_2019` (e menjëhershme, pa `DELETE` gjigant), dhe `ATTACH`/`DETACH` për rolling windows.

## Këndvështrimi i intervistës

Intervistuesi heton nëse e kuptoni se **partitioning nuk është indexing** — ai redukton të dhënat e skanuara, një index redukton rreshtat e ekzaminuar brenda një skanimi; shpesh ju duhen të dyja. Përgjigja e mirë emërton range/hash/list; përgjigja e shkëlqyer thekson se **partition key duhet të përputhet me filtrin tuaj dominant të query-t**, paralajmëron se një key i gabuar vret pruning-un, dhe përmend arkivimin e lirë përmes `DROP`.

**Kompromisi:** query-t cross-partition (pa key filter, ose constraints unike nëpër partitions) bëhen më të ngadalta dhe zbatimi i unike është më i vështirë. Mos partition-oni një tabelë 10M-rreshtash — shtoni kompleksitet operacional pa përfitim. Partition-oni kur tabela është e madhe **dhe** query-t janë natyrshëm të scope-uara sipas key-t.

Forma e një tabele të partition-uar

Zgjedhja e një strategjie partition

Pruning, indexes, mirëmbajtje

Këndvështrimi i intervistës

Pyetje të ngjashme