KiviDB 1.1.0 发布：兼容 Redis 的 Rust 数据库，吞吐量达 Redis 的 9 倍，并内置向量搜索

简要概述

KiviDB 1.1.0 是一个用 Rust 编写的 Redis/Valkey 直接替代品，它能利用所有 CPU 核心，在 32 核服务器上实现 2100 万次流水线 GET/s（约为 Redis 8 的 9 倍，Dragonfly 的 2.3 倍），并内置了类似 Redis Stack 的全文搜索和向量搜索功能。

什么是 KiviDB

KiviDB 是一个快速、多线程、内存键值存储系统，支持 Redis 协议（RESP2 和 RESP3）。它可以与任何现有的 Redis 客户端或 redis-cli 配合使用，无需更改代码，并增加了原生的 FT.* 命令，用于全文、标签、数值和 ANN 向量查询（FLAT 和 HNSW）。

  • 协议兼容性 – 支持所有标准 Redis 命令；请参阅 COMMANDS.md 获取支持的子集。
  • 搜索集成 – FT.CREATE、FT.SEARCH、FT.HYBRID 等命令的行为与 Redis Stack 一致。
  • 可选 Lua 和 TLS – 通过 Cargo 特性 lua 和 tls 启用。
  • 默认监听端口 – 6380（Redis 默认为 6379，因此两者可以并存）。
  • 许可证 – 仅限 AGPL-3.0；将 KiviDB 作为网络服务使用不会对您的应用程序施加 AGPL 义务。

性能亮点

所有基准测试均于 2026 年 10 月在两台 AWS Graviton3 裸机 c7gn.metal 实例（64 vCPU，服务器使用 32 核）上运行。每个引擎均在隔离环境下进行测试。

键值吞吐量与延迟

操作 KiviDB 1.1.0 Dragonfly 2.0.2 Redis 8.10 Redis Cluster (32 分片)
GET, 流水线 ×16 21.2 M ops/s 9.1 M 2.4 M 4.7 M
SET, 流水线 ×16 19.2 M ops/s 8.5 M 2.0 M 4.7 M
GET, 无流水线 3.07 M ops/s 3.35 M 1.32 M 1.46 M
SET, 无流水线 3.12 M ops/s 3.38 M 1.54 M 1.46 M
p99 延迟 (GET/SET, 流水线 ×16) 0.36 ms / 0.42 ms 0.88 ms / 1.07 ms 2.2 ms / 2.7 ms –
每个键的内存占用 177 B 134 B 178 B 183 B

KiviDB 的分片式、每核心设计使每个核心都能处理请求，这与 Redis 的单线程 I/O 模型不同。

向量搜索 (ANN) 性能

基准测试使用了 redis/vector-db-benchmark 套件，基于 118 万个向量、25 维的 Glove 数据集（HNSW, M=16, EF_CONSTRUCTION=256）。100 个客户端线程上传 64 个向量的批次，然后在不同的 ef 值下发出查询。

指标 KiviDB 1.1.0 Dragonfly 2.0.2 Redis 8.10 (查询引擎)
查询/秒 (ef = 64, recall@10) 59.3 k (0.943) 41.3 k (0.912) 31.8 k (0.912)
查询/秒 (ef = 128) 50.7 k (0.961) 40.3 k (0.937) 28.9 k (0.937)
查询/秒 (ef = 256) 31.5 k (0.989) 36.2 k (0.979) 21.1 k (0.979)
查询/秒 (ef = 512) 18.7 k (0.998) 29.8 k (0.995) 13.7 k (0.995)
摄入与索引构建时间 31 s 13 s 38 s
摄入后内存占用 1.66 GB 1.13 GB 1.07 GB

KiviDB 在较低 ef 值的高召回率查询中表现出色，而 Dragonfly 构建索引的速度更快且内存占用更少。

核心架构优势

  • 每核心分片设计 – 每个工作线程拥有一个不相交的键空间切片，消除了锁竞争并实现了真正的并行处理。
  • Rust 安全性与性能 – 使用 2024 版本编译，在可用时利用 io_uring（回退到 Tokio）。
  • 内置搜索 – 无需外部模块；FT.* 命令是核心二进制文件的一部分。
  • 持久化选项 – 快照 (dump.kdb) 和可选的追加写入文件 (AOF)，实现近乎实时的持久性。

快速入门指南

# 拉取官方 Docker 镜像 (默认版本)
docker run -d -p 6380:6380 kividb/kividb

# 验证服务器是否存活
redis-cli -p 6380 PING   # → PONG

创建向量索引 (Redis-Stack 语法)

redis-cli -p 6380 FT.CREATE idx ON HASH PREFIX 1 doc: \
  SCHEMA vec VECTOR HNSW 10 TYPE FLOAT32 DIM 128 \
  DISTANCE_METRIC COSINE M 16 EF_CONSTRUCTION 128

存储向量

