Mọi Ghi Nhanh Đều Dời Công Việc Đi Nơi Khác
Một bài phân tích sâu về nơi độ bền ghi thực sự xảy ra—SSD cục bộ, ổ đĩa mạng, hay kho đối tượng—và vì sao những con số benchmark nhanh nhất thường che giấu chi phí thực.

Mọi storage engine đều đối mặt cùng một câu hỏi: điều gì phải hoàn tất trước khi một ghi được xác nhận? Câu trả lời rẻ nhất là sao chép byte vào bộ nhớ và trả về. Câu trả lời bền nhất chờ một dịch vụ lưu trữ từ xa hoặc một quorum các máy chủ cơ sở dữ liệu. Ở giữa là SSD cục bộ, nơi sống sót qua sự cố tiến trình nhưng không qua sự cố máy chủ.
Tác giả, Shayon, đi qua các đánh đổi với một khung rõ ràng: tách biệt PUT của client (yêu cầu cơ sở dữ liệu) khỏi PUT của đối tượng (yêu cầu HTTP tới kho đối tượng). Khi bạn tách chúng ra, bạn có thể truy vết chính xác nơi độ trễ và độ bền đang được đánh đổi.
Ảo tưởng WAL cục bộ
Ổ SSD NVMe cục bộ nhanh—có thể 0,1 ms đến 1 ms cho fdatasync()—nhưng nó chỉ bảo vệ chống lại sự cố tiến trình hoặc kernel. Mất máy chủ, mất ghi. Một kho đối tượng như S3 có thể chậm hơn 10 lần (Turso đo trung bình 6,4 ms cho một PUT 4 KB tới S3 Express One Zone), nhưng dịch vụ lưu trữ sở hữu độ bền một khi PUT thành công.
Khoảng cách này hấp dẫn: chênh lệch tốc độ 50 lần là một kết quả benchmark thực, nhưng nó không phải là thuộc tính của mọi thiết bị NVMe và kho đối tượng. Hai đường dẫn sống sót qua các sự cố khác nhau.
Gộp nhóm flush
Gọi fdatasync() sau mỗi ghi giới hạn thông lượng ở tốc độ flush của thiết bị. Một flush 1 ms tuần tự cho phép khoảng 1.000 flush mỗi giây. Gộp nhiều ghi vào một flush—đóng nhóm theo byte, số ghi, hoặc thời gian—chia sẻ chi phí. Nhưng gộp nhóm mang lại đánh đổi riêng: yêu cầu sớm nhất chờ lâu nhất, một lỗi flush làm hỏng cả nhóm, và một yêu cầu hết thời gian có thể đã nằm trong một nhóm mà sau đó mới tới đĩa.
Vượt ra ngoài máy chủ
Nếu bạn muốn sống sót qua sự cố máy chủ, bạn cần một bản sao khác. Một ổ đĩa mạng bền có thể trông giống thiết bị khối cục bộ nhưng đưa độ trễ mạng vào mỗi fdatasync(). Một kho đối tượng dời ranh giới độ bền tới dịch vụ lưu trữ. Một WAL nhân bản đặt các bản sao trên các máy chủ cơ sở dữ liệu khác. Mỗi lựa chọn dời công việc trở lại đường dẫn ghi mà client thấy được.
Hiểu biết chính của tác giả: một biểu đồ độ trễ không nhãn là vô nghĩa. Bạn cần biết thao tác nào đã trả cho tốc độ, điều gì vẫn có thể bị mất sau khi thành công, và hệ thống chấp nhận bao nhiêu dọn dẹp chưa hoàn tất.
Một con số độ trễ NVMe không đầy đủ nếu thiếu điểm xác nhận của nó. Đồng hồ dừng sau khi sao chép byte vào bộ nhớ, sau khi đồng bộ 1 SSD cục bộ, hay sau khi một ổ đĩa từ xa xác nhận ghi?
| Điểm xác nhận | Sống sót qua | Độ trễ | Sử dụng điển hình |
|---|---|---|---|
| Sao chép bộ nhớ | Sự cố tiến trình | Micro giây | Bộ nhớ đệm không bền |
| SSD cục bộ fdatasync() | Sự cố tiến trình/kernel | 0,1–1 ms | WAL, DB một máy chủ |
| Ổ đĩa mạng fdatasync() | Sự cố máy chủ, nhưng có thể không qua trung tâm dữ liệu | 1–10 ms | Ổ đĩa gắn, EBS |
| Kho đối tượng PUT | Sự cố trung tâm dữ liệu (với nhân bản) | 5–50 ms | S3, GCS, Azure Blob |
| WAL nhân bản (quorum) | Nhiều sự cố máy chủ | 10–100 ms | Cơ sở dữ liệu phân tán |
Thảo luận
0 bình luận
Hãy là người đầu tiên thảo luận.