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

大家好，我从 2026 年 2 月开始开发 KiviDB 这个项目。最初是为了学习 Rust，同时打造一款没有 GC 暂停、快照后不会内存暴涨、运行中的 Pod 不会出现 OOM 的产品；而这些确实是我使用 Dragonfly 时遇到的问题。我希望做出一个结合 Rust 优点，同时吸收 Garnet 和 Dragonfly 等其他替代方案长处的产品。 我大量使用了 AI，但设计决策都是由我根据 Claude 从我工作中的故障排查记录里挑选出的测试结果亲自做出的。KiviDB 同时支持 RESP2 和 RESP3 协议。我的 AWS 账户中有一些创始人额度，这帮助我完成了基础设施搭建，也让我能够运行实例进行基准测试。 它的键空间跨线程分片，本质上是多线程的；由于使用了 io_uring，它在 Linux 上的性能最佳，我为此使用了 tokio_uring crate。在其他操作系统上，它也支持回退到 tokio。 直到最近我才将其开源，因为当时觉得它还没有准备好。学习它的最佳方式，是为它构建一个覆盖三大主流云服务商（AWS、GCP 和 Azure）的云托管服务。由于我过去主要从事云相关工作，对部署方式、故障转移、SLA 管理等方面的最佳实践有一些了解。这些工作中，我也借助 Claude 来加快进度。 网站看起来确实像是 AI 生成的粗制滥造作品，但目前还能用。考虑到我的资源有限，这已经是我能做到的全部了。你可以访问：https://kividb.io 。我以 AGPLv3 协议开源了核心引擎，不想只做到“源码可用”，因为其他工具也提供了这种模式。 它支持 Redis 8.10 大约 98%～99% 的命令，其中少数命令存在问题，详情可以在这里找到：https://github.com/kividbio/kividb/issues ，欢迎贡献代码。 下面说说性能数据。最终基准测试使用了两台 c7gn.metal 服务器，位于 us-east1 的同一放置组中，测试工具是 memtier-benchmark。配置为：1000 万个键，每个键 100B，使用 32 个核心，分别进行流水线和非流水线测试。 在流水线 16 GET 测试中：KiviDB 为 21.2M ops/sec，Dragonfly 2.0 为 9.1M，Redis 8.10 为 2.4M，拥有 32 个分片的 Redis Cluster 为 4.7M。 在非流水线测试中，Dragonfly 的表现略好，为 3.35M ops/sec；KiviDB 为 3.07M ops/sec。每个键的内存占用也略差于 Dragonfly，与 Redis 基本相同：KiviDB 为 177B，Dragonfly 为 134B，Redis 为 178B。 在向量写入方面，KiviDB 的速度较慢；但在查询时，当 ef 较低时，它比大多数替代方案更快，不过在 ef 较高时则慢于 Dragonfly。 大部分技术细节都在这里，你可以查看：https://kividb.io/benchmarks 。最简单的尝试方式是： docker run -d -p 6380:6380 kividb/kividb 我期待围绕这个项目建立一个社区，提供更好的基于 Rust 的工具。我欢迎建设性的批评，也重视有依据的意见。谢谢。 评论链接：https://news.ycombinator.com/item?id=50152541 点数：10 评论数：1