Canlı sistemi etkilemeden devasa bir dataset'i nasıl export edersiniz?

Question

IT Interview Practice · Accepted Answer

**Bir replica veya snapshot'tan okuyun (asla primary'den değil), `OFFSET` yerine keyset pagination ile sayfalayın, read rate'i throttle edin ve sonuçları doğrudan object storage'a stream'leyin.** Amaç, uzun kilitler tutmadan, primary CPU'yu spike'lamadan veya belleği patlatmadan 500M satır export etmektir.

## Export pipeline

```text
  Primary DB ──async replication──▶ Read replica / snapshot
                                          │  (isolated from live traffic)
                                          ▼
                                   Export worker
                              keyset page: WHERE id > :last
                                          │  throttle (sleep / rate limit)
                                          ▼
                                   Stream (batches)
                                          │
                                          ▼
                                   S3 / GCS  (NDJSON / Parquet)
```

## Her parça neden

- **Read replica veya snapshot.** İşi bir follower'a yönlendirin, böylece ağır okumalar primary'de production yazmalarıyla asla rekabet etmez. Bir **snapshot**, kararlı, point-in-time bir görünüm verir, böylece canlı veri değişmeye devam etse bile export tutarlıdır.
- **`OFFSET` değil, keyset pagination.** `OFFSET 10000000`, DB'nin her sayfada 10M satır tarayıp atmasını sağlar — export boyunca O(n²). Keyset son key'i hatırlar ve `WHERE id > :last ORDER BY id LIMIT 5000` yapar, ki bu index'e biner, sayfa başına O(1).
- **Throttle.** Batch'ler arasında sleep yapın veya satır/sn'yi sınırlayın, böylece replica doymaz ve replication lag sınırlı kalır.
- **Object store'a stream.** Her batch'i S3/GCS'ye NDJSON veya Parquet olarak yazın; asla tüm result set'i belleğe yüklemeyin. Driver'ın satırları stream'lemesi için bir cursor/server-side cursor kullanın.

## Mülakat perspektifi

Mülakatı yapan kişi, canlı sistemi koruyup korumadığınızı kontrol eder. Bir **replica** adlandırmak masa payıdır; kıdemli sinyal, **OFFSET üzerine keyset** (ve O(n²) tuzağını açıklayabilme) artı **backpressure/throttling** ve bir snapshot aracılığıyla **consistency**'dir. Yaygın bir tuzak: tek bir transaction'da tek bir `SELECT *` — bir read view'ı saatlerce açık tutar, DB'yi şişirir (Postgres vacuum, uzun snapshot'ın hala gördüğü satırları temizleyemez) ve her şeyi bellekte buffer'lar.

**Ödünleşimler:** bir replica gecikebilir, bu yüzden export biraz stale bir anı yansıtır — genellikle analitik için iyi, tam-şimdi veri gerektiren finansal mutabakat için değil. Keyset kararlı, unique, index'lenmiş bir sort key gerektirir; keyfi sort sıraları için zahmetlidir. Tablo devasa olduğunda ve storage layer'a sahip olduğunuzda, bir native araç (`pg_dump`, snapshot export to S3, `COPY`) sık sık elle yazılmış paging'i yener.

Export pipeline

Her parça neden

Mülakat perspektifi

İlgili sorular