Làm thế nào để scale database?

Question

Accepted Answer

Database thường trở thành **bottleneck** khi hệ thống tăng trưởng. Scale chúng đòi hỏi các kỹ thuật như **replication** (bản sao để scale đọc và availability), **sharding** (chia dữ liệu qua nhiều server), **caching**, và chọn loại database phù hợp.

## Replication — các bản sao của dữ liệu

```text
REPLICATION → duy trì các BẢN SAO của database qua nhiều server:
  → PRIMARY (ghi) + REPLICAS (bản sao):
    - READ SCALING → định tuyến đọc tới replica (giảm tải primary) → xử lý nhiều đọc hơn
    - AVAILABILITY → một replica có thể tiếp quản nếu primary lỗi (failover)
  ⚠️ replication lag → replica có thể trễ một chút (eventual consistency cho đọc)
→ tuyệt vời cho workload NẶNG ĐỌC và availability (hầu hết app đều nặng đọc)
```

## Sharding — chia nhỏ dữ liệu

```text
SHARDING → chia (partition) dữ liệu qua NHIỀU database server (mỗi cái giữ một TẬP CON):
  → phân tán theo một SHARD KEY (vd user ID) → mỗi shard xử lý một phần dữ liệu/tải
  → scale GHI và lưu trữ theo chiều ngang (vượt qua năng lực của một server)
  ⚠️ phức tạp: chọn shard key tốt (phân bố đều), query xuyên shard khó,
    rebalancing → độ phức tạp đáng kể
→ cho khi dữ liệu/lượng ghi vượt quá một server đơn (quy mô lớn)
```

## Các kỹ thuật scaling khác

```text
✓ CACHING → cache kết quả query / dữ liệu nóng (Redis) → giảm lớn tải DB (thường là
  bước đầu tiên và có tác động lớn nhất)
✓ INDEXING & tối ưu query → làm query hiệu quả (trước khi scale out)
✓ Tách đọc/ghi; connection pooling; denormalization (cho performance đọc)
✓ Chọn đúng DATABASE (một số scale theo chiều ngang dễ hơn — NoSQL)
✓ Vertical scaling (database server lớn hơn) → bước đầu đơn giản, nhưng có giới hạn
```

## Tại sao điều này quan trọng

Hiểu cách scale database là giá trị vì **database thường là bottleneck** khi hệ thống tăng trưởng, nên scale nó là một thách thức system design then chốt, phổ biến, khiến đây là kiến thức quan trọng.

Khi hệ thống scale, database thường trở thành yếu tố giới hạn (một database đơn chỉ xử lý được một lượng tải và dữ liệu nhất định), khiến database scaling là một mối quan tâm then chốt.

Hiểu **replication** — duy trì các bản sao (một primary để ghi cộng các replica) để cho phép **read scaling** (định tuyến đọc tới replica để giảm tải primary, giá trị vì hầu hết app nặng đọc) và **availability** (một replica tiếp quản khi lỗi) — là một kỹ thuật cơ bản, được dùng rộng rãi, cùng với hiểu lưu ý về replication lag (eventual consistency cho đọc replica).

Hiểu **sharding** — chia dữ liệu qua nhiều server (mỗi cái giữ một tập con, phân tán theo shard key) để scale **ghi và lưu trữ** theo chiều ngang vượt qua một server — là thiết yếu cho quy mô rất lớn, cùng với độ phức tạp đáng kể của nó (chọn shard key tốt, query xuyên shard khó, rebalancing).

Hiểu **các kỹ thuật khác** — **caching** (thường là bước đầu tiên và có tác động lớn nhất, giảm đáng kể tải database), **indexing và tối ưu query** (làm query hiệu quả trước khi scale out), tách đọc/ghi, denormalization, chọn database scale ngang được, và vertical scaling như bước đầu đơn giản — cung cấp bộ công cụ đầy đủ, với sự khôn ngoan thực tế quan trọng là caching và tối ưu thường đến trước độ phức tạp của sharding.

Vì database thường là bottleneck scaling và scale nó (qua replication cho đọc/availability, sharding cho ghi/lưu trữ, caching, và tối ưu) là một thách thức then chốt, phổ biến, và vì hiểu các kỹ thuật này cùng trade-off của chúng là quan trọng để thiết kế hệ thống scalable, nên hiểu cách scale database là kiến thức system design có giá trị, quan trọng thực tế — giải quyết một bottleneck then chốt, phổ biến, trung tâm của việc scale hệ thống thực, và đòi hỏi hiểu replication, sharding, caching, và tối ưu để xử lý việc scale database mà các hệ thống đang tăng trưởng tất yếu cần.