SingleStore vs TiDB AIアプリケーションに適したベクターデータベースの選択
ベクターデータベースとは？
SingleStoreとTiDBを比較する前に、まずベクターデータベースの概念について説明します；
ベクトルデータベース](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データベース管理システムであり、Rocksetはベクトル検索機能をアドオンとして持つ検索・分析データベースである。どちらもアドオンとしてベクトル検索機能を持っている。この記事では、両者のベクトル検索機能を比較する。
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アプリケーションを構築することを可能にします。
TiDBとは？概要
TiDBはPingCAP社によって開発されたオープンソースの分散SQLデータベースで、ハイブリッドトランザクション処理と分析処理（HTAP）機能を提供する。MySQLと互換性があるため、MySQLのエコシステムに慣れ親しんでいるチームにとっては導入が容易です。TiDBの分散SQLアーキテクチャは、SQLデータベースのリレーショナルモデルを維持しながら、NoSQLデータベースのような水平スケーラビリティを提供し、トランザクションと分析の両方のワークロードを処理するための高い柔軟性を実現しています。
TiDBの中核的な強みの1つはHTAPアーキテクチャであり、トランザクション（OLTP）と分析（OLAP）のワークロードを単一のデータベースで処理できるため、別々のシステムを用意する必要がありません。さらに、TiDBはMySQLと互換性があるため、アプリケーションコードを大幅に変更することなく、MySQLに依存している既存の環境に簡単に統合することができます。また、このデータベースは自動シャーディング機能を備えており、ノード間でデータを自動的に分散することで、強力な一貫性を維持しながら読み取りと書き込みのパフォーマンスを向上させます。
TiDBは外部ライブラリやプラグインとの統合によりベクトル検索をサポートし、ベクトル化されたデータの効率的な管理とクエリを可能にします。この機能とTiDBのHTAPアーキテクチャを組み合わせることで、トランザクションや分析ワークロードに加えてベクトル検索機能を必要とするビジネスにとって、TiDBは汎用性の高い選択肢となります。TiDBの分散アーキテクチャにより、必要な構成が整えば、大規模なベクタークエリを処理することができます。
TiDBにベクトル検索機能を組み込むには追加の設定が必要ですが、TiDBはSQLと互換性があるため、開発者はベクトル検索と従来のリレーショナルクエリを組み合わせることができます。この柔軟性により、TiDBはベクトル検索とリレーショナルデータベースの両方の機能を必要とする複雑なアプリケーションに適しており、多様なデータ管理ニーズに対する包括的なソリューションを提供します。
主な違い
検索方法
SingleStoreでは、データベース内ベクトル検索において、厳密なk-nearest neighbors (kNN)検索と近似最近傍(ANN)検索が可能です。アプリケーションのニーズに応じて、精度と速度を調整することができます。SingleStoreは、FLAT、IVF_FLAT、HNSWのようなベクトルインデキシングメソッドをビルトインでサポートしており、データベース内で高性能な類似性マッチングを行うことができます。
一方、TiDBは外部ライブラリやプラグインを通じてベクトル検索を統合している。これにより柔軟性が増す一方で、外部コンポーネントに依存することで複雑さが増し、性能にばらつきが生じる可能性がある。TiDBの強みは、ベクトル検索とハイブリッド・トランザクション＆アナリティカル・プロセッシング（HTAP）アーキテクチャを組み合わせることだが、そのためには余分な設定が必要になる。
データハンドリング
SingleStoreは、ベクター・データをカラムストア・テーブルに格納し、ベクター・クエリーと一緒にSQL操作を行うことができる。そのため、セマンティック検索やAIを利用したレコメンデーションなどのアプリケーションに適している。しかし、Vector Type(dimensions[,,F32])フォーマットに制限されており、ユースケースによっては柔軟性に欠けるかもしれない。
TiDBは様々なワークロード、構造化、半構造化、非構造化データを扱うことができる。MySQLと互換性があるため、すでにMySQLのエコシステムを利用しているチームにとっては導入しやすい。ベクターデータについては、TiDBは外部ツールを使用し、柔軟性を提供するが、余分なセットアップと潜在的なオーバーヘッドを犠牲にする。
スケーラビリティとパフォーマンス
SingleStoreはベクトルデータとリレーショナルデータをノードに分散するため、スケーラビリティが容易です。データが増加しても、ノードを追加することで、アーキテクチャを変更することなく、一貫したパフォーマンスを実現します。内蔵の ANN インデックスは、数十億のベクトルを持つアプリケーションの大規模データセットのクエリ速度を最適化します。
TiDBは、自動シャーディングとロードバランシングを備えた分散SQLアーキテクチャにより、水平方向のスケーラビリティも備えています。リレーショナルなワークロードに対するスケーラビリティは実証済みだが、ベクトル・クエリのパフォーマンスは外部統合に依存するため、スムーズにスケールしない可能性がある。
柔軟性とカスタマイズ
SingleStoreはSQLベースのベクトル検索に最適化されているため、使い慣れた構文を使用してアプリケーションを構築することができます。しかし、構造化されたアプローチによるベクトルインデックスとストレージは、 ベクトルだけのために構築されたシステムに比べて柔軟性を制限するかもしれません。
TiDBはベクトル検索に外部ライブラリを使用するため、より多くのカスタマイズが可能です。TiDB**は、ベクトル検索に外部ライブラリを使用するため、よりカスタマイズが可能です。
統合とエコシステム
SingleStoreは、OpenAIやHugging Faceのようなモデルからのベクトル埋め込みに対するSQL操作を可能にすることで、AIやMLパイプラインとうまく統合します。これにより、データ転送のオーバーヘッドが削減され、アプリケーション開発がシームレスになります。
TiDBはMySQLと強力な互換性があるため、既存のMySQLツールやエコシステムとの統合が容易だ。しかし、そのベクトル検索は外部ライブラリに依存しており、エンドツーエンドのワークフローに統合するには余分な労力が必要だ。
使いやすさ
SingleStoreは、ベクトル操作とリレーショナル操作の両方を1つのシステムで行うことで、開発を簡素化します。ドキュメンテーションと一般的なインデックス作成方法のサポートにより、1 つのソリューションですべてを実現したい開発者にとって使いやすいものとなっています。
TiDBは、リレーショナルなタスクでは開発者に優しいが、ベクトル検索では追加ツールや外部ツールを設定する必要があるため、学習曲線が急な場合がある。
コスト
SingleStoreはベクターとリレーショナル・データ管理を1つのシステムに統合するため、別々のデータベースを維持するコストを削減できる可能性がある。しかし、ライセンスとスケーリングコストはワークロードに基づいて評価されるべきである。
TiDBはオープンソースであり、基本的なセットアップにはコスト面で有利である。しかし、外部ライブラリを使ってベクトル検索を追加する場合、運用と保守の追加コストが発生する可能性がある。
セキュリティ
SingleStoreは暗号化、ロールベースのアクセス制御、セキュアな接続をエンタープライズ向けサービスの一部として提供しているため、機密性の高いアプリケーションに適している。
TiDBにもセキュリティ機能があり、暗号化とアクセス制御ができる。しかし、ベクトル検索用の外部プラグインは、コンプライアンスとセキュリティのために特別な注意が必要だ。
SingleStoreを選択する場合
SingleStoreは、単一のシステムでベクトル検索とリレーショナルクエリの両方を大規模に処理する必要があるアプリケーションに最適です。正確なkNNとANNインデックスを内蔵し、ベクトル検索とSQLを組み合わせることができるため、セマンティック検索、レコメンデーションシステム、画像認識などのAIを活用したアプリケーションに最適です。高速な類似性マッチング、シームレスなノードのスケーリング、別々のシステムを管理する複雑さを軽減する必要がある場合、SingleStoreの統合されたアプローチは、ビッグデータのための高いパフォーマンスと使いやすさを提供します。
TiDBを選ぶとき
TiDBは、特にMySQLエコシステム内でハイブリッドトランザクション処理と分析処理（HTAP）が必要とされるシナリオに最適です。リアルタイムのデータ分析やオペレーショナルインテリジェンスなど、分析ワークロードとトランザクションの一貫性を必要とするアプリケーションに最適です。フルテキスト検索を使用する場合や、アドオン機能としてベクトル検索のカスタム設定が必要な場合は、TiDBの分散SQL機能と自動シャーディングによるスケーラビリティを活用しながら、外部ライブラリと統合することができます。
結論
SingleStoreとTiDBはどちらも優れており、SingleStoreはスケーラブルなベクトル検索とリレーショナル検索を得意とし、TiDBはHTAPとカスタマイズを得意としています。高性能なベクトル検索にオールインワンのソリューションが必要な場合はSingleStoreを、HTAP、MySQLとの互換性、カスタム統合を優先する場合はTiDBを選択する。お客様のデータタイプ、スケーラビリティ要件、パフォーマンスニーズに合ったテクノロジーを選択することで、最良の結果を得ることができます。
これを読めばSingleStoreとTiDBの概要がわかりますが、これらを評価するにはユースケースに基づいて評価する必要があります。それに役立つツールの一つが、ベクターデータベースを比較するためのオープンソースのベンチマークツールである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: オープンソースベクターデータベースベンチマークツール](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.
読み続けて
How to Build an Enterprise-Ready RAG Pipeline on AWS with Bedrock, Zilliz Cloud, and LangChain
Build production-ready enterprise RAG with AWS Bedrock, Nova models, Zilliz Cloud, and LangChain. Complete tutorial with deployable code.
Why AI Databases Don't Need SQL
Whether you like it or not, here's the truth: SQL is destined for decline in the era of AI.
How to Build RAG with Milvus, QwQ-32B and Ollama
Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B model and Milvus.
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.