Jepsen phát hiện các lỗ hổng nghiêm trọng về an toàn và ổn định trong ParticleDB 1.1.4

Công ty kiểm thử độc lập Jepsen vừa công bố một báo cáo toàn diện về ParticleDB phiên bản 1.1.4, chỉ ra những vi phạm nghiêm trọng về tính an toàn và các vấn đề ổn định trong cơ sở dữ liệu này. Phân tích được thực hiện giữa các phiên bản 1.1.4 và 1.1.18.11.rc-22, làm nổi bật sự khác biệt giữa các tuyên bố tiếp thị về xác minh hình thức (formal verification) và hành vi thực tế của hệ thống dưới tải cao. Đối với các kỹ sư đang đánh giá hạ tầng cho tác nhân AI hoặc ứng dụng thông lượng cao, những phát hiện này đặt ra câu hỏi lớn về khả năng sẵn sàng của nền tảng cho môi trường sản xuất.

Chuyện gì đã xảy ra

ParticleDB, được phát triển bởi Orkes để hỗ trợ nền tảng điều phối quy trình làm việc Conductor của họ, nhằm mục đích hợp nhất SQL giao dịch, lưu trữ khóa-giá trị, tìm kiếm vector và phân tích vào một engine duy nhất dựa trên Rust. Công ty quảng bá cơ sở dữ liệu này như một giải pháp cung cấp đầy đủ tuân thủ ACID và hiệu suất nhanh hơn PostgreSQL nhiều bậc độ lớn, tập trung vào khối lượng công việc của tác nhân AI. Để xác thực các tuyên bố này trước khi phát hành rộng rãi, Orkes đã thuê Jepsen kiểm thử mã nguồn đã tái cấu trúc, bắt đầu từ phiên bản 1.1.4. Các bài kiểm thử tập trung vào hành vi nút đơn (single-node), vì các bản build được cung cấp không hỗ trợ các tính năng cụm có sao chép (replicated cluster features) vốn chỉ khả dụng trong các triển khai đám mây doanh nghiệp.

Đội ngũ Jepsen đã xác định 96 vấn đề riêng biệt thuộc nhiều danh mục khác nhau, bao gồm tính sẵn sàng, tính năng bị lỗi, đồng thời giao dịch và hỏng trạng thái. Mặc dù một số vấn đề đã được khắc phục trong các bản release candidate sau đó, báo cáo vẫn chi tiết hóa các bất thường nghiêm trọng như sập máy chủ tự phát mà không có thông báo lỗi, deadlock chỉ sau hai giao dịch đồng thời, và việc bỏ qua âm thầm các mức cô lập giao dịch. Quy trình kiểm thử bao gồm mô phỏng sập tiến trình, hỏng đĩa và lỗi mạng để tạo áp lực lên các đảm bảo về độ bền (durability) và tính nhất quán (consistency) của hệ thống.

Một điểm gây tranh cãi chính là tài liệu xung quanh mức cô lập giao dịch và độ bền. Trang chủ của ParticleDB tuyên bố "Full ACID" và an toàn "được chứng minh hình thức" (formally proven) thông qua TLA+, nhưng không có đặc tả TLA+ nào được cung cấp trong quá trình hợp tác. Hơn nữa, tài liệu cho các chế độ giao dịch như occ (Optimistic Concurrency Control - Điều khiển đồng thời lạc quan) và groupsync (đồng bộ WAL) chứa thông tin mâu thuẫn về việc chúng có cung cấp độ bền mạnh hay mức cô lập tuần tự hóa (serializable isolation) hay không. Trong nhiều trường hợp, cơ sở dữ liệu âm thầm bỏ qua các lệnh SQL tiêu chuẩn dùng để thiết lập mức cô lập, thay vào đó mặc định sử dụng các cờ khởi động (startup flags) được giải thích kém cỏi trong tài liệu công khai.

Cơ chế hoạt động

Jepsen kiểm thử các hệ thống phân tán bằng cách tiêm lỗi (fault injection) và quan sát xem hệ thống có duy trì các mô hình nhất quán đã tuyên bố hay không. Đối với ParticleDB, đội ngũ đã sử dụng kết hợp các khối lượng công việc SQL hiện có và các bài kiểm thử mới được thiết kế riêng cho các tính năng độc đáo của cơ sở dữ liệu. Họ sử dụng trình kiểm tra Elle để phân tích đồ thị phụ thuộc giao dịch nhằm tìm kiếm các chu trình (cycles), vốn chỉ ra vi phạm tính tuần tự hóa (serializability) hoặc mức cô lập snapshot. Các bài kiểm thử chạy trên cả client JDBC Postgres chính thức và SDK Java gốc của ParticleDB, mặc dù SDK này ban đầu không khả dụng như một dependency Maven.

Bộ kiểm thử bao gồm các khối lượng công việc thực hiện đọc và ghi ngẫu nhiên, thêm vào cấu trúc danh sách và kiểm tra tính nhất quán nội tại trong từng giao dịch đơn lẻ. Một phương pháp đáng chú ý là workload compare, sinh ra các câu lệnh SQL ngẫu nhiên và thực thi chúng trên cả ParticleDB lẫn PostgreSQL. Nếu kết quả khác biệt, công cụ sẽ thu nhỏ trường hợp kiểm thử để tái hiện lỗi. Cách tiếp cận này cho thấy ParticleDB thường không khớp với hành vi của PostgreSQL đối với các truy vấn cơ bản, chỉ ra rằng việc triển khai giao thức truyền dẫn Postgres (Postgres wire protocol) là chưa hoàn chỉnh hoặc có lỗi.

