KiviDB: Giải pháp thay thế Redis viết bằng Rust với tìm kiếm vector tích hợp sẵn

Một dự án mã nguồn mở mới có tên KiviDB đã xuất hiện như một giải pháp thay thế hiệu suất cao cho Redis và Valkey, được viết bằng ngôn ngữ Rust. Ra mắt vào tháng 10 năm 2026, dự án nhắm đến các kỹ sư hạ tầng đang tìm kiếm khả năng tương thích drop-in (thay thế trực tiếp) với các client Redis hiện có, đồng thời bổ sung hỗ trợ gốc cho tìm kiếm toàn văn và tìm kiếm vector. Dự án tuyên bố cải thiện đáng kể thông lượng so với các engine đã thiết lập nhờ tận dụng kiến trúc phân mảnh (sharded), đa lõi.

Điều gì đã xảy ra

KiviDB được thiết kế để giao tiếp theo giao thức Redis, hỗ trợ cả tiêu chuẩn RESP2 và RESP3. Khả năng tương thích này có nghĩa là các công cụ hiện có như redis-cli, cũng như các thư viện client phổ biến, có thể kết nối với KiviDB mà không cần chỉnh sửa. Khác với các instance Redis truyền thống thường dựa vào thực thi đơn luồng cho các lệnh cốt lõi, KiviDB phân phối khối lượng công việc trên tất cả các lõi CPU khả dụng bằng cách sử dụng thiết kế bộ nhớ trong phân mảnh. Nó cũng bao gồm các cơ chế lưu trữ dữ liệu thông qua snapshot và tệp chỉ ghi thêm (append-only file) tùy chọn.

Dự án tạo sự khác biệt bằng cách đóng gói các khả năng tìm kiếm trực tiếp vào engine cốt lõi. Người dùng có thể thực thi các lệnh kiểu Redis Stack FT.* cho tìm kiếm toàn văn, thẻ (tag), số và vector mà không cần cài đặt các module riêng biệt. Trong các bài kiểm tra benchmark được thực hiện trên các instance bare metal AWS Graviton3, KiviDB đã chứng minh những cải tiến hiệu suất đáng kể. Trên cấu hình 32 lõi, nó phục vụ 21 triệu thao tác GET pipelined mỗi giây, điều mà các nhà phát triển cho biết nhanh hơn khoảng chín lần so với Redis 8 và nhanh hơn 2,3 lần so với Dragonfly.

Các chỉ số độ trễ cũng ủng hộ engine mới, với độ trễ p99 được báo cáo thấp hơn một nửa so với Dragonfly trong các kịch bản pipelined. Tuy nhiên, trong các bài kiểm tra không dùng pipelining, Dragonfly duy trì lợi thế nhẹ về số lượng thao tác thô mỗi giây. Những kết quả này nhấn mạnh cách các mẫu khối lượng công việc, chẳng hạn như pipelining, ảnh hưởng đáng kể đến hiệu suất tương đối của các kho lưu trữ bộ nhớ trong này. Các bài kiểm tra benchmark được thực hiện trong môi trường được kiểm soát, và các tác giả khuyên nên thử nghiệm trên phần cứng cụ thể trước khi áp dụng vào sản xuất.

Cách hoạt động

KiviDB đạt được khả năng đồng thời bằng cách chạy các lệnh trên mọi lõi thông qua kiến trúc phân mảnh. Cách tiếp cận này trái ngược với mô hình đơn luồng của Redis tiêu chuẩn hoặc mô hình shared-nothing của Dragonfly. Bằng cách phân tán các khóa giữa các shard, hệ thống cho phép xử lý song song các yêu cầu, giảm thiểu tranh chấp trên bất kỳ luồng đơn lẻ nào. Engine được viết bằng Rust, sử dụng phiên bản 2024 của ngôn ngữ và dựa trên toolchain ổn định bắt đầu từ Rust 1.89.

Đối với tìm kiếm vector, KiviDB triển khai các thuật toán láng giềng gần đúng (approximate nearest neighbor), cụ thể là hỗ trợ chỉ mục FLAT và HNSW. Các vector được lưu trữ dưới dạng byte FLOAT32 little-endian thô trong các trường hash, tuân thủ cùng quy ước được sử dụng bởi Redis Stack. Khi một truy vấn tìm kiếm được thực thi, engine sử dụng các chỉ mục này để tìm các vector tương tự một cách hiệu quả. Hệ thống lưu trữ không chỉ dữ liệu khóa-giá trị mà còn cả schema chỉ mục và đồ thị HNSW, đảm bảo chất lượng tìm kiếm vẫn nhất quán sau khi khởi động lại mà không cần xây dựng lại hoàn toàn.

Phần mềm cung cấp sự linh hoạt thông qua các tính năng Cargo, cho phép người dùng xây dựng các biến thể có hoặc không có hỗ trợ script Lua và TLS. Theo mặc định, nó chạy mà không có các tính năng này để giảm thiểu phụ thuộc và bề mặt tấn công. Trên các hệ thống Linux, nó cố gắng sử dụng io_uring cho I/O bất đồng bộ nếu kernel cho phép, nếu không sẽ chuyển sang Tokio. Việc xử lý I/O ở mức thấp này góp phần vào khả năng quản lý hiệu quả số lượng kết nối lớn và thông lượng cao.

