KiviDB 1.1.0 リリース: Redis互換のRust製データベース、Redisの9倍のスループットとベクトル検索機能を内蔵
TL;DR
KiviDB 1.1.0は、Rustで記述されたRedis/Valkeyのドロップイン代替品です。すべてのCPUコアを活用し、32コアサーバー上で 2100万 pipelined GETs/s (Redis 8の約9倍、Dragonflyの2.3倍) を達成し、Redis Stackスタイルの全文検索およびベクトル検索機能を内蔵しています。
KiviDBとは
KiviDBは、Redisプロトコル (RESP2およびRESP3) に対応した、高速でマルチスレッド化されたインメモリキーバリューストアです。既存のRedisクライアントや redis-cli をコード変更なしで使用でき、全文検索、タグ検索、数値検索、およびANNベクトルクエリ (FLATおよびHNSW) 用のネイティブな FT.* コマンドを追加しています。
- プロトコル互換性 – すべての標準的なRedisコマンドが動作します。サポートされているサブセットについては
COMMANDS.mdを参照してください。 - 検索統合 –
FT.CREATE、FT.SEARCH、FT.HYBRIDなどはRedis Stackと同様に動作します。 - LuaおよびTLSのオプション – Cargoの機能フラグ
luaおよびtlsで有効化できます。 - デフォルトのリスニングポート – 6380 (Redisはデフォルトで6379のため、両方を並行して実行可能です)。
- ライセンス – AGPL-3.0-only。KiviDBをネットワークサービスとして使用しても、アプリケーションにAGPLが適用されることはありません。
パフォーマンスのハイライト
すべてのベンチマークは2026年10月に、2台のAWS Graviton3ベアメタル c7gn.metal インスタンス (64 vCPU、サーバー用に32コアを使用) で実行されました。各エンジンは個別にテストされています。
キーバリュースループットとレイテンシ
| 操作 | KiviDB 1.1.0 | Dragonfly 2.0.2 | Redis 8.10 | Redis Cluster (32シャード) |
|---|---|---|---|---|
| GET, pipelined ×16 | 21.2 M ops/s | 9.1 M | 2.4 M | 4.7 M |
| SET, pipelined ×16 | 19.2 M ops/s | 8.5 M | 2.0 M | 4.7 M |
| GET, no pipelining | 3.07 M ops/s | 3.35 M | 1.32 M | 1.46 M |
| SET, no pipelining | 3.12 M ops/s | 3.38 M | 1.54 M | 1.46 M |
| p99レイテンシ (GET/SET, pipelined ×16) | 0.36 ms / 0.42 ms | 0.88 ms / 1.07 ms | 2.2 ms / 2.7 ms | – |
| キーあたりのメモリ | 177 B | 134 B | 178 B | 183 B |
KiviDBのシャード化されたコアごとの設計により、RedisのシングルスレッドI/Oモデルとは異なり、すべてのコアがリクエストを処理できます。
ベクトル検索 (ANN) パフォーマンス
ベンチマークには、118万ベクトル、25次元のGloveデータセット (HNSW, M=16, EF_CONSTRUCTION=256) を使用した redis/vector-db-benchmark スイートを使用しました。100のクライアントスレッドが64ベクトルのバッチをアップロードし、さまざまな ef 値でクエリを発行しました。
| メトリクス | KiviDB 1.1.0 | Dragonfly 2.0.2 | Redis 8.10 (クエリエンジン) |
|---|---|---|---|
| Queries/s (ef = 64, recall@10) | 59.3 k (0.943) | 41.3 k (0.912) | 31.8 k (0.912) |
| Queries/s (ef = 128) | 50.7 k (0.961) | 40.3 k (0.937) | 28.9 k (0.937) |
| Queries/s (ef = 256) | 31.5 k (0.989) | 36.2 k (0.979) | 21.1 k (0.979) |
| Queries/s (ef = 512) | 18.7 k (0.998) | 29.8 k (0.995) | 13.7 k (0.995) |
| 取り込みとインデックス構築時間 | 31 s | 13 s | 38 s |
| 取り込み後のメモリ | 1.66 GB | 1.13 GB | 1.07 GB |
KiviDBは低い
ef値での高リコールクエリに優れており、Dragonflyはインデックス構築が速く、メモリ消費が少ないという特徴があります。
主要なアーキテクチャ上の利点
- コアごとのシャード設計 – 各ワーカー・スレッドが独立したキー空間スライスを所有し、ロック競合を排除して真の並列処理を実現します。
- Rustの安全性とパフォーマンス – 2024エディションでコンパイルされ、利用可能な場合は
io_uringを活用します (Tokioへのフォールバックあり)。 - 内蔵検索 – 外部モジュールは不要で、
FT.*コマンドはコアバイナリの一部です。 - 永続化オプション – スナップショット (
dump.kdb) および、ほぼリアルタイムの耐久性を実現するオプションのAppend-Only File (AOF)。
クイックスタートガイド
# 公式Dockerイメージをプル (デフォルトバリアント)
docker run -d -p 6380:6380 kividb/kividb
# サーバーが稼働しているか確認
redis-cli -p 6380 PING # → PONG
ベクトルインデックスの作成 (Redis-Stack構文)
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 バイトを保存します (例: HSET doc:1 vec <binary>)。形式はRedis Stackおよび redis-py/NumPyのBLOBと一致します。
KNNクエリ (Dialect 2)
redis-cli -p 6380 FT.SEARCH idx '*=>[KNN 10 @vec $q]' \
PARAMS 2 q <binary-blob> DIALECT 2
完全なコマンドリファレンスは COMMANDS.md にあります。
永続化の詳細
- スナップショット (
dump.kdb) は、インデックス作成後にSAVE/BGSAVEが実行されると、キー、インデックススキーマ、およびHNSWグラフをキャプチャします。 - AOF (
--aof) はすべての書き込みを追記します。再起動時にAOFがリプレイされ、スナップショットの読み込みをバイパスして信頼できるソースとなります。 - 起動時のインデックス再構築中、グラフの準備ができるまでほとんどのコマンドは
LOADINGを返しますが、PINGとINFOは機能し続けます。
ビルドバリアント
| バリアント | Cargo機能 | 追加内容 |
|---|---|---|
default |
なし | コアサーバーのみ |
lua |
lua |
Luaスクリプト (EVAL, SCRIPT, …) |
tls |
tls |
TLSリスナーおよびノード間TLS |
full |
lua,tls |
LuaとTLSの両方 |
ビルド例:
cargo build --release # デフォルト
cargo build --release --features lua # Lua付き
cargo build --release --features tls # TLS付き
cargo build --release --features lua,tls # フル
Linuxビルドはカーネルが許可する場合に自動的に io_uring を使用します。それ以外の場合はTokioにフォールバックします (--io-model auto)。
設定のハイライト
主要なフラグ (括弧内はデフォルト値):
--port 6380– リスニングポート。--bind 0.0.0.0– アドレス。これを設定すると保護モードが無効になります。--protected-mode yes– デフォルトで有効。パスワードやバインドアドレスが設定されていない限り、ループバッククライアントのみが許可されます。--threads 0–コア数-2を自動選択 (最小2)。--aof– AOF永続化を有効化。--maxmemory 0– メモリ無制限。上限を設定するには値を指定します。--cluster-enabled no–port+10000で別のバスを使用するオプションのクラスターモード。- TLSオプション (
--tls-port,--tls-cert-fileなど) はtls機能でビルドされた場合に利用可能です。
すべてのフラグはRedisスタイルの設定ファイル (/etc/kividb/kividb.conf がデフォルト) またはコマンドラインから指定できます。コマンドラインはファイルの値よりも優先されます。
Dockerの使用方法
# 最新イメージをプル (デフォルトバリアント)
docker pull kividb/kividb:latest
docker run -p 6380:6380 kividb/kividb
- コンテナはDockerがネットワークを外部に公開するため、デフォルトで
--protected-mode noで実行されます。保護モードを再有効化し、パスワードを設定するには独自のフラグを渡してください。 - AOF永続化の場合:
docker run -p 6380:6380 \
-v $(pwd)/data:/home/kividb \
ghcr.io/kividbio/kividb \
--aof --requirepass "change-me"
- Docker内で
io_uringを許可するには、--security-opt seccomp=unconfinedを追加してください (本番環境で使用する前にセキュリティへの影響を理解してください)。
コミュニティのフィードバック (Hacker News)
- ベンチマークの再現性 – 著者は、独立した検証のためにTerraformスクリプトと負荷生成コードを含む
kivi-benchmarkリポジトリを共有しました。(コメント: @murtazayusuf) - 負荷生成器の制限 – あるコメント投稿者は、500万 ops/sを超えるには複数の負荷生成ホストが必要になることが多いと指摘しました。KiviDBが報告した2100万 ops/sは、クライアントのボトルネックではなくサーバーの容量を反映している可能性が高いです。(コメント: @falconBrisk47)
- 機能比較のリクエスト – ユーザーはValkeyのベンチマークやApache KVrocksとの比較を求めましたが、これらは現在のリリースノートには含まれていません。
- AIの関与 – メンテナーは設計上の決定にAIを広範囲に活用したことを認めましたが、コアエンジニアリングは人間主導で行われました。(コメント: @ghm2180)
- メモリフットプリント – 取り込み中のメモリ使用量に関する質問は未回答のままです。公開された表には、キーあたりのメモリ (177 B) と取り込み後のベクトルメモリ (118万ベクトルで1.66 GB) が示されています。
ライセンスと商用オプション
KiviDBは AGPL-3.0-only でリリースされています。未修正のKiviDBをネットワークサービスとして実行しても、独自のアプリケーションにAGPLの義務が課されることはありません。KiviDB自体を修正してホスト型サービスとして提供する場合は、修正したソースをユーザーが利用できるようにする必要があります。
AGPL条項を受け入れられない組織向けに、KIVIDB PRIVATE LIMITEDが商用ライセンスを提供しています。お問い合わせは support@kividb.io までお願いします。
入手方法
- GitHubリポジトリ – https://github.com/kividbio/kividb
- Docker Hub / GHCR –
kividb/kividb:latest(他にv1.1.0,v1.1.0-lua,v1.1.0-tls,v1.1.0-fullもあり) - リリースバイナリ – Linux x86_64, Linux aarch64, macOS (Intel & Apple Silicon) のtarball。Debian/RPMパッケージも提供されています。
- ベンチマークスイート – パフォーマンス数値を再現するための https://github.com/kividbio/kivi-benchmark
クイックリファレンスコマンド
# サーバー起動 (デフォルトバリアント)
./kividb
# TLSで起動 (`tls` 機能が必要)
./kividb --port 6380 --tls-port 6381 \
--tls-cert-file cert.pem --tls-key-file key.pem
# AOF永続化を有効化
./kividb --aof --requirepass "s3cr3t"
# クラスターモードで実行
./kividb --cluster-enabled yes --cluster-node-timeout 15000
すべてのベンチマーク数値は単一の制御された環境のスナップショットであり、実際のパフォーマンスはハードウェア、ワークロード、設定によって異なります。