KiviDB：更快、相容 Redis 的記憶體資料庫與向量快取

大家好，我從 2026 年 2 月開始開發 KiviDB 這個專案。它最初是為了讓我理解 Rust 而啟動的，目標是打造一個沒有垃圾回收（GC）暫停、快照後記憶體不會暴增，也不會在執行中的 Pod 上發生記憶體不足（OOM）的產品，這正是我在使用 Dragonfly 時遇到的問題。

我希望它能結合 Rust 的優點，同時也借鑒 Garnet 和 Dragonfly 等其他替代方案的精華。我大量使用了 AI，但最終的設計決策仍由我根據 Claude 從我過去工作中的故障排除紀錄所挑選的測試結果來制定。

KiviDB 支援 RESP2 和 RESP3 兩種協定。我在 AWS 帳戶中擁有創始人額度，這幫助我建置基礎設施並執行基準測試實例。它的鍵空間（keyspace）在多個執行緒之間分片，本質上是多執行緒的，並且由於 io_uring 的應用，在 Linux 上表現最佳，我為此使用了 tokio_uring crate。對於其他作業系統，它也有 tokio 備援機制。

我直到最近才將其開源，因為我覺得它尚未準備好；學習它的最佳方式是為其在 AWS、GCP 和 Azure 這三大廣泛使用的雲端供應商上建立一個雲端託管服務。由於我主要從事雲端工作，我對部署的最佳方式、如何執行故障轉移、管理服務水準協議（SLA）等方面有一些見解。這也是我借助 Claude 來加速開發的部分。

雖然網站看起來有點像 AI 生成的粗糙內容，但在資源有限的情況下，它目前堪用。您可以在 https://kividb.io 查看，我將核心引擎以 AGPLv3 授權開源，因為我不希望它只是「原始碼可用」（source available），那樣其他工具也做得到。

它支援大約 98-99% 的 Redis 8.10 指令，少數有問題的指令可以在 https://github.com/kividbio/kividb/issues 找到，歡迎貢獻者加入。

接下來是數據，為了最終的基準測試，我使用了位於 us-east1 相同放置群組中的兩台 c7gn.metal 伺服器，並使用 memtier-benchmark 工具。設定為：1000 萬個鍵，每個鍵 100 位元組，使用 32 個核心，並進行管線化（pipelined）和非管線化（un-pipelined）的執行。

在管線化 16 個 GET 操作中：KiviDB 達到每秒 2120 萬次操作，而 Dragonfly 2.0 為 910 萬次，Redis 8.10 為 240 萬次，Redis Cluster（32 個分片）為 470 萬次。在非管線化情況下，Dragonfly 表現略優，每秒 335 萬次操作，而 KiviDB 為 307 萬次。

每個鍵的記憶體使用量也略遜於 Dragonfly，但與 Redis 幾乎相同：KiviDB 為 177 位元組，Dragonfly 為 134 位元組，Redis 為 178 位元組。

在向量資料攝取時間方面，KiviDB 較慢，但在查詢時，於較低的 ef 值下比大多數替代方案更快，但在較高的 ef 值下則慢於 Dragonfly。大部分技術細節都可以在這裡查看：https://kividb.io/benchmarks。最簡單的試用方式是執行：docker run -d -p 6380:6380 kividb/kividb。

我期待圍繞 KiviDB 建立一個社群，提供更好的基於 Rust 的工具，我樂於接受建設性的批評並重視有見地的意見。謝謝。