在哈希字段中存储原始小端序 FLOAT32 字节（例如 HSET doc:1 vec <binary>）。该格式与 Redis Stack 和 redis-py/NumPy 二进制数据兼容。

KNN 查询 (Dialect 2)

redis-cli -p 6380 FT.SEARCH idx '*=>[KNN 10 @vec $q]' \
  PARAMS 2 q <binary-blob> DIALECT 2

完整的命令参考请见 COMMANDS.md。

持久化详情

  • 快照 (dump.kdb) 在索引后执行 SAVE/BGSAVE 时捕获键、索引模式和 HNSW 图。
  • AOF (--aof) 追加每次写入；重启时会重放 AOF 并成为事实来源，跳过快照加载。
  • 在启动时的索引重建期间，大多数命令会返回 LOADING，直到图准备就绪；PING 和 INFO 保持可用。

构建版本

版本 Cargo 特性 增加的功能
default 无 仅核心服务器
lua lua Lua 脚本 (EVAL, SCRIPT, …)
tls tls TLS 监听器和节点间 TLS
full lua,tls 同时包含 Lua 和 TLS

示例构建：

cargo build --release                     # 默认
cargo build --release --features lua      # 带 Lua
cargo build --release --features tls      # 带 TLS
cargo build --release --features lua,tls  # 全功能

Linux 构建在内核允许时会自动使用 io_uring；否则回退到 Tokio (--io-model auto)。

配置亮点

关键标志（括号内为默认值）：

  • --port 6380 – 监听端口。
  • --bind 0.0.0.0 – 地址；设置此项将禁用保护模式。
  • --protected-mode yes – 默认开启；除非配置了密码或绑定地址，否则仅允许回环客户端。
  • --threads 0 – 自动选择 核心数-2（最小为 2）。
  • --aof – 启用追加写入文件持久化。
  • --maxmemory 0 – 无限制内存；设置此项以强制执行上限。
  • --cluster-enabled no – 可选的集群模式，在 port+10000 上有单独的总线。
  • TLS 选项（--tls-port、--tls-cert-file 等）在构建时启用 tls 特性后可用。

所有标志均可通过 Redis 风格的配置文件（默认 /etc/kividb/kividb.conf）或命令行提供；命令行值会覆盖文件值。

Docker 使用

# 拉取最新镜像 (默认版本)
docker pull kividb/kividb:latest

docker run -p 6380:6380 kividb/kividb
  • 容器默认以 --protected-mode no 运行，因为 Docker 会将网络暴露在外部。请传递您自己的标志以重新启用保护模式并设置密码。
  • 对于 AOF 持久化：
docker run -p 6380:6380 \
  -v $(pwd)/data:/home/kividb \
  ghcr.io/kividbio/kividb \
  --aof --requirepass "change-me"
  • 要在 Docker 内允许 io_uring，请添加 --security-opt seccomp=unconfined（在生产环境使用前请了解安全影响）。

社区反馈 (Hacker News)

  • 基准测试可复现性 – 作者分享了 kivi-benchmark 仓库，其中包含用于独立验证的 Terraform 脚本和负载生成器代码。（评论者 @murtazayusuf）
  • 负载生成器限制 – 有评论者指出，实现 >500 万次操作/秒通常需要多个负载生成器主机；KiviDB 报告的 2100 万次操作/秒可能反映了服务器的容量，而非客户端瓶颈。（评论者 @falconBrisk47）
  • 功能比较请求 – 用户询问了 Valkey 基准测试以及与 Apache KVrocks 的比较；这些内容未出现在当前的发行说明中。
  • AI 参与 – 维护者确认在设计决策中大量使用了 AI 辅助，但核心工程是由人工驱动的。（评论者 @ghm2180）
  • 内存占用 – 关于摄入期间内存使用的问题尚未得到解答；已发布的表格显示了每个键的内存 (177 B) 和摄入后的向量内存 (118 万个向量占用 1.66 GB)。

许可与商业选项

KiviDB 采用 AGPL-3.0-only 许可发布。将未修改的 KiviDB 作为网络服务运行不会对您的专有应用程序施加 AGPL 义务。如果您修改了 KiviDB 本身并将其作为托管服务提供，则必须向用户提供修改后的源代码。

对于无法接受 AGPL 条款的组织，KIVIDB PRIVATE LIMITED 提供商业许可。咨询请发送至 support@kividb.io。

获取方式

快速参考命令

# 启动服务器 (默认版本)
./kividb

# 使用 TLS 启动 (需要 `tls` 特性)
./kividb --port 6380 --tls-port 6381 \
  --tls-cert-file cert.pem --tls-key-file key.pem

# 启用 AOF 持久化
./kividb --aof --requirepass "s3cr3t"

# 以集群模式运行
./kividb --cluster-enabled yes --cluster-node-timeout 15000

所有基准测试数据均为单一受控环境的快照；实际性能将根据硬件、工作负载和配置而有所不同。

Sources