Show HN：KiviDB，更快的 Redis 兼容内存数据库和向量缓存

KiviDB 是 Redis® 和 Valkey 的快速、多线程替代品，用 Rust 编写。它使用 Redis 协议（RESP2 和 RESP3），因此现有的 Redis 客户端、redis-cli 和库保持不变，并且内置全文和矢量搜索。它在分片内存键值设计上运行每个核心，并持久保存快照和可选的仅附加文件。在同样的 32 个核心上，KiviDB 每秒可处理 2100 万个管道 GET：大约是 Redis 8 的 9 倍和 Dragonfly 的 2.3 倍，而延迟只有 Dragonfly 的一半以下（基准测试）。 docker run -d -p 6380:6380 kividb/kividb redis-cli -p 6380 PING # PONG KiviDB 监听 6380 ，而不是 Redis 的 6379 ，因此两者可以并行运行；将您的客户端指向该端口，或传递 --port 6379 。协议：Redis 兼容的命令界面（有关支持的命令，请参阅 COMMANDS.md） 搜索和向量：用于全文、标签、数字和向量（FLAT / HNSW）搜索的 Redis Stack 式 FT.* 命令 Lua 脚本：可选的 Cargo 功能。 EVAL 、 SCRIPT 、 FUNCTION 、 FCALL 和相关命令可在带有 --features lua 的构建中使用（请参阅脚本命令 (Lua) ） TLS ：可选 Cargo 功能（ --features tls ）默认侦听地址： 0.0.0.0:6380 ，许可证上有保护模式： GNU Affero 通用公共许可证 v3（仅限 AGPL-3.0），开源；使用 KiviDB 不会将您的应用程序置于 AGPL 之下；请参阅许可证存储库：github.com/kividbio/kividb · 网站：kividb.io KiviDB Redis 8 Valkey 8 Dragonfly KeyDB 许可证 AGPL-3.0 RSALv2、SSPLv1 或 AGPL-3.0 BSD-3-Clause BSL 1.1 BSD-3-Clause 语言 Rust C C C++ C++ 命令在每个核心（分片）上运行 一个线程（I/O 线程）一线程（I/O 线程） 每个核心（无共享） 多个线程 内置全文和矢量搜索 ( FT.* ) 内置 内置（查询引擎） 内置单独模块 否 Lua 脚本 lua 构建 是 是 是 截至 2026 年 10 月。有什么过时或错误吗？请打开一个问题。吞吐量、延迟、矢量搜索和矢量摄取。单击查看全分辨率视频。以下所有数据均来自 2026 年 10 月 AWS Graviton3 裸机上的一次会议：服务器位于 c7gn.metal（64 个 vCPU）上，仅限 32 个核心，负载生成器位于同一置放组中的第二个 c7gn.metal 上。每个引擎在服务器上单独运行，一个接一个。 memtier_benchmark 到 kivi-benchmark 的 run-matrix.sh ：1000 万个键，100 字节值，30 秒一个场景，两轮的平均值； 300 个管道连接，1,200 个无管道连接。 ops/s KiviDB 1.1.0 Dragonfly 2.0.2 Redis 8.10 Redis Cluster（32 个分片） GET，管道 16 21.2M 9.1M 2.4M 4.7M SET，管道 16 19.2M 8.5M 2.0M 4.7M GET，无管道 3.07M 3.35M 1.32M 1.46M SET，无流水线 3.12M 3.38M 1.54M 1.46M p99 延迟，GET / SET，流水线 16 0.36 / 0.42 ms 0.88 / 1.07 ms 2.2 / 2.7 ms 每个键的内存 177 B 134 B 178 B 183 B glove-25-angular 上的 redis/vector-db-benchmark（1.18M 向量，25 个维度）：M=16 且 EF_CONSTRUCTION=256 的 HNSW，100 个客户端以 64 个为一组上传，然后在 ef 64、128、256 和 512 处进行查询。 KiviDB 1.1.0 Dragonfly 2.0.2 Redis 8.10（查询引擎) ef 时的查询/秒 (recall@10) 59.3k (0.943) 41.3k (0.912) 31.8k (0.912) ef 时的查询/秒 128 50.7k (0.961) 40.3k (0.937) 28.9k (0.937) ef 时的查询/秒256 31.5k (0.989) 36.2k (0.979) 21.1k (0.979) ef 时的查询/秒 512 18.7k ( 0.998 ) 29.8k (0.995) 13.7k (0.995) 摄取和索引构建 31 s 13 s 38 s 之后的内存摄取 1.66 GB 1.13 GB 1.07 GB 结果取决于环境。将发布的数据视为一次受控捕获，而不是保证，并根据您自己的硬件和工作负载进行测量。矢量搜索（Redis Stack 式 FT.*）KiviDB 实现了 Redis Stack 兼容的搜索和矢量命令，因此现有的客户端和教程基本上无需更改。将它们用于哈希字段上的全文 (BM25) 、标签/数字和向量 ANN （FLAT 或 HNSW ）。在带有前缀的键上创建索引，声明至少一个 VECTOR 字段（HNSW 或 FLAT）和可选的 TEXT / TAG / NUMERIC 字段： 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 小端字节（DIM × 4 字节），与 Redis 堆栈和 redis-py / numpy blob 的约定相同。使用客户端的二进制安全 HSET（tests/e2e/ 下的集成测试有示例）。使用 KNN（方言 2）查询，将查询向量作为命名二进制参数传递： redis-cli -p 6380 FT.SEARCH idx ' *=>[KNN 10 @vec $q] ' PARAMS 2 q < blob > DIALECT 2 完整的命令界面、过滤器、混合搜索和边缘情况位于 COMMANDS.md 中（搜索 FT.CREATE 、 FT.SEARCH 、 FT.HYBRID 等）。本机快照 ( dump.kdb ) 存储键、索引模式，并且当您使用填充的索引进行 SAVE/BGSAVE 时，还会存储每个向量字段的 HNSW 图，因此重新启动后的搜索质量与关闭之前的图相匹配。当搜索索引在启动时重建时，大多数命令都会返回 LOADING 直到重建完成；