Giới thiệu
Cách đây một năm, tôi đã làm việc với một nhóm có kế hoạch sử dụng Amazon DynamoDB để lưu trữ dữ liệu ứng dụng. Là một người mới, tôi rất hào hứng với ý tưởng sử dụng một cơ sở dữ liệu NoSQL không máy chủ, mở rộng quy mô. Tuy nhiên, một sự kiện đã xảy ra khiến tôi không thể hiểu rõ vào thời điểm đó: kỹ sư trưởng của chúng tôi đã đặt ra một câu hỏi đơn giản:
"Năng lực đọc và ghi của hệ thống này sẽ như thế nào?"
Câu trả lời là: rất cao. Ngay lập tức, anh ấy đã gợi ý rằng chúng tôi không nên chọn DynamoDB. Tôi đã hỏi anh ấy "Tại sao?" và anh ấy trả lời:
"Bởi vì trong DynamoDB, bạn bị tính phí nhiều hơn cho việc đọc và ghi, không chỉ là lưu trữ. Đối với một hệ thống có khối lượng đọc/ghi lớn, chi phí sẽ tăng vọt."
Lúc đó, điều này không đi vào đầu tôi. Lưu trữ = chi phí là toàn bộ mô hình tư duy của tôi về cơ sở dữ liệu.
Gần đây, tôi đã tìm được câu trả lời cho vấn đề này.
Mô Hình Giá của DynamoDB (Ánh Sáng Thực Sự)
Khác với các cơ sở dữ liệu truyền thống, nơi chi phí chủ yếu do lưu trữ, DynamoDB đã đảo ngược mô hình:
- Lưu trữ: Rất rẻ (~\$0.25/GB-tháng).
- RCUs (Đơn vị Năng lực Đọc): Bạn phải trả cho mỗi yêu cầu đọc (dựa trên kích thước mục và tính nhất quán).
- WCUs (Đơn vị Năng lực Ghi): Bạn phải trả cho mỗi yêu cầu ghi (dựa trên kích thước mục).
- Chỉ mục (LSI/GSI): Mỗi lần ghi sẽ cập nhật chỉ mục → làm tăng mức sử dụng WCU của bạn.
Vì vậy, nếu bạn có hàng triệu yêu cầu đọc và ghi mỗi giây, hóa đơn của bạn sẽ không dựa trên số GB bạn lưu trữ mà là dựa trên số hoạt động bạn thực hiện.
Kiến Trúc Hệ Thống DynamoDB + Năng Lực Tăng Cường + Lưu Cache
Dưới đây là cái nhìn tổng quan về cách DynamoDB xử lý các yêu cầu và tối ưu hóa thông lượng:
🔹 Các Khái Niệm Chính
-
Phân vùng & Năng lực
- Mỗi phân vùng có RCUs/WCUs và thùng token riêng cho năng lực tăng cường.
- Năng lực chưa sử dụng có thể tích lũy lên tới ~5 phút.
- Các đột biến đột ngột sẽ được hấp thu từ thùng token trước khi xảy ra việc giới hạn.
-
Lưu Cache
- DynamoDB có thể sử dụng DynamoDB Accelerator (DAX) hoặc lưu cache nội bộ cho các mục nóng.
- Các yêu cầu đọc từ bộ nhớ cache không tiêu tốn RCUs, giảm đáng kể chi phí cho các khối lượng công việc nặng về đọc.
- Ngay cả khi không có DAX, DynamoDB cũng sử dụng các chiến lược lưu trữ và caching nội bộ để duy trì tỷ lệ hit cao (~99.7%), giảm độ trễ.
-
Bản Sao
- Mỗi phân vùng được sao chép qua nhiều AZ để đảm bảo độ bền và khả năng sẵn có.
- Các bản sao không làm tăng thông lượng; RCUs/WCUs vẫn được tính theo phân vùng.
Ý Nghĩa Thực Sự Của Kỹ Sư Trưởng
Giờ đây, tôi cuối cùng đã hiểu những gì kỹ sư trưởng của tôi muốn nói khi anh ấy nói:
"Chúng ta bị tính phí không phải cho việc lưu trữ, mà cho những gì chúng ta đọc và ghi."
Anh ấy không chỉ đang nói về chi phí. Anh ấy đang nói về việc chọn công cụ phù hợp cho khối lượng công việc.
- Đối với khối lượng công việc đọc/ghi vừa phải → DynamoDB thật tuyệt vời: có thể mở rộng, được quản lý hoàn toàn, và có thể dự đoán.
- Đối với khối lượng công việc đọc/ghi nặng → chi phí có thể không hợp lý so với các lựa chọn khác (Aurora, Cassandra, hoặc S3 + các lớp cache).
Những Ghi Nhớ Quan Trọng
- Yếu tố chi phí lớn nhất của DynamoDB là RCUs & WCUs, không phải lưu trữ.
- Năng lực tăng cường + caching là rất quan trọng cho hiệu suất có thể dự đoán và tiết kiệm chi phí.
- Luôn hỏi: "Hệ thống này có khối lượng đọc/ghi nặng như thế nào?" trước khi chọn DynamoDB.
- Những người cố vấn tốt sẽ thúc đẩy bạn suy nghĩ về mô hình khối lượng công việc, không chỉ công nghệ.
Kết Luận
Ngày hôm đó, tôi không hiểu tại sao DynamoDB không được chọn. Hôm nay, sau khi thấy cách mà kiến trúc, năng lực tăng cường và caching hoạt động cùng nhau, tôi đã hiểu.
Và thành thật mà nói, bài học này không chỉ về DynamoDB mà còn về cách mà mỗi quyết định thiết kế hệ thống đều liên quan không chỉ đến công nghệ, mà còn đến mô hình chi phí, mô hình khối lượng công việc, và chiến lược hiệu suất.
Đôi khi, bạn chỉ kết nối các điểm sau nhiều năm.
