Bagaimana Anda mengquery 10 miliar record di bawah 100ms?

Question

IT Interview Practice · Accepted Answer

Rancang untuk **pola akses terlebih dahulu**, lalu pilih partisi + index/PK yang tepat agar setiap query tunggal hanya menyentuh irisan kecil yang terbatas — tidak pernah men-scan 10 miliar baris. Sub-100ms atas 10 miliar record bukan soal disk yang lebih cepat; ini soal membuat working set menjadi 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
```

## Pola akses menentukan segalanya

Sebelum memilih teknologi, tanyakan: **point lookup atau range/aggregate?** "Ambil 20 order terakhir user X" adalah query point/range — Anda ingin partisi dan sort key cocok persis dengannya. "Jumlahkan revenue per region bulan ini" adalah scan analitis — row store adalah alat yang salah. Memodelkan query terlebih dahulu itulah yang memisahkan desain yang bekerja dari yang terlihat masuk akal tetapi men-scan penuh.

## Partisi memangkas ruang pencarian

Pecah tabel berdasarkan key yang muncul di setiap query — biasanya **tenant_id + time**. Dengan partisi waktu, query untuk "7 hari terakhir" membaca 7 partisi dan mengabaikan 3 tahun lainnya. Ini *partition pruning*: router mengeliminasi 99,9% data sebelum index apa pun dikonsultasikan.

## Desain index / PK yang tepat

Di dalam partisi, **primary key harus menaruh kolom filter query di depan (front-load)**. Di DynamoDB: partition key = `tenant`, sort key = `timestamp` → range query adalah O(log n) + sequential read. Di columnar store seperti **ClickHouse**, sorting key (`ORDER BY (tenant, ts)`) membuat engine melewati granule dan hanya membaca blok yang cocok. Covering index menghindari fetch baris tambahan sepenuhnya.

## Pilihan store

- **Point lookup, write tinggi:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish berdasarkan key, menskala horizontal.
- **Analitik/aggregate:** columnar (ClickHouse, BigQuery) — membaca hanya kolom yang dibutuhkan, vektorisasi.
- **Cache 1% terpanas:** Redis di depan menyerap baca berulang di <5ms; 10 miliar baris tetapi beberapa juta hot key.

## Perspektif wawancara

Pewawancara ingin melihat Anda mengucap **"apa query-nya?" sebelum "database apa?"**. Kandidat baik meraih index; yang hebat mencatat bahwa index atas 10 miliar baris sendiri sudah raksasa — jadi Anda *mempartisi dulu untuk memperkecil apa yang dicakup index*. Menyebut pemisahan row-vs-columnar dan tier cache menandakan pengalaman skala nyata.

**Jebakan umum:** mengusulkan satu B-tree index raksasa sebagai jawaban. Ia membantu point lookup tetapi tidak berbuat apa pun untuk scan analitis, dan write-nya menjadi bottleneck ingesti.

## Trade-off & mode kegagalan

- **Partition key salah** = scatter-gather antar-partisi, latensi membengkak. Pilih key yang hadir di query.
- **Partisi panas:** tenant selebritas membebani satu shard — tambahkan salting suffix.
- **Cache basi:** invalidasi saat write atau terima lag TTL.
- **Biaya denormalisasi:** Anda sering menduplikasi data per pola akses; storage murah, query 10 detik tidak.

Pola akses menentukan segalanya

Partisi memangkas ruang pencarian

Desain index / PK yang tepat

Pilihan store

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait