Bagaimana anda men-query 10B rekod di bawah 100ms?

Question

IT Interview Practice · Accepted Answer

Reka bentuk untuk **access pattern dahulu**, kemudian pilih partitioning + index/PK yang betul supaya mana-mana query tunggal hanya menyentuh sekeping kecil yang terbatas — tidak pernah mengimbas 10B baris. Sub-100ms merentas 10 bilion rekod bukan tentang disk yang lebih pantas; ia tentang menjadikan working set sangat kecil.

```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 memacu segalanya

Sebelum memilih teknologi, tanya: **point lookup atau range/aggregate?** "Dapatkan 20 order terakhir pengguna X" ialah query point/range — anda mahu partition dan sort key sepadan dengannya dengan tepat. "Jumlahkan hasil mengikut wilayah bulan ini" ialah imbasan analitik — sebuah row store ialah alat yang salah. Memodelkan query dahulu itulah yang memisahkan reka bentuk yang berfungsi daripada yang kelihatan munasabah tetapi mengimbas penuh.

## Partitioning menyunting ruang carian

Pecahkan jadual mengikut key yang muncul dalam setiap query — biasanya **tenant_id + time**. Dengan partition masa, query untuk "7 hari terakhir" membaca 7 partition dan mengabaikan 3 tahun yang lain. Ini ialah *partition pruning*: router menghapuskan 99.9% data sebelum mana-mana index dirujuk.

## Reka bentuk index / PK yang betul

Dalam satu partition, **primary key mesti mendahulukan (front-load) lajur penapis query**. Dalam DynamoDB: partition key = `tenant`, sort key = `timestamp` → query range ialah O(log n) + bacaan berjujukan. Dalam columnar store seperti **ClickHouse**, sorting key (`ORDER BY (tenant, ts)`) membenarkan enjin melangkau granule dan hanya membaca blok yang sepadan. Sebuah covering index mengelakkan pengambilan baris tambahan sepenuhnya.

## Pilihan store

- **Point lookup, penulisan tinggi:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish mengikut key, menskala secara mendatar.
- **Analitik/aggregate:** columnar (ClickHouse, BigQuery) — hanya membaca lajur yang diperlukan, ter-vektor.
- **Cache 1% panas:** Redis di hadapan menyerap bacaan berulang pada <5ms; 10B baris tetapi hanya beberapa juta hot key.

## Perspektif temu duga

Penemu duga mahu melihat anda berkata **"apakah query-nya?" sebelum "apakah database-nya?"**. Calon yang baik menggapai index; yang hebat mencatat bahawa index ke atas 10B baris itu sendiri besar — jadi anda *partition dahulu untuk mengecilkan apa yang index liputi*. Menyebut pemisahan row-vs-columnar dan lapisan cache menandakan pengalaman skala sebenar.

**Perangkap biasa:** mencadangkan satu B-tree index gergasi sebagai jawapan. Ia membantu point lookup tetapi tidak melakukan apa-apa untuk imbasan analitik, dan penulisannya menyesakkan ingestion.

## Pertukaran & mod kegagalan

- **Partition key yang salah** = scatter-gather rentas partition, latency membengkak. Pilih key yang hadir dalam query.
- **Partition panas:** seorang tenant selebriti membanjiri satu shard — tambah salting suffix.
- **Cache basi:** invalidasi pada penulisan atau terima TTL lag.
- **Kos denormalisasi:** anda sering menduplikasi data bagi setiap access pattern; storan murah, query 10 saat tidak.

Access pattern memacu segalanya

Partitioning menyunting ruang carian

Reka bentuk index / PK yang betul

Pilihan store

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan