KiviDB是一个快速的、多线程的Redis®和Valkey的替代品，使用Rust编写。它支持Redis协议（RESP2和RESP3），因此现有的Redis客户端、redis-cli和库均可不变地工作，并且内置有全文搜索和向量搜索。它在分片的内存键值设计上运行每个核心，并持久化到快照和可选的仅附加文件。在同样的32个核心上，KiviDB每秒处理2100万个管道GET：约为Redis 8的9倍，Dragonfly的2.3倍，且延迟低于Dragonfly的p99延迟（基准测试）。docker run -d -p 6380:6380 kividb/kividb redis-cli -p 6380 PING # PONG KiviDB监听在6380端口，而不是Redis的6379，所以两个可以并行运行；将客户端指向该端口，或传递--port 6379。协议：兼容Redis的命令界面（请参阅COMMANDS.md以了解支持的命令）搜索和向量：与Redis Stack风格的FT.*命令相似，支持全文、标签、数字和向量（FLAT / HNSW）搜索Lua脚本：可选Cargo功能。EVAL，SCRIPT，FUNCTION，FCALL和相关命令在使用--features lua进行构建时可用（请参阅脚本命令（Lua））。TLS：可选Cargo功能（--features tls）默认监听地址：0.0.0.0:6380，开启保护模式许可证：GNU Affero General Public License v3 (AGPL-3.0-only)，开源；使用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个连接管道，1200个不使用管道。ops/s KiviDB 1.1.0 Dragonfly 2.0.2 Redis 8.10 Redis集群（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毫秒 0.88 / 1.07毫秒 2.2 / 2.7毫秒 每个键的内存 177 B 134 B 178 B 183 B 向量搜索 redis/vector-db-benchmark 在 glove-25-angular（1.18M 向量，25维度）：HNSW，M=16和EF_CONSTRUCTION=256，100个客户端以64的批次上传，然后在ef 64，128，256和512下进行查询。 KiviDB 1.1.0 Dragonfly 2.0.2 Redis 8.10（查询引擎） ef 64的查询/秒（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秒 13秒 38秒 摄取后的内存 1.66 GB 1.13 GB 1.07 GB 方法论和脚本：kivi-benchmark 最近的自动运行：benchmarks/LATEST.md 结果取决于环境。将发布的数字视为一次受控捕获，而不是保证，并在您自己的硬件和工作负载上进行测量。向量搜索（与Redis Stack风格的FT.*） KiviDB实现了与Redis Stack兼容的搜索和向量命令，因此现有客户和教程大多可以不变地工作。可以用于全文搜索（BM25）、标签/数字和向量ANN（FLAT或HNSW）在哈希字段上。快速开始 在有前缀的键上创建一个索引，声明至少一个向量字段（HNSW或FLAT）和可选的文本/标签/数字字段： 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 Stack和redis-py / numpy blob相同的约定。使用客户端的二进制安全HSET（测试/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图。