Query 10 tỷ bản ghi dưới 100ms bằng cách nào?

Question

IT Interview Practice · Accepted Answer

Thiết kế cho **access pattern trước**, rồi chọn partitioning + đúng index/PK sao cho mỗi query chỉ chạm một lát dữ liệu nhỏ, có giới hạn — không bao giờ scan 10 tỷ dòng. Dưới 100ms trên 10 tỷ bản ghi không phải chuyện ổ đĩa nhanh hơn; đó là chuyện làm cho working set thật nhỏ.

```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 quyết định tất cả

Trước khi chọn công nghệ, hỏi: **point lookup hay range/aggregate?** "Lấy 20 đơn hàng gần nhất của user X" là query point/range — bạn muốn partition key và sort key khớp chính xác nó. "Tính tổng doanh thu theo vùng tháng này" là scan phân tích — row store là công cụ sai. Mô hình hoá query trước là thứ phân biệt một thiết kế chạy được với một thiết kế trông hợp lý nhưng full-scan.

## Partitioning cắt bớt không gian tìm kiếm

Chia bảng theo một key xuất hiện trong mọi query — thường là **tenant_id + time**. Với time partition, query "7 ngày gần nhất" đọc 7 partition và bỏ qua 3 năm còn lại. Đây là *partition pruning*: router loại 99.9% dữ liệu trước khi tra bất kỳ index nào.

## Thiết kế index / PK đúng

Trong một partition, **primary key phải đưa các cột filter của query lên đầu**. Trong DynamoDB: partition key = `tenant`, sort key = `timestamp` → range query là O(log n) + đọc tuần tự. Trong columnar store như **ClickHouse**, sorting key (`ORDER BY (tenant, ts)`) cho engine bỏ qua granule và chỉ đọc block khớp. Một covering index tránh hẳn thao tác fetch dòng phụ.

## Chọn store

- **Point lookup, write cao:** NoSQL key-value (DynamoDB, Cassandra) — gần O(1) theo key, scale ngang.
- **Analytics/aggregate:** columnar (ClickHouse, BigQuery) — chỉ đọc cột cần, vectorized.
- **Cache 1% nóng:** Redis phía trước hấp thụ các read lặp lại ở <5ms; 10 tỷ dòng nhưng chỉ vài triệu key nóng.

## Góc nhìn phỏng vấn

Người phỏng vấn muốn thấy bạn nói **"query là gì?" trước "database nào?"**. Ứng viên khá với tới index; ứng viên xuất sắc lưu ý index trên 10 tỷ dòng bản thân nó cũng khổng lồ — nên bạn *partition trước để thu nhỏ thứ index phải phủ*. Gọi tên phân chia row-vs-columnar và tầng cache báo hiệu kinh nghiệm quy mô thật.

**Bẫy thường gặp:** đề xuất một B-tree index khổng lồ duy nhất làm câu trả lời. Nó giúp point lookup nhưng vô dụng với scan phân tích, và write của nó làm nghẽn ingestion.

## Đánh đổi & kịch bản hỏng

- **Partition key sai** = scatter-gather liên partition, latency phình to. Chọn key có trong query.
- **Hot partition:** một tenant "người nổi tiếng" làm quá tải một shard — thêm hậu tố salting.
- **Cache cũ:** invalidate khi write hoặc chấp nhận trễ TTL.
- **Chi phí denormalization:** bạn thường nhân bản dữ liệu theo từng access pattern; storage rẻ, một query 10 giây thì không.

Access pattern quyết định tất cả

Partitioning cắt bớt không gian tìm kiếm

Thiết kế index / PK đúng

Chọn store

Góc nhìn phỏng vấn

Đánh đổi & kịch bản hỏng

Câu hỏi liên quan