Database sharding cho hệ thống 1.000 user

Chỉ 1.000 user mà chia DB thành 8 shard, giờ tốn 4 DB admin mà dữ liệu… trống!

Một startup giáo dục Việt Nam, 1.000 user, quyết định shard DB thành 8 phần để “scale như Netflix”. Kết quả? Quản lý phức tạp, dữ liệu rải rác, tốn 4 DB admin, nhưng bảng nào cũng gần trống.

Case thực tế: Sharding “để oai”

• Context: App học online, 1.000 user, dùng MySQL. 
• Quyết định sai: Shard DB thành 8 phần dựa trên user_id, chuẩn bị cho “tỷ user”. 
• Vấn đề: 
• Mỗi shard chỉ chứa 125 user, bảng gần trống, không cần sharding. 
• Query cross-shard phức tạp, latency tăng 500ms. 
• Cần 4 DB admin để maintain 8 shard, tốn 200 triệu/tháng.

Hậu quả: 

• Chi phí cao: Cloud bill và lương DB admin tốn 300 triệu/tháng. 
• Hiệu suất kém: Query chậm vì join cross-shard. 
• Team kiệt sức: DevOps ngập trong config shard.

Phân tích: Tại sao sai?

• Scale quá sớm: 1.000 user không cần sharding, MySQL đơn instance đủ. 
• Không đánh giá workload: Dữ liệu nhỏ, không cần phân mảnh. 
• Over-engineering: Sharding để “oai” thay vì giải quyết vấn đề.

Bài học: Scale khi cần

1. Đánh giá workload: Chỉ shard khi DB >100GB hoặc 1M user. 
2. Dùng single DB: MySQL/PostgreSQL đủ cho <10.000 user. 
3. PoC sharding: Test sharding trên staging trước.

Code mẫu: Query single DB (MySQL)

SELECT * FROM users WHERE id = 123;

Sharding cho 1.000 user là “mua voi lấy ngà”. Dùng single DB, chỉ shard khi dữ liệu thực sự lớn. Đừng scale “để oai”, để team không ngập trong config và ví không “cháy”!

Checklist scale DB: 

• Đánh giá workload (dữ liệu, user). 
• Dùng single DB cho <10.000 user. 
• PoC sharding trên staging. 
• Monitor query performance và DB size.

🎯 Tóm lại: Sharding cho 1.000 user là “tự làm khổ mình”. Dùng single DB, scale khi cần, để không tốn tiền và team không thành “DB admin bất đắc dĩ”!