SingleStoreとRedis AIアプリケーションに適したベクターデータベースの選択
ベクターデータベースとは？
SingleStoreとRedisを比較する前に、まずベクターデータベースの概念を探ってみましょう。 ；
ベクトルデータベース](https://zilliz.com/learn/what-is-vector-database)は、特に高次元のベクトルを格納し、クエリするように設計されています。ベクトルは非構造化データの数値表現です。これらのベクトルは、テキストの意味、画像の視覚的特徴、または製品の属性などの複雑な情報をエンコードします。効率的な類似検索を可能にすることで、ベクトルデータベースはAIアプリケーションにおいて極めて重要な役割を果たし、より高度なデータ分析と検索を可能にしている。
ベクトルデータベースの一般的なユースケースには、電子商取引の商品推奨、コンテンツ発見プラットフォーム、サイバーセキュリティにおける異常検知、医療画像分析、自然言語処理(NLP)タスクなどがある。また、AI幻覚のような問題を軽減するために、外部知識を提供することによって大規模言語モデル(LLM)の性能を向上させる技術であるRAG(Retrieval Augmented Generation)でも重要な役割を果たしている。
市場には、以下のような多くの種類のベクトル・データベースがある：
- Milvus](https://zilliz.com/what-is-milvus)、Zilliz Cloud(フルマネージドMilvus)など。
- Faiss](https://zilliz.com/learn/faiss)やAnnoyのようなベクトル検索ライブラリ。
- Chroma](https://zilliz.com/blog/milvus-vs-chroma)やMilvus Liteのような軽量ベクトルデータベース。
- 小規模なベクトル検索が可能なベクトル検索アドオンを備えた従来のデータベース**。
SingleStoreは分散リレーショナルSQLデータベース管理システムであり、Redisはインメモリデータベースである。この記事では、両者のベクトル検索機能を比較する。
SingleStore：概要とコアテクノロジー
SingleStoreは、データベース自体にベクター検索機能を搭載することで、ベクター検索を可能にしました。ベクターは通常のデータベーステーブルに格納され、標準的なSQLクエリで検索することができます。例えば、価格帯でフィルタリングしながら類似の商品画像を検索したり、特定の部門に結果を限定しながらドキュメントの埋め込みを検索したりすることができます。システムは、ベクトルインデックスにFLAT、IVF_FLAT、IVF_PQ、IVF_PQFS、HNSW_FLAT、HNSW_PQを、類似性マッチングにドット積とユークリッド距離を使用したセマンティック検索の両方をサポートしている。これは、推薦システム、画像認識、AIチャットボットなど、類似性マッチングが高速なアプリケーションに超便利である。
SingleStoreの中核は、パフォーマンスとスケールのために構築されている。データベースは複数のノードにデータを分散させるので、大規模なベクトルデータ操作に対応できます。データが大きくなっても、ノードを追加すれば問題ありません。クエリプロセッサーはベクトル検索とSQLオペレーションを組み合わせることができるので、複数のクエリを別々に実行する必要がありません。ベクターのみのデータベースとは異なり、SingleStoreはこれらの機能を完全なデータベースの一部として提供するため、複数のシステムを管理したり、複雑なデータ転送に対応したりすることなく、AI機能を構築することができます。
SingleStoreのベクトルインデックスには2つのオプションがあります。1つ目は厳密なk-最近傍(kNN)検索で、クエリベクトルに最も近いk個の近傍集合を正確に見つけます。しかし、非常に大きなデータセットや高い同時実行性の場合、SingleStoreはベクトルインデックスを使用した近似最近傍（ANN）検索もサポートします。ANN検索は、厳密なkNN検索よりもはるかに高速にk近傍を見つけることができます。速度と精度はトレードオフの関係にあり、ANNは高速ですが、正確なk個の最近傍セットを返すとは限りません。インタラクティブな応答時間が必要で、絶対的な精度を必要としない数十億のベクトルを扱うアプリケーションには、ANN検索が適しています。
SingleStoreにおけるベクトルインデックスの技術的実装には特別な要件があります。これらのインデックスはカラムストアテーブルにのみ作成可能で、ベクトルデータを格納する単一のカラムに作成する必要があります。システムは現在Vector Type(dimensions[, F32])フォーマットをサポートしており、F32は唯一サポートされている要素タイプです。この構造化されたアプローチにより、SingleStoreは大規模な言語モデルからのベクトルを使用した意味検索、焦点を絞ったテキスト生成のためのRAG（retrieval-augmented generation）、ベクトル埋め込みに基づく画像マッチングなどのアプリケーションに最適です。これらを従来のデータベース機能と組み合わせることで、SingleStoreは開発者がパフォーマンスとスケールを維持しながら、SQL構文を使用して複雑なAIアプリケーションを構築することを可能にします。
Redis概要とコアテクノロジー
Redisはもともとインメモリ・データ・ストレージとして知られていたが、現在はRedis Stackの一部であるRedis Vector Libraryを通じてベクトル検索機能を追加した。これにより、Redisはスピードとパフォーマンスを維持したまま、ベクトルの類似検索ができるようになりました。
Redisのベクトル検索は既存のインフラストラクチャの上に構築されており、高速なクエリ実行のためにインメモリ処理を使用している。Redisは近似最近傍検索にFLATとHNSW（Hierarchical Navigable Small World）アルゴリズムを使用し、高次元のベクトル空間での高速かつ正確な検索を可能にしています。
Redisのベクトル検索の主な強みの1つは、ベクトルの類似性検索と他の属性に関する従来のフィルタリングを組み合わせることができる点です。このハイブリッド検索により、開発者は意味的類似性と特定のメタデータ基準の両方を考慮した複雑なクエリを作成することができるため、多くのAI駆動型アプリケーションで汎用性があります。
Redis Vector Libraryは、開発者がRedisでベクトルデータを扱うためのシンプルなインターフェースを提供します。柔軟なスキーマ設計、カスタムベクタークエリ、セマンティックキャッシングやセッション管理などのLLM関連タスクの拡張機能などを備えている。これにより、AI/MLエンジニアやデータサイエンティストは、特にリアルタイムのデータ処理と検索のために、RedisをAIワークフローに統合することが容易になります。
主な違い
検索方法とアルゴリズム
SingleStoreは検索アルゴリズムに複数の選択肢を提供しており、様々なユースケースに適応可能です。システムは厳密なk-nearest neighbors (kNN)と近似最近傍(ANN)の両方の検索方法を実装しています。特にANNについては、SingleStoreはFLAT、IVF_FLAT、IVF_PQ、IVF_PQFS、HNSW_FLAT、HNSW_PQインデックスメソッドをサポートしている。この多様性により、開発者は特定のニーズに基づいて、検索精度とスピードのバランスをとることができる。
Redisはベクトル検索アルゴリズムに対してより合理的なアプローチを取っている。主に2つの実装に焦点を当てている：FLATとHNSW（Hierarchical Navigable Small World）だ。どちらのシステムも、ドット積やユークリッド距離のような一般的な類似性メトリックをサポートしており、ユーザーにベクトルの類似性計算に必要な標準的なツールを提供します。
データ管理とアーキテクチャ
SingleStoreは、ベクトル検索をSQLデータベースシステムに直接統合している点が特徴です。この統合により、開発者はベクターを標準的なデータベーステーブルに格納し、ベクター検索を通常のSQL操作と組み合わせることができます。このシステムにより、ユーザーは異なるデータベースを切り替えることなく複雑なクエリを実行することができ、標準SQL条件を使用してベクトル検索結果をフィルタリングすることができます。この統一されたアプローチは、アーキテクチャを簡素化し、複数のシステムを管理する複雑さを軽減します。
Redisは、Redis Stackを通じて既存のインメモリアーキテクチャの上にベクトル検索機能を構築している。この設計上の選択により、Redisの特徴であるスピードは維持されながら、ベクトル機能が追加されている。このシステムは、ベクターの類似性とメタデータのフィルタリングを組み合わせたハイブリッド検索機能を提供します。
スケーラビリティのアプローチ
SingleStoreは、大規模なベクトル操作を処理するために分散アーキテクチャを採用しています。システムは複数のノードにデータを分散させるため、ユーザはデータの増加に応じてノードを追加して拡張することができます。この分散アプローチは、SingleStoreがパフォーマンスを維持しながらデータ量の増加に対応できることを意味し、成長するアプリケーションに適しています。
Redisは、ベクトル検索処理に実績のあるインメモリ処理モデルを活用している。提供されているドキュメントには、ベクトル検索に対する正確なスケーリング・メカニズムの詳細は記載されていないが、システムはベクトル操作に対してRedisの特徴であるスピードを維持しており、多くのユースケースで効率的である。
インテグレーションと使用法
SingleStoreはベクトル操作にSQLベースのインターフェイスを提供するため、すでにSQLデータベースを使用しているチームにはなじみやすい。ベクトル・インデックスはカラムストア・テーブルでのみ動作し、単一のベクトル・データ列で作成する必要があり、現在は Vector Type(dimensions[, F32])形式をサポートしています。これらの要件により、ベクトル操作のための構造化されたフレームワークが構築される。
Redisは、最新のAIアプリケーション向けに設計された様々な機能を提供するVector Libraryを通じて統合を提供します。このシステムには、柔軟なスキーマ設計機能、カスタムベクタクエリ、言語モデルタスクに特化した拡張機能が含まれている。また、セマンティック・キャッシングやセッション管理のためのツールも提供しており、特にAI主導のアプリケーションに適している。
SingleStoreを選ぶとき
SingleStoreは、ベクトル検索を備えた完全なSQLデータベースを必要とするアプリケーション、特に大規模な分散データ処理、ベクトル検索を備えた複雑なSQL、またはすでにSQLシステムに精通しているチームと作業する場合、特にベクトル操作を行いながらデータの一貫性を維持する必要があるエンタープライズ・アプリケーションに適しています。
Redisを選ぶとき
Redisは、特に高速なインメモリ・ベクトル処理、柔軟なスキーマ設計、言語モデルの統合など、スピードとシンプルさを必要とするアプリケーションに適しています。特に、リアルタイム・アプリケーション、迅速なベクトル類似検索を必要とするAI駆動システム、またはインメモリ・パフォーマンスが重要なプロジェクトに適しています。
概要
SingleStoreかRedisか - 選択はユースケースに依存する - SingleStoreはベクトル機能を備えた完全なSQLデータベースで、複雑な分散アプリケーションに最適であり、Redisはそのインメモリアーキテクチャ上に構築された高性能なベクトル検索ソリューションである。データサイズ、クエリの複雑さ、パフォーマンスニーズ、そしてフルデータベースとベクトル検索ソリューションのどちらが必要かを考慮して選択する必要があります。
SingleStoreとRedisの概要についてはこちらをお読みいただきたいが、これらを評価するには、ユースケースに基づいて評価する必要がある。それに役立つツールの1つが、ベクターデータベースを比較するためのオープンソースのベンチマークツールであるVectorDBBenchだ。最終的には、独自のデータセットとクエリパターンで徹底的なベンチマークを行うことが、分散データベースシステムにおけるベクトル検索に対する、強力だが異なるこの2つのアプローチのどちらを選ぶかを決める鍵となるだろう。
オープンソースのVectorDBBenchを使ってベクトルデータベースを評価・比較する
VectorDBBenchは、高性能なデータ保存・検索システム、特にベクトルデータベースを必要とするユーザーのためのオープンソースのベンチマークツールです。このツールにより、ユーザはMilvusやZilliz Cloud(マネージドMilvus)のような異なるベクトルデータベースシステムを独自のデータセットを使ってテストし比較し、自分のユースケースに合うものを見つけることができます。VectorDBBenchを使えば、ユーザーはマーケティング上の主張や伝聞ではなく、実際のベクターデータベースのパフォーマンスに基づいて決定を下すことができます。
VectorDBBenchはPythonで書かれており、MITオープンソースライセンスの下でライセンスされています。VectorDBBenchは、その機能と性能の改善に取り組む開発者のコミュニティによって活発にメンテナンスされています。
VectorDBBenchをGitHubリポジトリ**からダウンロードして、我々のベンチマーク結果を再現したり、あなた自身のデータセットでパフォーマンス結果を得てください。
VectorDBBench Leaderboard](https://zilliz.com/vector-database-benchmark-tool?database=ZillizCloud%2CMilvus%2CElasticCloud%2CPgVector%2CPinecone%2CQdrantCloud%2CWeaviateCloud&dataset=medium&filter=none%2Clow%2Chigh&tab=1)で、主流のベクトルデータベースのパフォーマンスを簡単に見てみましょう。
ベクターデータベースの評価については、以下のブログをお読みください。
- ベンチマーク・ベクター・データベースのパフォーマンス：テクニックと洞察](https://zilliz.com/learn/benchmark-vector-database-performance-techniques-and-insights)
- VectorDBBench: Open-Source Vector Database Benchmark Tool](https://zilliz.com/learn/open-source-vector-database-benchmarking-your-way)
- ベクターデータベースを他のデータベースと比較する](https://zilliz.com/comparison)
VectorDB、GenAI、MLに関するその他のリソース
- ジェネレーティブAIリソースハブ｜Zilliz](https://zilliz.com/learn/generative-ai)
- あなたのGenAIアプリのためのトップパフォーマンスAIモデル｜Zilliz](https://zilliz.com/ai-models)
- RAGとは](https://zilliz.com/learn/Retrieval-Augmented-Generation)
- 大規模言語モデル(LLM)を学ぶ](https://zilliz.com/learn/ChatGPT-Vector-Database-Prompt-as-code)
- ベクトルデータベース101](https://zilliz.com/learn/what-is-vector-database)
- 自然言語処理(NLP)](https://zilliz.com/learn/introduction-to-natural-language-processing-tokens-ngrams-bag-of-words-models)
Chloe WilliamsChloe Williams is a technical writer at Zilliz.
読み続けて
Semantic Search vs. Lexical Search vs. Full-text Search
Lexical search offers exact term matching; full-text search allows for fuzzy matching; semantic search understands context and intent.
GPL: Generative Pseudo Labeling for Unsupervised Domain Adaptation of Dense Retrieval
GPL is an unsupervised domain adaptation technique for dense retrieval models that combines a query generator with pseudo-labeling.
Evaluating Retrieval-Augmented Generation (RAG): Everything You Should Know
An overview of various RAG pipeline architectures, retrieval and evaluation frameworks, and examples of biases and failures in LLMs.
The Definitive Guide to Choosing a Vector Database
Overwhelmed by all the options? Learn key features to look for & how to evaluate with your own data. Choose with confidence.