KiviDB: Cơ sở dữ liệu trong bộ nhớ viết bằng Rust, nhanh gấp 9 lần Redis

Trong thế giới cơ sở dữ liệu trong bộ nhớ, Redis từ lâu đã là cái tên quen thuộc nhưng không phải lúc nào cũng là lựa chọn nhanh nhất. Một dự án mới mang tên KiviDB, viết hoàn toàn bằng Rust, đang thu hút sự chú ý khi công bố những con số hiệu năng đáng kinh ngạc trên diễn đàn Hacker News.

KiviDB được phát triển từ tháng 2/2026 bởi một lập trình viên từng gặp nhiều vấn đề với Dragonfly — các vấn đề như độ trễ do garbage collector, bộ nhớ phình to sau khi chụp snapshot và tình trạng OOM trên các pod đang chạy. Mục tiêu của dự án là kết hợp những điểm mạnh nhất của Rust với các ý tưởng hay từ những giải pháp thay thế như Garnet và Dragonfly.

Tương thích Redis nhưng nhanh hơn nhiều

Điểm hấp dẫn nhất của KiviDB là khả năng tương thích giao thức Redis (cả RESP2 và RESP3). Điều này có nghĩa là các thư viện client Redis hiện có, công cụ redis-cli hay bất kỳ ứng dụng nào đang dùng Redis đều có thể chuyển sang KiviDB mà gần như không cần sửa code. Dự án hỗ trợ khoảng 98-99% lệnh của Redis 8.10.

Về kiến trúc, KiviDB chia không gian khóa (keyspace) thành nhiều phân mảnh (shard) chạy trên nhiều luồng, tận dụng toàn bộ số nhân CPU. Trên Linux, server sử dụng io_uring thông qua crate tokio_uring để đạt hiệu năng tối đa, đồng thời có cơ chế dự phòng Tokio cho các hệ điều hành khác.

Biểu đồ hiệu năng của KiviDB

Những con số ấn tượng trên phần cứng AWS

Kết quả benchmark được thực hiện trên hai máy chủ c7gn.metal (vi xử lý Graviton3, 64 vCPU) đặt trong cùng một placement group tại us-east1, với KiviDB giới hạn 32 nhân. Kịch bản thử nghiệm gồm 10 triệu khóa, mỗi giá trị 100 byte, dùng công cụ memtier_benchmark.

Kết quả khi chạy pipeline 16 lệnh GET:

• KiviDB: 21,2 triệu ops/giây
• Dragonfly 2.0: 9,1 triệu ops/giây
• Redis 8.10: 2,4 triệu ops/giây
• Redis Cluster (32 shard): 4,7 triệu ops/giây

Như vậy, KiviDB nhanh gấp khoảng 9 lần Redis 8 và 2,3 lần Dragonfly trong kịch bản pipeline. Đáng chú ý hơn, độ trễ p99 khi pipeline chỉ ở mức 0,36 ms cho GET và 0,42 ms cho SET — chưa bằng một nửa so với Dragonfly (0,88 ms / 1,07 ms).

Độ trễ p99 khi chạy pipeline

Tuy nhiên, khi không dùng pipeline, khoảng cách thu hẹp đáng kể: Dragonfly đạt 3,35 triệu ops/giây, nhỉnh hơn KiviDB ở mức 3,07 triệu ops/giây. Lượng bộ nhớ tiêu tốn mỗi khóa của KiviDB là 177 byte, cao hơn Dragonfly (134 byte) nhưng gần tương đương Redis (178 byte).

Tìm kiếm vector — mảnh ghép cho ứng dụng AI

Không chỉ là bản thay thế Redis thuần túy, KiviDB còn tích hợp sẵn tìm kiếm toàn văn (BM25) và tìm kiếm vector với các chỉ mục FLAT và HNSW, thông qua các lệnh FT.* tương thích kiểu Redis Stack. Đây là điểm cộng lớn cho các ứng dụng AI cần lưu trữ và truy vấn embedding, vốn thường phải dùng thêm một cơ sở dữ liệu vector riêng.

Trên bộ dữ liệu glove-25-angular (1,18 triệu vector, 25 chiều), KiviDB đạt tốc độ truy vấn vượt trội ở các mức ef thấp:

• ef 64: 59,3 nghìn truy vấn/giây (recall@10 đạt 0,943) — so với Dragonfly 41,3 nghìn và Redis 31,8 nghìn
• ef 512: 18,7 nghìn truy vấn/giây — thấp hơn Dragonfly (29,8 nghìn) nhưng vẫn hơn Redis (13,7 nghìn)

Tốc độ truy vấn vector và độ chính xác

Điểm yếu hiện tại là tốc độ nạp dữ liệu vector: KiviDB mất 31 giây để nạp và xây chỉ mục, chậm hơn đáng kể so với Dragonfly (13 giây), dù vẫn nhanh hơn Redis (38 giây).

Dễ dùng, mã nguồn mở và hướng tới cộng đồng

Tác giả đã mở mã nguồn phần lõi dưới giấy phép AGPLv3 trên GitHub. Theo giấy phép này, ứng dụng của bạn kết nối tới KiviDB qua mạng không bị coi là sản phẩm phái sinh, nên không phải công khai mã nguồn. Chỉ khi bạn chỉnh sửa chính KiviDB rồi cung cấp qua mạng cho người khác thì mới phải chia sẻ mã đã sửa.

Cách thử nghiệm nhanh nhất là chạy Docker:

docker run -d -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING   # trả về PONG

Server lắng nghe ở cổng 6380 thay vì 6379 để có thể chạy song song với Redis. Ngoài ra KiviDB còn có các bản build tùy chọn hỗ trợ Lua scripting và TLS, cùng các gói cài đặt .deb, .rpm và binary cho Linux/macOS.

Về lưu trữ, KiviDB hỗ trợ snapshot và append-only file (AOF). Một chi tiết kỹ thuật đáng chú ý: khi lưu snapshot cùng chỉ mục vector, đồ thị HNSW được ghi xuống đĩa, nên chất lượng tìm kiếm sau khi khởi động lại không bị giảm và không phải xây dựng lại chỉ mục.

Góc nhìn cho cộng đồng công nghệ Việt Nam

Với các đội ngũ đang vận hành Redis trên hạ tầng cloud, KiviDB là phương án đáng cân nhắc nhờ chi phí hạ tầng thấp hơn khi cùng tải — chỉ cần một nửa số máy nếu hiệu suất gấp đôi. Đối với các dự án AI cần vector database cục bộ (như ứng dụng RAG, tìm kiếm ngữ nghĩa), việc có sẵn tìm kiếm vector trong cùng một công cụ quen thuộc giúp giảm độ phức tạp triển khai.

Dù vậy, cần lưu ý rằng KiviDB vẫn là dự án non trẻ, số người đóng góp còn ít và một số lệnh Redis chưa hoạt động hoàn hảo. Các con số benchmark do chính tác giả công bố trên phần cứng cụ thể, nên tổ chức có ý định chuyển đổi nên tự đo lại trên môi trường thực tế của mình trước khi quyết định.

"Tôi mong muốn xây dựng một cộng đồng quanh dự án này, cung cấp những công cụ Rust tốt hơn. Tôi sẵn sàng đón nhận phê bình mang tính xây dựng và trân trọng những ý kiến có căn cứ." — tác giả KiviDB chia sẻ.