Cách tiếp cận thử nghiệm của một developer trong việc xây dựng cơ sở dữ liệu hiệu suất cao sử dụng io_uring của Linux và hệ thống dual write-ahead log (WAL) đã châm ngòi cho một cuộc tranh luận kỹ thuật gay gắt trong cộng đồng lập trình. Tranh cãi tập trung vào việc liệu thiết kế được đề xuất có thực sự duy trì được các đảm bảo về tính bền vững mà các cơ sở dữ liệu được kỳ vọng cung cấp hay không.
Developer này đã tạo ra một cơ sở dữ liệu key-value thử nghiệm có tên Poro, triển khai cái mà họ gọi là thiết kế dual WAL để đạt được hiệu suất tốt hơn với các hoạt động I/O bất đồng bộ. Thay vì cách tiếp cận truyền thống là ghi các thay đổi vào đĩa và chờ xác nhận trước khi phản hồi cho client, hệ thống này sử dụng hai log riêng biệt: một intent WAL ghi lại các hoạt động được lên kế hoạch và một completion WAL xác nhận các hoạt động thành công.
Các Thành Phần Kỹ Thuật Chính
- Intent WAL: Ghi lại các hoạt động được lên kế hoạch trước khi thực thi
- Completion WAL: Ghi lại việc hoàn thành thành công các hoạt động
- io_uring: Giao diện I/O bất đồng bộ của Linux với các hàng đợi gửi/hoàn thành
- Circular Buffers: Xử lý hàng loạt các mục để cải thiện hiệu suất (ngưỡng 75% dung lượng)
- Checksum Verification: Kiểm tra tính toàn vẹn dữ liệu trong quá trình khôi phục
- Separate Ring Buffers: Ngăn chặn tình trạng chặn đầu hàng giữa các loại WAL
Cộng Đồng Đặt Câu Hỏi Về Các Nguyên Tắc Cơ Bản Của Cơ Sở Dữ Liệu
Cộng đồng kỹ thuật đã nêu lên những lo ngại nghiêm trọng về thiết kế cơ bản. Nhiều developer đã chỉ ra điều có vẻ như là một lỗ hổng nghiêm trọng trong cách tiếp cận này. Hệ thống trả về thành công cho client sau khi ghi cả intent và completion record một cách bất đồng bộ, nhưng trước khi đảm bảo những record này thực sự được lưu vào đĩa. Điều này có nghĩa là client có thể nhận được xác nhận rằng dữ liệu của họ đã được lưu, chỉ để mất dữ liệu đó nếu hệ thống crash ngay sau đó.
Điều này có nghĩa là client có thể nhận được thành công cho một request, mà nếu hệ thống crash ngay sau đó, khi replay, không nhất thiết có request đó được ghi lại không? Làm sao điều đó không vi phạm ACID?
Các thuộc tính ACID (Atomicity, Consistency, Isolation, Durability) là những yêu cầu cơ bản cho các hệ thống cơ sở dữ liệu đáng tin cậy. Khía cạnh durability cụ thể yêu cầu rằng một khi transaction được xác nhận là thành công, dữ liệu phải tồn tại qua các lỗi hệ thống. Những người chỉ trích cho rằng cách tiếp cận dual WAL về cơ bản phá vỡ đảm bảo này.
Các Tuyên Bố Về Hiệu Suất Bị Đặt Dưới Sự Giám Sát
Trong khi developer báo cáo những cải thiện hiệu suất ấn tượng - tuyên bố tăng 10 lần throughput transaction - các thành viên cộng đồng đặt câu hỏi liệu những lợi ích này có đến với cái giá của độ tin cậy dữ liệu hay không. Một số developer có kinh nghiệm đã bày tỏ sự bối rối về việc làm thế nào hai hoạt động ghi bất đồng bộ có thể nhanh hơn hoặc đáng tin cậy hơn một hoạt động ghi đồng bộ duy nhất thực sự đảm bảo tính bền vững của dữ liệu.
Cuộc tranh luận cũng đã làm nổi bật các cách tiếp cận thay thế được sử dụng trong các hệ thống production. Một số developer đã chia sẻ các kỹ thuật chống crash của riêng họ, chẳng hạn như sử dụng các file hash và length riêng biệt với các hoạt động rename atomic, hoặc triển khai các cấu trúc B-tree append-only thống nhất WAL và lưu trữ dữ liệu.
Phương pháp WAL Truyền thống so với Phương pháp WAL Kép
| Khía cạnh | WAL Truyền thống | WAL Kép (Đề xuất) |
|---|---|---|
| Thao tác Ghi | Ghi đồng bộ đơn lẻ | Hai lần ghi bất đồng bộ (ý định + hoàn thành) |
| Phản hồi Client | Sau khi xác nhận flush disk | Sau khi các thao tác bộ nhớ hoàn thành |
| Đảm bảo Tính bền vững | Mạnh (dữ liệu tồn tại sau sự cố) | Đáng ngờ (dữ liệu có thể bị mất) |
| Tuyên bố về Hiệu suất | Cơ sở | Báo cáo cải thiện 10 lần |
| Quy trình Khôi phục | Áp dụng tất cả các mục đã commit | Chỉ áp dụng các mục có cả bản ghi ý định và hoàn thành |
Chi Tiết Triển Khai Còn Thiếu Gây Ra Sự Bối Rối
Phần lớn sự chỉ trích của cộng đồng xuất phát từ những giải thích không rõ ràng trong đề xuất ban đầu. Một số developer nghi ngờ rằng việc triển khai thực tế có thể bao gồm một bước còn thiếu mà hệ thống chờ cả hai WAL record được flush vào đĩa trước khi trả về thành công cho client. Tuy nhiên, điều này sẽ loại bỏ những lợi ích hiệu suất được tuyên bố, vì chờ hai hoạt động đĩa có thể sẽ chậm hơn chờ một hoạt động.
Cuộc thảo luận cũng đã nêu lên câu hỏi về các kịch bản truy cập đồng thời. Nếu nhiều thread đang truy cập dữ liệu đang được ghi bất đồng bộ, hệ thống có thể đối mặt với những thách thức consistency bổ sung ngoài các lo ngại durability cơ bản.
Ý Nghĩa Rộng Lớn Hơn Cho Thiết Kế Cơ Sở Dữ Liệu
Bất chấp sự chỉ trích, thí nghiệm đã khơi dậy những thảo luận có giá trị về kiến trúc cơ sở dữ liệu hiện đại và tiềm năng của io_uring cho các hệ thống lưu trữ hiệu suất cao. Giao diện io_uring của Linux thực sự cung cấp những lợi thế thực sự cho các ứng dụng có thể tận dụng đúng cách I/O bất đồng bộ, nhưng cộng đồng cơ sở dữ liệu có vẻ hoài nghi rằng những lợi ích này có thể được thực hiện mà không hy sinh các đảm bảo độ tin cậy cơ bản.
Cuộc tranh luận tiếp tục khi các developer tìm kiếm sự làm rõ về các chi tiết triển khai thực tế và liệu hệ thống được đề xuất có thể thực sự duy trì tuân thủ ACID trong khi mang lại những cải thiện hiệu suất được hứa hẹn hay không.
*Write-ahead log (WAL): Một kỹ thuật mà các thay đổi được ghi vào file log trước khi được áp dụng vào cơ sở dữ liệu chính, đảm bảo dữ liệu có thể được khôi phục sau các crash.*io_uring: Một giao diện kernel Linux cung cấp các hoạt động I/O bất đồng bộ hiệu quả, cho phép các ứng dụng gửi nhiều hoạt động mà không bị block.
*ACID: Một tập hợp các thuộc tính (Atomicity, Consistency, Isolation, Durability) đảm bảo các transaction cơ sở dữ liệu đáng tin cậy.
Tham khảo: Async I/O on Linux and durability