Miten vietä valtavan datajoukon vaikuttamatta live-järjestelmään?

Question

IT Interview Practice · Accepted Answer

**Lue replikasta tai snapshotista (älä koskaan primarysta), sivuta keyset-sivutuksella `OFFSET`:n sijaan, throttlaa lukutahtia ja striimaa tulokset suoraan object storageen.** Tavoite on viedä 500M riviä pitämättä pitkiä lukkoja, piikittämättä primaryn CPU:ta tai räjäyttämättä muistia.

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

## Miksi kukin osa

- **Read replica tai snapshot.** Suuntaa työ followeriin, jotta raskaat lukemiset eivät koskaan kilpaile tuotantokirjoitusten kanssa primarysta. **Snapshot** antaa vakaan, point-in-time-näkymän, jotta vienti on konsistentti vaikka live-data jatkaa muuttumistaan.
- **Keyset-sivutus, ei `OFFSET`.** `OFFSET 10000000` saa DB:n skannaamaan ja hylkäämään 10M riviä joka sivulla — O(n²) viennin yli. Keyset muistaa viimeisen avaimen ja tekee `WHERE id > :last ORDER BY id LIMIT 5000`, mikä ratsastaa indeksillä O(1):ssä per sivu.
- **Throttle.** Nuku erien välillä tai rajaa rivejä/s, jottei replika saturoidu ja replication lag pysyy rajattuna.
- **Striimaa object storeen.** Kirjoita jokainen erä S3:een/GCS:ään NDJSON- tai Parquet-muodossa; älä koskaan lataa koko tulosjoukkoa muistiin. Käytä kursoria/server-side-kursoria, jotta ajuri striimaa rivit.

## Haastattelunäkökulma

Haastattelija tarkistaa, suojaatko live-järjestelmää. **Replikan** nimeäminen on peruskauraa; senior-signaali on **keyset over OFFSET** (ja kyky selittää O(n²)-ansa) plus **backpressure/throttlaus** ja **konsistenssi** snapshotin kautta. Yleinen ansa: yksittäinen `SELECT *` yhdessä transaktiossa — se pitää lukunäkymän auki tunteja, pöhöttää DB:n (Postgres vacuum ei voi siivota rivejä, jotka pitkä snapshot vielä näkee), ja puskuroi kaiken muistiin.

**Kompromissit:** replika voi laahata, joten vienti heijastaa hieman vanhentunutta hetkeä — yleensä ok analytiikkaan, ei taloudelliseen täsmäytykseen, joka tarvitsee tarkkaa-nyt-dataa. Keyset tarvitsee vakaan, uniikin, indeksoidun lajitteluavaimen; se on kömpelö mielivaltaisille lajittelujärjestyksille. Kun taulu on valtava ja omistat tallennuskerroksen, natiivi työkalu (`pg_dump`, snapshot-vienti S3:een, `COPY`) usein voittaa käsin tehdyn sivutuksen.

Vienti-pipeline

Miksi kukin osa

Haastattelunäkökulma

Aiheeseen liittyvät kysymykset