Show HN: KiviDB、より高速なRedis互換メモリデータベースおよびベクトルキャッシュ

皆さん、こんにちは。

2026年2月からこのプロジェクトKiviDBに取り組んできました。当初はRustを理解するためのプロジェクトとして始まりましたが、GCの停止、スナップショット後のメモリの急増、OOM（Out Of Memory）といった問題を抱える製品を避けたいという思いがありました。これはDragonflyで実際に直面した問題でした。Rustの利点と、GarnetやDragonflyのような他の代替ツールの優れた部分を組み合わせたものを実現したかったのです。AIを多用しましたが、設計上の決定は、私の仕事の一部であるトラブルシューティングセッションの履歴からClaudeが選んだテストに基づいて私が行いました。KiviDBはRESP2とRESP3の両方のプロトコルをサポートしています。AWSアカウントの創設者向けクレジットがあったため、インフラやベンチマークを実行するためのインスタンスの運用に役立ちました。

キー空間はスレッド間でシャーディングされており、マルチスレッドネイチャーであり、io_uringのおかげでLinuxで最高のパフォーマンスを発揮します。このためにtokio_uringクレートを使用しました。他のOS向けにはtokioフォールバックも備えています。まだ準備ができていないと感じていたため、最近までオープンソース化していませんでした。それを学ぶ最善の方法は、広く使われている3つのクラウドプロバイダー（AWS、GCP、Azure）すべてでマネージドサービスを構築することでした。主にクラウドで作業していたため、デプロイメントの最適な方法、フェイルオーバーの管理、SLAの管理などについていくつかの洞察がありました。そして、Claudeの助けを借りてこれを迅速に進めました。ウェブサイトはAIによる雑な作りですが、今のところ機能しています。リソースが限られている中で、それが私の全てでした。コアエンジンはAGPLv3の下でオープンソース化しましたが、単なるソースコード公開では不十分だと考えました。なぜなら、それは他のツールでも利用可能だからです。Redis 8.10コマンドの約98-99%をサポートしており、いくつか問題がありますが、それらはhttps://github.com/kividbio/kividb/issuesで見つけることができます。コントリビューターを歓迎します。

さて、数値についてです。最終ベンチマークでは、us-east1の同じ配置グループにある2つのc7gn.metalサーバーを使用し、memtier-benchmarkツールを使用しました。設定は以下の通りです：10Mキー、各100B、32コアを使用し、パイプライン実行と非パイプライン実行の両方を行いました。

パイプライン16 GET: KiviDB 21.2M ops/sec vs Dragonfly 2.0 9.1M, Redis 8.10 2.4M, Redis Cluster 32 shards 4.7M

パイプラインを使用しない場合、Dragonflyは3.35M ops/secで、KiviDBの3.07M ops/secよりもわずかに優れていました。キーあたりのメモリ使用量も、Dragonflyよりわずかに悪く、Redisとほぼ同じでした。177B（KiviDB） vs 134B（Dragonfly） vs 178B（Redis）です。

ベクトル取り込み時間は遅かったですが、クエリ時には、低いef値ではほとんどの代替手段よりも高速でしたが、高いef値ではDragonflyよりも遅かったです。技術的な詳細はほとんどここに記載されているので、確認できます：https://kividb.io/benchmarks。

試す最も簡単な方法：docker run -d -p 6380:6380 kividb/kividb

このプロジェクトを中心にコミュニティを構築し、より良いRustベースのツールを提供していきたいと考えています。建設的な批判にはオープンであり、情報に基づいた意見を高く評価します。ありがとうございます。