Milyarlarca satırlı tek bir tabloyu nasıl partition yaparsınız?

Question

IT Interview Practice · Accepted Answer

**Dev tabloyu bir partition key'e göre daha küçük fiziksel child tablolara bölün, böylece her sorgu milyarlarca satırı taramak yerine yalnızca ihtiyaç duyduğu partition'lara dokunur (partition pruning).** 5 milyar order satırlı bir tablo hala tek bir mantıksal tablo gibi davranır, ancak `WHERE`'iniz partition key üzerinde filtrelediğinde engine %99'unu atlar.

## Partition'lanmış bir tablonun şekli

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

## Bir partition stratejisi seçme

- **Range** — tarih/id range'lerine göre. Time-series için en iyi (order'lar, log'lar, event'ler); son veri hot kalır ve eski range'leri drop etmek kolaydır.
- **Hash** — `hash(key) % N` ile N partition arasında eşit yayılım. Doğal bir range olmadığında ve dengeli yük istediğinizde kullanın (örn. `user_id`).
- **List** — açık bucket'lar (`region IN ('EU','US')`). Tenant veya region izolasyonu için iyi.

```sql
-- Postgres: aya göre range partition, created_at üzerinde prune
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');

-- Bu, tüm tabloyu değil, YALNIZCA orders_2025_01'i tarar
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, index'ler, bakım

- **Partition pruning** yalnızca sorgu **partition key** üzerinde filtrelerse çalışır. Başka bir şey üzerinde filtreleyin ve her partition'ı tararsınız — 1 numaralı hata.
- **Local index** = child başına bir index (Postgres'te varsayılan); partition ile inşa etmesi ve drop etmesi ucuz. **Global index** (Oracle) tüm partition'ları kapsar — partition'lar arası unique lookup'lara yardımcı olur ama birini drop ettiğinizde yeniden inşa edilmelidir.
- **Bakım** O(partition) olur: eski veriyi `DROP TABLE orders_2019` ile arşivleyin (anında, dev bir `DELETE` yok) ve rolling window'lar için `ATTACH`/`DETACH`.

## Mülakat perspektifi

Mülakatı yapan kişi, **partitioning'in indexing olmadığını** anlayıp anlamadığınızı yoklar — partitioning taranan veriyi azaltır, bir index bir tarama içinde incelenen satırları azaltır; sık sık ikisine de ihtiyacınız var. İyi cevap range/hash/list'i adlandırır; harika cevap **partition key'in baskın sorgu filter'ınıza uyması gerektiğini** vurgular, yanlış bir key'in pruning'i öldürdüğü konusunda uyarır ve `DROP` aracılığıyla ucuz arşivlemeyi belirtir.

**Ödünleşim:** cross-partition sorgular (key filter yok veya partition'lar arası unique constraint'ler) yavaşlar ve unique zorlama zorlaşır. 10M satırlık bir tabloyu partition yapmayın — kazanç olmadan operasyonel karmaşıklık eklersiniz. Tablo devasa **ve** sorgular doğal olarak key ile kapsamlandığında partition yapın.

Partition'lanmış bir tablonun şekli

Bir partition stratejisi seçme

Pruning, index'ler, bakım

Mülakat perspektifi

İlgili sorular