10 milyar kaydı 100ms altında nasıl sorgularsınız?

Question

IT Interview Practice · Accepted Answer

Önce **access pattern için tasarlayın**, sonra partitioning + doğru index/PK'yı seçin, böylece herhangi bir tek sorgu küçük, sınırlı bir dilime dokunur — asla 10 milyar satır taramaz. 10 milyar kayıt üzerinde 100ms altı, daha hızlı bir disk ile ilgili değildir; working set'i küçültmekle ilgilidir.

```text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
   │                    (prune 99.9% of data)         (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? return in <5ms
                        miss ▼
                   Columnar store (ClickHouse) for aggregates / scans
```

## Access pattern'ler her şeyi yönlendirir

Teknolojiyi seçmeden önce sorun: **point lookup mu, range/aggregate mi?** "X kullanıcısının son 20 siparişini getir" bir point/range sorgusudur — partition ve sort key'in buna tam olarak uymasını istersiniz. "Bu ay bölgeye göre geliri topla" bir analitik tarama'dır — bir row store yanlış araçtır. Önce sorguyu modellemek, çalışan bir tasarımı, makul görünen ama full-scan yapan bir tasarımdan ayıran şeydir.

## Partitioning arama alanını budar

Tabloyu her sorguda görünen bir key ile bölün — genellikle **tenant_id + time**. Zaman partition'ları ile, "son 7 gün" için bir sorgu 7 partition okur ve diğer 3 yılı yok sayar. Bu *partition pruning*'tir: router, herhangi bir index'e danışılmadan önce verinin %99,9'unu eler.

## Doğru index / PK tasarımı

Bir partition içinde, **primary key sorgunun filter sütunlarını öne yüklemelidir**. DynamoDB'de: partition key = `tenant`, sort key = `timestamp` → range sorguları O(log n) + sequential read'tir. **ClickHouse** gibi bir columnar store'da, sorting key (`ORDER BY (tenant, ts)`) engine'in granule'leri atlamasına ve yalnızca eşleşen block'ları okumasına izin verir. Bir covering index, ekstra satır getirmeyi tamamen önler.

## Store seçimi

- **Point lookup, yüksek write:** NoSQL key-value (DynamoDB, Cassandra) — key'e göre O(1)-ish, yatay ölçeklenir.
- **Analytics/aggregate:** columnar (ClickHouse, BigQuery) — yalnızca gerekli sütunları okur, vectorized.
- **Hot %1'i cache'le:** önündeki Redis, tekrarlanan okumaları <5ms'de emer; 10 milyar satır ama birkaç milyon hot key.

## Mülakat perspektifi

Mülakatı yapan kişi, "hangi veritabanı?"dan önce **"sorgular neler?"** dediğinizi görmek ister. İyi adaylar index'lere başvurur; harika olanlar 10 milyar satır üzerinde bir index'in kendisinin devasa olduğunu belirtir — bu yüzden *önce partition yaparak index'in kapsadığını küçültürsünüz*. Row-vs-columnar ayrımını ve cache tier'ı adlandırmak gerçek ölçek deneyimini sinyaller.

**Yaygın tuzak:** cevap olarak tek bir dev B-tree index önermek. Point lookup'lara yardımcı olur ama analitik taramalar için hiçbir şey yapmaz ve yazmaları ingestion'ı bottleneck'ler.

## Ödünleşimler ve hata modları

- **Yanlış partition key** = cross-partition scatter-gather, latency şişer. Sorgularda mevcut bir key seçin.
- **Hot partition:** bir celebrity tenant tek bir shard'ı ezer — bir salting suffix ekleyin.
- **Cache staleness:** yazmada invalidate edin veya TTL gecikmesini kabul edin.
- **Denormalization maliyeti:** access pattern başına verileri sık sık çoğaltırsınız; storage ucuz, 10 saniyelik bir sorgu değil.

Access pattern'ler her şeyi yönlendirir

Partitioning arama alanını budar

Doğru index / PK tasarımı

Store seçimi

Mülakat perspektifi

Ödünleşimler ve hata modları

İlgili sorular