KiviDB: ベクトル検索を内蔵したRustベースのRedis代替

2026年10月にリリースされたオープンソースプロジェクト「KiviDB」が、RedisやValkeyに代わる高性能な選択肢として注目を集めています。Rustで書かれたこのプロジェクトは、既存のRedisクライアントとのドロップイン互換性を保ちながら、フルテキスト検索とベクトル検索へのネイティブサポートを追加することで、インフラエンジニアの利用を想定しています。シャーディングされたマルチコアアーキテクチャを活用することにより、確立されたエンジンと比較して大幅なスループット向上を実現すると主張しています。

何が起きたか

KiviDBはRedisプロトコルに対応しており、RESP2およびRESP3規格をサポートしています。この互換性により、redis-cliなどの既存ツールや人気のあるクライアントライブラリは、変更を加えることなくKiviDBに接続できます。コアコマンドの実行において多くの場合シングルスレッドに依存する従来のRedisインスタンスとは異なり、KiviDBはシャーディングされたインメモリ設計を用いて、利用可能なすべてのCPUコアにワークロードを分散させます。また、スナップショットによる永続化メカニズムと、オプションの追記専用ファイル（AOF）も含まれています。

本プロジェクトの特徴は、検索機能をコアエンジンに直接組み込んでいる点にあります。ユーザーは、外部モジュールをインストールすることなく、Redis StackスタイルのFT.*コマンドを使用して、フルテキスト、タグ、数値、およびベクトル検索を実行できます。AWS Graviton3ベアメタルインスタンスで実施されたベンチマークでは、KiviDBは顕著な性能向上を示しました。32コア構成において、毎秒2,100万回のパイプラインGET操作を処理し、開発者によればこれはRedis 8の約9倍、Dragonflyの約2.3倍の速度です。

遅延指標においても新エンジンが優位でした。パイプラインシナリオでは、p99遅延がDragonflyの半分未満であると報告されています。しかし、非パイプラインテストでは、Dragonflyが生オペレーション数（OPS）においてわずかに有利でした。これらの結果は、パイプライン化などのワークロードパターンが、これらのインメモリストアの相対的な性能に大きく影響することを浮き彫りにしています。ベンチマークは制御された環境で実施されており、著者は本番導入前に特定のハードウェアでのテストを推奨しています。

仕組み

KiviDBは、シャーディングアーキテクチャを通じてすべてのコアでコマンドを実行することで並行性を実現しています。このアプローチは、標準的なRedisのシングルスレッドモデルや、Dragonflyの共有なし（shared-nothing）モデルとは対照的です。キーをシャード間で分散させることにより、システムはリクエストの並列処理を可能にし、単一スレッドへの競合を軽減します。エンジンはRustで記述されており、言語の2024年版エディションを使用し、Rust 1.89以降の安定版ツールチェーンに依存しています。

ベクトル検索において、KiviDBは近似最近傍探索アルゴリズムを実装しており、特にFLATおよびHNSWインデックスをサポートしています。ベクトルはハッシュフィールド内の生のFLOAT32リトルエンディアンバイトとして格納され、Redis Stackで使用される同じ規約に従います。検索クエリが実行されると、エンジンはこれらのインデックスを使用して類似ベクトルを効率的に探します。システムはキーバリューデータだけでなく、インデックススキーマやHNSWグラフも永続化するため、再起動後も検索品質が一貫して維持され、完全な再構築が必要なくなります。

ソフトウェアはCargo機能を通じて柔軟性を提供し、LuaスクリプトやTLSサポートの有無を選択してビルド変種を作成できます。デフォルトでは、依存関係と攻撃面を最小限にするため、これらの機能なしで動作します。Linuxシステムでは、カーネルが許可する場合、非同期I/Oのためにio_uringの使用を試み、それ以外の場合はTokioにフォールバックします。この低レベルのI/O処理が、高接続数とスループットを効率的に管理できる能力に貢献しています。

主要な詳細

• プロトコル互換性: RESP2およびRESP3をサポートしており、既存のRedisクライアントやツールを変更なしで接続できます。
• 性能主張: ベンチマークでは、32コアで毎秒2,100万回のパイプラインGETを記録し、特定のシナリオにおいてRedis 8やDragonflyを上回りました。
• 内蔵検索: FT.*コマンドを使用したフルテキスト、タグ、数値、およびベクトル検索へのネイティブサポートを含み、外部モジュールの必要性を排除しています。
• マルチスレッドアーキテクチャ: シャーディングされたインメモリ設計を通じてすべてのCPUコアを利用し、標準的なRedisのシングルスレッド性質とは異なります。
• 永続化オプション: データの耐久性のために、スナップショット（dump.kdb）とオプションの追記専用ファイル（AOF）をサポートしています。
• ライセンス: GNU Affero General Public License v3（AGPL-3.0-only）の下でリリースされており、独自ソフトウェアの配布における使用に影響を与える可能性があります。

なぜ重要なのか

AI駆動アプリケーションを構築するソフトウェアエンジニアにとって、キャッシュ層へのベクトル検索の直接統合はインフラを簡素化します。従来、チームはキャッシュとベクトル類似性検索のために別々のサービスを管理する必要があり、運用複雑性の増加や潜在的な整合性問題を引き起こしていました。KiviDBのアプローチにより、開発者は高速なキーバルックアップとセマンティック検索の両方に単一のインターフェースを使用でき、スタック内の可動部品数を削減できる可能性があります。

マルチコア環境で報告された性能向上は、高スループットシステムにおける一般的なボトルネックに対処しています。アプリケーションがスケールするにつれ、従来のRedisのシングルスレッド制限が制約となり、チームは手動でのシャーディングやより複雑なクラスタリングソリューションの採用を余儀なくされることがあります。KiviDBのコア間での自動シャーディングは、シャーディングロジックを処理するためのアプリケーションレベルの変更を必要とせずに、現代のマルチコアサーバーの利用率を高める道を提供します。

ただし、ライセンスの選択は技術リードにとって重要な考慮事項です。AGPL-3.0ライセンスでは、ソフトウェアを修正してネットワーク経由で提供する場合は、ソースコードを公開する必要があります。KiviDBをサービスとして使用することは必ずしもアプリケーションコードをオープンソースにするわけではありませんが、厳格な独自要件を持つ組織にとっては法的レビューが不可欠です。これは、商用利用により寛容な条件を提供するBSD-3-Clauseライセンスを採用しているValkeyなどの代替品とは対照的です。

できること

• docker run -d -p 6380:6380 kividb/kividbを実行してDockerでローカルにKiviDBをテストし、redis-cli -p 6380で接続してください。
• KiviDB、Redis、およびDragonflyに対して特定のワークロードをベンチマークし、マルチスレッドアーキテクチャがユースケースにおいて実質的な利点を提供するかを確認してください。
• KiviDBを商用製品や分散サービスで使用予定の場合、AGPL-3.0ライセンスの影響について法務チームとレビューしてください。
• FT.CREATEでインデックスを作成し、FT.SEARCHでクエリを実行することで、内蔵ベクトル検索機能を試してみて、検索品質と遅延を評価してください。
• Dockerまたはコマンドライン引数で追記専用ファイル（--aof）フラグを有効にして永続化を設定し、再起動間のデータの耐久性を確保してください。
• メモリ使用量を監視してください。ベンチマークでは、KiviDBのキーあたりのメモリ使用量は177バイトと報告されており、Dragonflyの134バイトよりわずかに高いですが、Redisと同程度です。