Làm sao phân mảnh một bảng có hàng tỷ dòng?

Question

IT Interview Practice · Accepted Answer

**Chia bảng khổng lồ thành các bảng con vật lý nhỏ hơn theo một partition key, để mỗi query chỉ chạm vào những partition cần thiết (partition pruning) thay vì quét hàng tỷ dòng.** Một bảng 5 tỷ dòng đơn hàng vẫn hoạt động như một bảng logic duy nhất, nhưng engine bỏ qua 99% dữ liệu khi `WHERE` lọc theo partition key.

## Hình dạng của bảng đã phân mảnh

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## Chọn chiến lược phân mảnh

- **Range** — theo khoảng ngày/id. Tốt cho dữ liệu time-series (orders, logs, events); dữ liệu gần đây luôn "nóng" còn range cũ dễ dàng xoá.
- **Hash** — rải đều qua N partition theo `hash(key) % N`. Dùng khi không có range tự nhiên và muốn cân bằng tải (vd. `user_id`).
- **List** — bucket tường minh (`region IN ('EU','US')`). Hợp cho việc tách biệt tenant hay region.

```sql
-- Postgres: phân mảnh range theo tháng, prune trên created_at
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- Query này CHỈ quét orders_2025_01, không phải toàn bảng
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, index, bảo trì

- **Partition pruning** chỉ hoạt động khi query lọc theo **partition key**. Lọc theo cột khác thì bạn quét mọi partition — lỗi số một.
- **Local index** = một index cho mỗi bảng con (mặc định ở Postgres); rẻ để build và xoá cùng partition. **Global index** (Oracle) trải khắp mọi partition — hỗ trợ tra cứu unique xuyên partition nhưng phải rebuild khi bạn drop một partition.
- **Bảo trì** trở thành O(partition): archive dữ liệu cũ bằng `DROP TABLE orders_2019` (tức thì, không cần `DELETE` khổng lồ), và `ATTACH`/`DETACH` cho cửa sổ trượt (rolling window).

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

Người phỏng vấn dò xem bạn có hiểu **phân mảnh không phải là index** — nó giảm lượng dữ liệu bị quét, còn index giảm số dòng phải xét trong một lần quét; bạn thường cần cả hai. Câu trả lời tốt nêu được range/hash/list; câu xuất sắc nhấn mạnh **partition key phải khớp với bộ lọc query chủ đạo**, cảnh báo chọn sai key sẽ giết pruning, và nhắc tới archival rẻ qua `DROP`.

**Đánh đổi:** query xuyên partition (không lọc theo key, hoặc unique constraint xuyên partition) sẽ chậm hơn và ép unique khó hơn. Đừng phân mảnh bảng 10M dòng — bạn thêm độ phức tạp vận hành mà chẳng lợi gì. Chỉ phân mảnh khi bảng thật sự lớn **và** query được giới hạn tự nhiên theo key.

Hình dạng của bảng đã phân mảnh

Chọn chiến lược phân mảnh

Pruning, index, bảo trì

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

Câu hỏi liên quan