Khi website hay ứng dụng phát triển nhanh, lượng người dùng và dữ liệu tăng gấp hàng triệu lần, database đơn lẻ trở thành điểm nghẽn. Database sharding là kỹ thuật chia một cơ sở dữ liệu lớn thành nhiều phần nhỏ hơn, gọi là shard, phân tán trên nhiều máy chủ khác nhau — tương tự cách hệ thống phân mảnh đĩa cứng để tăng hiệu năng.
Horizontal vs Vertical Sharding
Sharding có 2 hình thức cơ bản:
- Horizontal sharding (phân mảnh ngang): Mỗi shard chứa cùng số cột, nhưng các hàng khác nhau. Ví dụ: bảng orders có 100 triệu dòng → chia theo 4 shard theo khoảng ID (1–25tr, 25–50tr, 50–75tr, 75–100tr).
- Vertical sharding (phân mảnh dọc): Mỗi shard chứa tập con các cột khác nhau. Ví dụ: shard profiles lưu thông tin người dùng, shard auth lưu mật khẩu/quyền, shard analytics lưu hành vi.
Hầu hết hệ thống lớn (Instagram, Facebook, Uber) dùng horizontal sharding vì nó giảm tải tốt nhất cho bảng lớn có hàng triệu bản ghi.
Các chiến lược sharding phổ biến
| Chiến lược | Cách hoạt động | Ưu điểm | Nhược điểm |
|---|---|---|---|
| Range-based | Chia theo khoảng giá trị (ID, ngày, vùng) | Dễ debug, truy vấn theo range nhanh | Hotspot nếu data không đều |
| Hash-based | Hash key → modulo số shard | Phân bố đều, dễ mở rộng | Khó truy vấn range, thêm/xóa shard phức tạp |
| Directory-based | Bảng lookup ánh xạ key → shard | Linh hoạt, thay đổi mapping dễ | Lookup table thành bottleneck |
| Geo-based | Chia theo khu vực địa lý | Latency thấp cho user local, tuân thủ GDPR | Khó cân bằng tải nếu user không đều |
Khi nào nên shard?
Sharding không phải giải pháp mặc định. Áp dụng khi:
- Database đơn lẻ đạt ngưỡng CPU/RAM/IOPS tối đa — ví dụ PostgreSQL > 50% CPU liên tục, InnoDB buffer pool đầy.
- Lượng dữ liệu > 500GB–1TB và tăng 20–30%/tháng.
- Đọc/ghi > 10,000 QPS mà read replica không cải thiện.
- Khách hàng toàn cầu cần low-latency cho từng khu vực.
Trước khi shard, thử các bước tối ưu đơn giản: query optimization, indexing, caching (Redis), read replica, partition — vì sharding tăng đáng kể độ phức tạp vận hành và application logic.
Thách thức của sharding
Joins và transactions xuyên shard
Join giữa 2 bảng nằm trên shard khác nhau rất tốn kém. Có 3 hướng: denormalize sẵn dữ liệu, dùng distributed SQL (CockroachDB, TiDB), hoặc chấp nhận eventual consistency và join ở application layer.
Rebalancing khi thêm shard
Thêm shard mới yêu cầu di chuyển data — dùng consistent hashing hoặc hash function có thể mở rộng (VNodes) để giảm thiểu dữ liệu phải di chuyển.
Hotspot key
Một key cực hot (ví dụ: influencer có triệu follower) đổ toàn bộ request vào 1 shard. Giải pháp: thêm ngẫu nhiên (jitter) vào key, hoặc cache riêng cho hot key.
Công cụ và framework
- Vitess: Sharding proxy cho MySQL, dùng bởi YouTube, Slack. Tự động vito routing, connection pooling, query rewriting.
- Citus: Extension PostgreSQL thành distributed database — shard transparent, hỗ trợ joins xuyên shard giới hạn.
- ProxySQL / MaxScale: Routing layer cho MySQL/MariaDB, nhận biết shard từ query context.
- Custom application sharding: Nhiều hệ thống lớn tự implement: Instagram (ID-based), Uber (Geobase), Facebook (MyRocks sharded MySQL).
Ví dụ thực tế: Instagram và Vitess
Instagram sử dụng Vitess để sharding PostgreSQL cho hàng tỷ nội dung media. Shard key là user_id, cho phép truy vấn profile và post của một người dùng luôn ở cùng một shard. Khi user nổi tiếng gây hotspot, team dùng read replica và cache Redis để giảm tải. Kiến trúc này giúp Instagram mở rộng từ triệu lên tỷ người dùng mà không cần rewrite application.
Kết luận
Sharding là kỹ thuật mạnh để đưa database lên quy mô triệu người dùng, nhưng không phải giải pháp ban đầu cho mọi vấn đề. Bắt đầu từ đơn giản: tối ưu query, thêm index, cache, read replica. Khi mọi kỹ thuật đó đã bão, hãy sharding có chiến lược rõ ràng về shard key, rebalancing, và cross-shard query handling.
Nguồn tham khảo: Database Sharding Explained — dev.to, Database Sharding With Real Examples — dev.to, Database Sharding Strategies Deep Dive — dev.to
