Jepsen chỉ ra hàng loạt lỗi nghiêm trọng trong ParticleDB 1.1.4: từ mất tính nhất quán đến dữ liệu "zombie"

Jepsen vừa công bố báo cáo kiểm thử đối với ParticleDB 1.1.4, cơ sở dữ liệu thế hệ mới viết bằng Rust do Orkes phát triển. Kết quả cho thấy sản phẩm này mắc vô số lỗi cơ bản ngay cả khi chạy một node duy nhất, một client duy nhất và không có bất kỳ sự cố nào — từ vi phạm ràng buộc, SELECT trả về kết quả sai, đến dữ liệu bị hỏng không thể xóa hoặc cập nhật.

ParticleDB là gì và vì sao đáng quan tâm?

ParticleDB hướng tới việc hợp nhất nhiều loại workload vào một engine duy nhất: SQL giao dịch, key-value store, tìm kiếm vector, phân tích thời gian thực và các hàm do người dùng định nghĩa gọi là Particles. Mục tiêu khá tham vọng — thay thế sự phối hợp phức tạp giữa database, cache, hàng đợi và search index trong các ứng dụng hiện đại, đặc biệt là các ứng dụng AI.

Được Orkes xây dựng để phục vụ nền tảng điều phối workflow Conductor, ParticleDB tự hào nhanh hơn Postgres "nhiều bậc độ lớn" và tương thích với các giao thức quen thuộc như Postgres và Redis. Phiên bản 1.0.0 đã được dùng làm database nền cho một số cụm Conductor của khách hàng. Tuy nhiên, phiên bản build mà Orkes cung cấp cho Jepsen không hỗ trợ replication (tính năng chỉ có trên bản cloud enterprise), nên báo cáo chỉ đánh giá hành vi single-node.

Tài liệu mô tả mơ hồ và mâu thuẫn

Một trong những vấn đề nổi bật là mức độ cô lập giao dịch (transaction isolation). Trang chủ ParticleDB quảng cáo "Full ACID. 159K TPS." nhưng ngay bên dưới lại ghi "snapshot isolation" — vốn không phải mức cô lập đầy đủ.

Nghiêm trọng hơn, ParticleDB bỏ qua hoặc từ chối câu lệnh SET TRANSACTION ISOLATION LEVEL tiêu chuẩn của SQL. Trong một số trường hợp nó khuyên người dùng chọn READ COMMITTED, trong số khác nó chấp nhận câu lệnh rồi âm thầm bỏ qua. Thay vào đó, mức cô lập thực tế do tham số --txn-mode khi khởi động quyết định.

Các tài liệu nội bộ mô tả bốn chế độ fast, occ, zero-copy-occ, table-2pl với những mô tả khó hiểu và mâu thuẫn nhau. Ví dụ, chế độ occ được ghi là "an toàn cho hầu hết OLTP" trong CLI, nhưng tài liệu vận hành lại nói nó tương đương Snapshot Isolation, còn table-2pl mới là "Strong Serializable". Jepsen cũng ghi nhận không hề có bản đặc tả TLA+ nào dù trang chủ quảng cáo sản phẩm đã được "chứng minh hình thức".

Jepsen đánh giá tính an toàn dựa trên chính tài liệu và các tuyên bố marketing — vì thế những mâu thuẫn này khiến việc xác định "đúng hay sai" gần như bất khả thi.

Những lỗi khiến database gần như không dùng được

Qua kiểm thử các phiên bản từ 1.1.4 đến 1.1.18.11.rc-22, Jepsen phát hiện một danh sách dài các lỗi chí mạng:

• Prepared statement trả về phản hồi sai định dạng, khiến JDBC driver của Postgres ném NoSuchElementException. Vì driver tự động chuyển sang prepared statement sau vài lần gọi, database gần như không thể sử dụng.
• Hầu hết truy vấn Postgres thất bại với lỗi "Bad value for type long" ở các bản 1.1.18.11.rc-7 đến rc-19.
• Không thể xác thực username qua giao thức Postgres — không có tùy chọn nào hoạt động, chỉ có thể tắt xác thực hoàn toàn bằng --no-auth.
• SDK Java chính thức không thể thực thi transaction ở phiên bản 1.0.0.
• Mệnh đề WHERE bị bỏ qua trong nhiều trường hợp: SELECT 5 WHERE FALSE vẫn trả về một dòng, predicate trên cột không tồn tại vẫn khớp dữ liệu, và WHERE b = 5 lại trả về dòng có b = 6.

Ràng buộc bị vi phạm, join sai, dữ liệu "zombie"

Đáng lo ngại nhất là các lỗi xảy ra ngay cả trong điều kiện lý tưởng:

• Ràng buộc NOT NULL bị bỏ qua: chèn NULL vào cột NOT NULL vẫn thành công, tạo ra dòng "vô hình" — SELECT COUNT(*) đếm được 1 nhưng SELECT * trả về 0 dòng.
• Ràng buộc UNIQUE không được thực thi, cho phép chèn trùng lặp. Thậm chí UPDATE có thể tạo ra nhiều dòng cùng khóa chính, và khóa chính có thể bị đặt thành NULL.
• JOIN bảng hỏng nặng: không join được cột int với real dù 2.0 = 2; tên cột bị đổi thành right.a; join bảng rỗng trả về 0 dòng; và đặc biệt là join có thể khớp nhầm dữ liệu giữa hai bảng khi chúng có cột cùng tên.
• Dữ liệu "zombie": có những dòng không thể xóa dù đã DELETE, hoặc vẫn hiện diện qua hàm tổng hợp sau khi bị xóa. Bảng bị DROP có thể "hồi sinh" dữ liệu cũ — thậm chí biến số thực 18.83 thành số nguyên 19 — khi tạo lại bảng mới cùng tên.

Ngoài ra, Jepsen còn ghi nhận các trường hợp giá trị NaN bị đổi thành 0.0 một cách ngẫu nhiên, cột bị gán giá trị kiểu không tương thích, vô cực không đọc được, và thứ tự cột trong INSERT bị bỏ qua gây hỏng dữ liệu.

Ý nghĩa với cộng đồng công nghệ

ParticleDB là ví dụ điển hình cho áp lực tạo ra sản phẩm cơ sở dữ liệu thế hệ mới, tích hợp "tất cả trong một" và tận dụng sức hút của Rust cùng các tuyên bố hiệu năng ấn tượng. Nhưng báo cáo của Jepsen — đơn vị đã kiểm thử nhiều database phổ biến như MongoDB, PostgreSQL, CockroachDB — cho thấy việc xây dựng một hệ quản trị cơ sở dữ liệu đúng đắn về ngữ nghĩa vẫn là bài toán cực kỳ khó.

Với các lập trình viên và doanh nghiệp Việt Nam đang cân nhắc các giải pháp database mới cho hệ thống AI hay microservices, đây là lời cảnh báo: đừng đánh đổi tính đúng đắn của dữ liệu lấy vài con số benchmark hiệu năng. Một database trả về kết quả SELECT sai một cách âm thầm còn nguy hiểm hơn nhiều lần một hệ thống chậm.

Một điểm tích cực là Orkes đã phản hồi và sửa nhiều lỗi trong các bản rc tiếp theo, dù Jepsen chưa có cơ hội kiểm chứng đầy đủ tất cả các trường hợp. Phiên bản 1.1.19 hứa hẹn khắc phục phần lớn các vấn đề nêu trên.