Chi tiết chính

• Tương thích giao thức: Hỗ trợ RESP2 và RESP3, cho phép các client và công cụ Redis hiện có kết nối mà không cần thay đổi.
• Tuyên bố về hiệu suất: Benchmark cho thấy 21 triệu GET pipelined mỗi giây trên 32 lõi, vượt trội hơn Redis 8 và Dragonfly trong các kịch bản cụ thể.
• Tìm kiếm tích hợp: Bao gồm hỗ trợ gốc cho tìm kiếm toàn văn, thẻ, số và vector sử dụng các lệnh FT.*, loại bỏ nhu cầu về các module bên ngoài.
• Kiến trúc đa luồng: Tận dụng tất cả các lõi CPU thông qua thiết kế bộ nhớ trong phân mảnh, khác với bản chất đơn luồng của Redis tiêu chuẩn.
• Tùy chọn lưu trữ: Hỗ trợ snapshot (dump.kdb) và tệp chỉ ghi thêm (AOF) tùy chọn để đảm bảo độ bền dữ liệu.
• Giấy phép: Phát hành theo Giấy phép Công cộng GNU Affero phiên bản 3 (AGPL-3.0-only), điều này có thể ảnh hưởng đến việc sử dụng trong các bản phân phối phần mềm độc quyền.

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

Đối với các kỹ sư phần mềm xây dựng ứng dụng dựa trên AI, việc tích hợp tìm kiếm vector trực tiếp vào lớp cache giúp đơn giản hóa hạ tầng. Theo cách truyền thống, các nhóm phải quản lý các dịch vụ riêng biệt cho caching và tìm kiếm tương đồng vector, dẫn đến tăng độ phức tạp vận hành và các vấn đề tiềm ẩn về tính nhất quán. Cách tiếp cận của KiviDB cho phép các nhà phát triển sử dụng một giao diện duy nhất cho cả tra cứu khóa-giá trị nhanh và tìm kiếm ngữ nghĩa, có khả năng giảm số lượng thành phần cần quản lý trong stack của họ.

Những cải tiến hiệu suất được báo cáo trong môi trường đa lõi giải quyết một nút thắt cổ chai phổ biến trong các hệ thống thông lượng cao. Khi các ứng dụng mở rộng quy mô, giới hạn đơn luồng của Redis truyền thống có thể trở thành ràng buộc, buộc các nhóm phải phân mảnh thủ công hoặc áp dụng các giải pháp clustering phức tạp hơn. Việc phân mảnh tự động trên các lõi của KiviDB mang đến một con đường hướng tới mức độ sử dụng cao hơn của các máy chủ đa lõi hiện đại mà không yêu cầu thay đổi ở cấp độ ứng dụng để xử lý logic phân mảnh.

Tuy nhiên, lựa chọn giấy phép là một cân nhắc quan trọng đối với các trưởng nhóm kỹ thuật. Giấy phép AGPL-3.0 yêu cầu rằng nếu bạn chỉnh sửa phần mềm và cung cấp nó qua mạng, bạn phải làm cho mã nguồn có sẵn. Mặc dù việc sử dụng KiviDB như một dịch vụ không nhất thiết buộc mã ứng dụng của bạn phải là mã nguồn mở, nhưng việc xem xét pháp lý là rất cần thiết cho các tổ chức có yêu cầu độc quyền nghiêm ngặt. Điều này trái ngược với các giải pháp thay thế như Valkey, sử dụng giấy phép BSD-3-Clause, cung cấp các điều khoản dễ dãi hơn cho mục đích thương mại.

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

• Thử nghiệm KiviDB cục bộ bằng Docker bằng cách chạy docker run -d -p 6380:6380 kividb/kividb và kết nối với redis-cli -p 6380.
• Benchmark khối lượng công việc cụ thể của bạn với KiviDB, Redis và Dragonfly để xác định xem kiến trúc đa luồng có mang lại lợi ích hữu hình cho trường hợp sử dụng của bạn hay không.
• Xem xét các hàm ý của giấy phép AGPL-3.0 với đội ngũ pháp lý của bạn nếu bạn dự định sử dụng KiviDB trong một sản phẩm thương mại hoặc dịch vụ phân phối.
• Thử nghiệm với các khả năng tìm kiếm vector tích hợp bằng cách tạo chỉ mục với FT.CREATE và truy vấn chúng với FT.SEARCH để đánh giá chất lượng tìm kiếm và độ trễ.
• Cấu hình lưu trữ bằng cách bật cờ tệp chỉ ghi thêm (--aof) trong Docker hoặc tham số dòng lệnh để đảm bảo độ bền dữ liệu qua các lần khởi động lại.
• Giám sát mức sử dụng bộ nhớ, vì bộ nhớ trên mỗi khóa của KiviDB được báo cáo là 177 byte trong các bài kiểm tra benchmark, hơi cao hơn so với 134 byte của Dragonfly nhưng tương đương với Redis.