Việc tiêm lỗi đóng vai trò then chốt trong việc phơi bày các vấn đề về độ bền. Bằng cách sử dụng LazyFS để mô phỏng mất các ghi chưa được fsync và đột ngột giết các tiến trình, Jepsen đã xác minh xem Write-Ahead Log (WAL) có bảo toàn dữ liệu đúng cách hay không. Các bài kiểm thử bao phủ ba chế độ đồng bộ WAL: sync, groupsync và nosync. Sự khác biệt giữa hành vi được tài liệu hóa của các chế độ này và hiệu suất thực tế của chúng dẫn đến một số phát hiện nơi dữ liệu có thể bị mất hoặc hỏng ngay cả khi người dùng tin rằng họ đã chọn các thiết lập an toàn.

Chi tiết chính

• Jepsen phát hiện 96 vấn đề trong ParticleDB, dao động từ nút thắt hiệu suất đến vi phạm an toàn dữ liệu nghiêm trọng.
• Tài liệu tuyên bố an toàn "được chứng minh hình thức" qua TLA+, nhưng không có đặc tả nào được cung cấp để xác minh tuyên bố này.
• Các mức cô lập giao dịch được thiết lập qua SQL thường bị bỏ qua âm thầm, với hành vi được điều khiển bởi các cờ khởi động mờ ám thay thế.
• Deadlock nghiêm trọng xảy ra ở các phiên bản lên đến 1.1.18.11.rc-6, đôi khi làm đóng băng nút chỉ sau hai giao dịch đồng thời.
• Hỗ trợ cho các tính năng Postgres tiêu chuẩn là chưa hoàn chỉnh, với các lỗi trong prepared statements, hàm tổng hợp (aggregates) trong biểu thức CASE và toán tử lũy thừa.
• Sập máy chủ tự phát không kèm log lỗi được quan sát thấy ở phiên bản 1.1.18.6, khiến hệ thống không đáng tin cậy cho các tác vụ chạy dài hạn.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và trưởng nhóm kỹ thuật, báo cáo này là một bài học cảnh giác về việc dựa vào các tuyên bố tiếp thị cho hạ tầng quan trọng. ParticleDB định vị mình là giải pháp hợp nhất cho các tác nhân AI, một lĩnh vực mà tính nhất quán dữ liệu là tối thượng. Việc phát hiện ra rằng các mức cô lập giao dịch có thể bị bỏ qua âm thầm có nghĩa là các ứng dụng giả định tính nhất quán mạnh có thể gặp phải các race condition (điều kiện cạnh tranh) tinh vi, khó gỡ lỗi. Khi một cơ sở dữ liệu tuyên bố "Full ACID" nhưng hành xử với mức cô lập snapshot hoặc các đảm bảo yếu hơn, các nhà phát triển có thể thiết kế hệ thống thất bại dưới tải đồng thời.

Các vấn đề bất ổn, bao gồm deadlock và sập máy chủ không rõ nguyên nhân, ảnh hưởng trực tiếp đến tính sẵn sàng của hệ thống. Trong môi trường sản xuất, một cơ sở dữ liệu đóng băng sau vài giây hoạt động đồng thời hoặc sập mà không ghi log lỗi là không thể vận hành bền vững. Những lỗ hổng này buộc các đội ngũ phải đầu tư mạnh vào giám sát và chiến lược workaround (lách luật), triệt tiêu các lợi ích hiệu suất đã hứa hẹn. Hơn nữa, việc triển khai chưa hoàn chỉnh giao thức truyền dẫn Postgres có nghĩa là di chuyển các ứng dụng hiện có sang ParticleDB không phải là thay thế trực tiếp (drop-in replacement), đòi hỏi refactor và kiểm thử đáng kể.

Sự khác biệt giữa tài liệu công khai và hướng dẫn dành cho operator nội bộ cũng làm nổi bật khoảng trống về độ chín muồi. Khi các thuộc tính an toàn thiết yếu được mô tả khác nhau trong văn bản trợ giúp, trang chủ và tài liệu nội bộ, người dùng không thể đưa ra quyết định sáng suốt về rủi ro. Đối với các tổ chức đang cân nhắc ParticleDB cho quy trình làm việc AI, sự thiếu vắng các bằng chứng an toàn minh bạch, có thể xác minh được và sự tồn tại của các lỗi hỏng dữ liệu đã biết cho thấy công nghệ này chưa sẵn sàng cho các triển khai quan trọng (mission-critical).

Bạn có thể làm gì

• Tránh sử dụng các phiên bản ParticleDB trước 1.1.18.11.rc-7 trong môi trường sản xuất do các vấn đề deadlock và sập máy chủ đã biết.
• Xác minh hành vi cô lập giao dịch bằng kinh nghiệm thực tế thay vì dựa vào tài liệu; kiểm tra race condition dưới tải đồng thời.
• Không giả định tương thích hoàn toàn với Postgres; kiểm toán các truy vấn SQL của bạn để tìm các tính năng không được hỗ trợ như hàm tổng hợp trong câu lệnh CASE hoặc toán tử lũy thừa.
• Nếu sử dụng ParticleDB, hãy ưu tiên các chế độ table-2pl hoặc serializable cho dữ liệu quan trọng, bất chấp chi phí hiệu suất tiềm tàng, để đảm bảo tính nhất quán mạnh hơn.
• Giám sát hỏng dữ liệu âm thầm bằng cách triển khai checksum cấp ứng dụng hoặc các bài kiểm tra so sánh với một cơ sở dữ liệu đáng tin cậy như PostgreSQL.
• Yêu cầu quyền truy cập vào hướng dẫn operator nội bộ hoặc đặc tả an toàn chi tiết từ nhà cung cấp trước khi cam kết sử dụng nền tảng.