SingleStore vs MongoDB AIアプリケーションに適したベクターデータベースの選択

ベクターデータベースとは？

SingleStoreとMongoDBを比較する前に、まずベクターデータベースの概念を探ってみましょう；

ベクトルデータベース](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データベース管理システムであり、MongoDBはJSONライクなドキュメントでデータを格納するNoSQLデータベースである。どちらもアドオンとしてベクトル検索を備えている。この記事では、両者のベクトル検索機能を比較する。&#x20；

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アプリケーションを構築することを可能にします。

##MongoDB：概要とコアテクノロジー

MongoDB Atlas Vector Searchは、MongoDB Atlasに保存されたデータに対してベクトルの類似性検索を行う機能です。高次元のベクトル埋め込みデータを文書データと一緒にインデックス化してクエリし、データベース内でAIや機械学習を行うことができます。

Atlas Vector Searchの中核は、HNSW（Hierarchical Navigable Small World）アルゴリズムを使ったベクトルデータのインデックス化と検索です。これによりベクトル空間の多階層グラフが作成され、近似最近傍（ANN）検索が可能になる。これは大規模なベクトル検索におけるスピードと精度のバランスです。Atlas Vector Search は、10,000 ドキュメントまでのクエリに対して、パフォーマンスよりも精度を優先する Exact Nearest Neighbors (ENN) 検索もサポートしています。

Atlas Vector Searchの大きな利点の一つは、MongoDBの柔軟なドキュメントモデルとの統合です。ベクトル埋め込みを他のドキュメントデータと一緒に保存できるので、より文脈に沿った正確な検索ができます。最大4096次元まで埋め込むことができ、どのようなデータでもクエリできます。アトラスベクター検索では、ベクトルの類似検索と従来の文書フィルタリングを組み合わせることができます。例えば、商品のセマンティック検索は、カテゴリー、価格帯、在庫状況でフィルタリングすることができます。

また、Atlas Vector Searchはハイブリッド検索にも対応しており、ベクトル検索とフルテキスト検索を組み合わせることで、より詳細な検索結果を得ることができます。これは、キーワードベースの検索に特化したAtlas Searchとは異なる。このプラットフォームは一般的なAIサービスやツールと統合されているため、OpenAIやVoyageAI、その他Hugging Faceに掲載されている多くのプロバイダーのモデルを埋め込んで使用することができる。また、大規模言語モデル（LLM）を使用するアプリケーションを構築するためのLangChainやLlamaIndexのようなオープンソースのフレームワークもサポートしています。

スケーラビリティとパフォーマンスを保証するために、MongoDBアトラスは、アトラスサーチとベクターサーチのワークロード専用のインフラを提供するサーチノードを提供しています。これにより、最適化されたコンピュートリソースと、検索ニーズの独立したスケーリングが可能になり、スケール時のパフォーマンスが向上します。

これらの機能をMongoDBエコシステム内に持つことで、Atlas Vector SearchはAIを活用したアプリケーション、レコメンデーションシステム、高度な検索機能を構築する開発者にとって完全なソリューションとなります。ベクターデータベースを別途用意する必要がなく、MongoDBのスケーラビリティと豊富な機能をベクター検索と共に利用することができます。

主な違い

検索方法とアルゴリズム

SingleStoreは様々なユースケースに対応できるよう、複数のベクトル検索オプションを用意しています。厳密な結果を求める場合は、厳密なk-nearest neighbors (kNN)検索を行います。SingleStoreは、正確さよりもスピードを重視する場合、複数のインデックスタイプを持つ近似最近傍（ANN）検索を行います：FLAT、IVF_FLAT、IVF_PQ、IVF_PQFS、HNSW_FLAT、HNSW_PQ。類似性マッチングにドット積とユークリッド距離の両方をサポートしているため、 開発者はベクトルの類似性を測定する方法を柔軟に選択できる。

MongoDB Atlas Vector Search は、より集中的なアプローチで、HNSW (Hierarchical Navigable Small World) を主な検索手法としています。10,000ドキュメントまでの小規模なデータセットでは、MongoDBはENN（Exact Nearest Neighbors）検索を行う。それ以上の規模になると、パフォーマンスを維持するためにANN検索に切り替わる。これにより、検索機能を提供しながら、開発者の判断を簡素化することができる。

データの取り扱いと構造

SingleStoreはカラムストアテーブルに基づいた構造化アプローチを採用しています。ベクターデータは以下の形式でなければならない：Vector Type(dimensions[, F32])の形式でなければなりません。この構造化アプローチにより、SingleStoreは従来のSQLとベクトル操作を効率的に組み合わせることができます。これは、SQL操作が主な要件である明確なデータスキーマを持つアプリケーションに適しています。

MongoDBはドキュメントベースのストレージで、より緩やかなアプローチを取ります。MongoDBは4096次元までのベクトルをサポートしており、ベクトルデータとあらゆるドキュメント構造を混在させることができる。この柔軟性により、MongoDBはスキーマが時間とともに変わる可能性のある半構造化データや非構造化データを扱うアプリケーションに適している。

スケーラビリティとパフォーマンス

SingleStoreは複数のノードにデータを分散することでスケーリングします。データの増加に応じてノードを追加し、パフォーマンスを維持することができます。SingleStoreはベクトル検索とSQLを1つのクエリに統合することで、複雑さを軽減し、パフォーマンスを向上させます。このアーキテクチャにより、SingleStoreは従来のデータベース内での高性能なベクトル操作に適しています。

MongoDBは、ベクトル検索ワークロード専用の検索ノードによってスケールします。このように検索インフラをメインのデータベース操作から分離することで、検索を独立してスケーリングできる。MongoDBはベクトル検索を統合したドキュメントベースのオペレーションに最適化されているので、従来のドキュメントストレージとベクトル検索機能のバランスを取る必要があるアプリケーションに適しています。

統合とエコシステム

SingleStoreの強みはSQLベースのアプローチにあります。既存のSQLツールやワークフローとシームレスに連携するため、既存のSQLの専門知識やインフラを持つ組織にとって最適な選択肢です。強力なSQL統合を必要とするアプリケーションは、アーキテクチャを大幅に変更することなくSingleStoreのベクトル機能を使用することができます。

MongoDBは、OpenAIやVoyageAIのような一般的なAIサービスと幅広く統合されている。LangChainやLlamaIndexのような最新のAIフレームワークをサポートし、様々なエンベッディングモデルに対応している。また、ベクトル検索と全文検索を組み合わせたハイブリッド検索のサポートも組み込まれている。この豊富なエコシステムにより、MongoDBはAI駆動のアプリケーションに適した選択肢となっている。

シングルストアを選ぶとき

SingleStoreはSQLを使用し、構造化データを大規模に扱う必要がある企業向けだ。金融分析プラットフォーム、リアルタイム・レコメンデーション・エンジン、正確な結果を必要とする大規模画像類似検索システムなど、正確なベクトルマッチングが重要なエンタープライズ・アプリケーションに最適です。従来のデータベース操作とベクトル検索を組み合わせる必要があり、チームにSQLの専門知識があり、インフラがリレーショナルデータベースを中心に構築されている場合に適しています。

MongoDBを選ぶとき

MongoDBは、あなたのアプリが柔軟なデータ構造と最新のAIサービスとのシームレスな統合を必要とする場合、当然の選択です。ベクトル検索と非構造化データを組み合わせる必要があるコンテンツ推薦システム、セマンティック文書検索、AI搭載チャットボットなどのアプリケーションに最適です。ベクトル検索の実装を迅速にプロトタイプ化して反復する必要がある場合、ハイブリッド検索が必要な場合、または多くのAIサービスや埋め込みモデルと統合する予定がある場合に適しています。

結論

SingleStoreとMongoDBはどちらもベクトル検索に適しているが、現代のアプリの状況では異なるニーズに応えている。SingleStoreの強みは、SQLファーストのアプローチ、正確なベクトル操作、スケールでの構造化データの処理である。MongoDBの柔軟性、AIサービスの統合、ドキュメントベースのアプローチは、ベクトル検索と複数のデータ型やAI機能を組み合わせる必要があるモダンなアプリに最適です。ユースケース、既存の技術スタック、チームの専門知識、正確なSQLベースのオペレーションが必要か、柔軟性とAI統合の容易さが必要かを考慮して選択する必要がある。

SingleStoreとMongoDBの概要についてはこちらをお読みいただきたいが、これらを評価するには、ユースケースに基づいて評価する必要がある。それに役立つツールの一つが、ベクターデータベースを比較するためのオープンソースのベンチマークツールである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)