Tóm tắt: Mở rộng cơ sở dữ liệu bắt đầu bằng việc tìm đúng nơi đang tranh chấp tài nguyên, không phải bằng cách thêm máy.
Thuật ngữ chính: Connection pool: nhóm kết nối dùng lại; replica: bản sao cơ sở dữ liệu để đọc; partition: chia dữ liệu thành các phần nhỏ theo một quy tắc.
Bài toán
Ứng dụng có thể tăng số máy nhanh hơn khả năng nhận kết nối của cơ sở dữ liệu. Pool kết nối quá lớn, truy vấn lặp và giao dịch kéo dài sẽ làm cạn năng lực. Tách dữ liệu quá sớm lại khiến vận hành phức tạp hơn.
Vì sao cách làm đơn giản chưa đủ
CPU chỉ là một kiểu bão hòa. Khóa wait, I/O, buffer churn, tạo connection và sao chép dữ liệu lag thường trở thành bottleneck sớm hơn.
Scale ngang ứng dụng có thể tạo connection storm trong lúc triển khai. Năng lực xử lý plan phải tính max replica và surge, không chỉ steady trạng thái.
Luồng xử lý
unit of work hữu hạn→Pooler
connection budget→Primary
ghi và đọc nhất quán→Replica hoặc partition
offload đã đo
Quyết định kiến trúc
Quản lý connection toàn cục
Chừa năng lực xử lý cho migration và xử lý sự cố. Sau đó, chia phần còn lại cho dịch vụ bằng hard pool limit.
Gắn consistency với use case
Số dư và luồng đọc ngay sau khi ghi đi primary. Chỉ chấp nhận lag khi sản phẩm cho phép.
Partition để pruning hoặc quản lý lifecycle
Chọn key giúp giảm dữ liệu quét hoặc đơn giản hóa retention. Partition không pruning chỉ làm tăng object vận hành.
Phân tích chuyên sâu
Tối ưu tổng công việc
truy vấn 20 ms chạy một triệu lần có thể quan trọng hơn report 2 giây chạy mỗi giờ. Cần kết hợp tần suất, độ trễ và số row đụng tới.
Sharding là quyết định về quyền sở hữu
Shard key quyết định thao tác nào nằm cục bộ. Cross-shard transaction, uniqueness và rebalance phải được thiết kế trước lần tách đầu tiên.
Các bước triển khai
- Đặt connection budget toàn hệ thống rồi chia cho dịch vụ, job và đợt triển khai.
- Tối ưu truy vấn có tổng chi phí cao nhất bằng execution plan và dữ liệu gần môi trường thật.
- Chỉ thêm replica hoặc partition sau khi có consistency và routing rule.
Ví dụ kỹ thuật: Transaction hữu hạn và đọc theo consistency
with db.transaction(timeout = 800ms) as tx:
order = tx.orders.lock(orderId)
tx.orders.update(orderId, nextState)
readTarget = PRIMARY if session.justWrote else REPLICA
return query(readTarget, tenantId, orderId)Đặt network call ngoài giao dịch cơ sở dữ liệu. Nếu không, timeout bên ngoài sẽ biến thành khóa giữ tài nguyên của khách hàng khác.
Các tình huống lỗi cần tính trước
- Surge lúc triển khai mở nhiều connection hơn cơ sở dữ liệu cho phép.
- Replica lag trả entitlement cũ ngay sau khi khách hàng mua.
- Build chỉ mục mới chặn hoặc làm bão hòa luồng ghi môi trường thật.
Tín hiệu cần giám sát
| Tín hiệu | Ý nghĩa |
|---|---|
| Connection active so với waiting | Phân biệt công việc hữu ích với tranh chấp pool. |
| Tổng thời gian truy vấn và rows examined | Ưu tiên theo chi phí trên toàn hệ thống. |
| khóa wait và replica lag | Làm rõ rủi ro consistency và tail độ trễ. |
Cách kiểm chứng thiết kế
- Chạy max application replica cộng đợt triển khai surge với cơ sở dữ liệu môi trường thử nghiệm.
- Chủ động tạo replica lag và kiểm thử mọi hành trình đọc ngay sau khi ghi.
- Build rồi gỡ chỉ mục trên volume gần môi trường thật và đo ảnh hưởng ghi.
Kế hoạch triển khai an toàn
Đưa dashboard truy vấn và pool vào trước. Giảm pool quá lớn từng bước. Sau đó, sửa truy vấn lộ ra. Thêm replica cho đúng một đường đọc chấp nhận stale. Xem partition hoặc sharding là chương trình riêng có rollback và đối soát dữ liệu.
Checklist trước khi đưa vào vận hành
- Mọi transaction có timeout và phạm vi nhỏ, dễ dự đoán.
- Mỗi chỉ mục phải chứng minh lợi ích đọc và chi phí ghi.
- Replica lag là một phần của routing logic trong ứng dụng.
Kết luận
cơ sở dữ liệu có khả năng mở rộng được bảo vệ bằng budget và access pattern dự đoán được trước khi bị chia nhỏ.