paint-brush
主なベンチマークを使用した Meilisearch と Manticore Search の比較@snikolaev
4,200 測定値
4,200 測定値

主なベンチマークを使用した Meilisearch と Manticore Search の比較

Sergey Nikolaev10m2023/05/02
Read on Terminal Reader

長すぎる; 読むには

検索エンジンは、さまざまなプラットフォームで検索機能を強化する上でますます重要な役割を果たしています。プロジェクトに適した検索エンジンを選択するには、そのパフォーマンス、使用例、および制限を完全に理解する必要があります。この記事は、機能セットとデータ取り込みに焦点を当てて、Meilisearch と Manticore Search を比較することを目的としています。
featured image - 主なベンチマークを使用した Meilisearch と Manticore Search の比較
Sergey Nikolaev HackerNoon profile picture
0-item
1-item

進化を続けるデジタル環境において、検索エンジンは、さまざまなプラットフォームで検索機能を強化する上でますます重要な役割を果たしています。人気のある検索エンジンの中で、 MeilisearchManticore Search は独自のサービスで際立っています。


ただし、プロジェクトに適した検索エンジンを選択するには、そのパフォーマンス、使用例、および制限を完全に理解する必要があります。この記事は Meilisearch と Manticore Search の比較を提供することを目的としており、1,000 万個の NGINX ログ、Hacker News の 110 万個のドキュメント データセット、および Hacker News の 1 億 1,600 万個のドキュメント データセットという 3 つの実際のベンチマークにおける機能セットとデータの取り込みと検索パフォーマンスに焦点を当てています。すべてDB Benchmarksで入手できます。すべてのパフォーマンス テスト スクリプト、構成、およびデータ コレクションは公開されており、再現可能です。

全文検索の関連性

Manticore と Meilisearch はどちらも、全文検索エンジンとしての地位を確立しています。全文検索エンジンの重要な要素は、検索中にドキュメントをランク付けする方法です。


適切な検索ランキング アルゴリズムを選択することは、ユーザーが必要な情報を正確かつ再現的に見つけられるようにするために重要です。全文検索の関連性のコンテキストでは、これらのアルゴリズムがどのように機能し、正確で意味のある検索結果を提供するためにどのように貢献するかを理解することが不可欠です。


Manticore Search は非常に柔軟に検索ランキングを制御し、多数のランキング要素を公開します。ただし、デフォルトでは、従来の BM25 アルゴリズムとその派生アルゴリズムが使用されます。 BM25 は、用語の頻度とドキュメントの逆頻度に基づいてドキュメントの関連性を計算する、確立された情報検索アルゴリズムです。


BEIR (Benchmarking and Evaluation of Information Retrieval) ベンチマークに対する進行中のプル リクエストは、 Manticore Search の検索関連性への取り組みを示しています。 BEIR は、文書検索や質問応答など、さまざまなタスクに関する情報検索システムのパフォーマンスを測定する評価フレームワークです。 BEIR ベンチマークの結果は、次の場所にあります。


https://docs.google.com/spreadsheets/d/1_ZyYkPJ_K0st9FJBrjbZqX14nmCCPVlE_y3a_y5KkYI/edit#gid=0 .


対照的に、Meilisearch は優れた検索関連性を提供すると主張していますが、この主張を実証する公開ベンチマークはありません。 Hacker Newsでの議論によると、Meilisearch ユーザーはその検索関連性について言及していますが、経験的な証拠がないため、そのパフォーマンスを Manticore Search と客観的に比較することは困難です。


全体として、Manticore Search の実績のあるランキング アルゴリズムの使用と BEIR ベンチマークへの参加は、関連性の高い検索結果を提供するという同社のコミットメントを強調しており、さまざまなアプリケーションにとって信頼できる選択肢となっています。 Meilisearch は全文検索の関連性にも優れているかもしれませんが、確立されたベンチマークがなく、使用されているアルゴリズムが広く知られていないため、決定的な声明を出すことは困難です.

インデックスのサイズとデータの取り込み

Manticore Search は、行単位および列単位のストレージを使用することで、大規模なデータセット (例: 17 億件のドキュメントのタクシー乗車テストまたは単にCraigslist.org ) を効果的に処理する能力を示しています。カラム型アプローチは、大規模なデータセットで検索パフォーマンスを高速化し、RAM 消費を削減するように特別に設計されています。対照的に、Manticore Search のデフォルトの行単位のストレージは、小規模および中規模のデータセットで比類のないパフォーマンスを提供します。この柔軟性により、Manticore Search は幅広いアプリケーションにとって理想的な選択肢となります。


一方、Meilisearch は、 Hacker News のより大きなデータセットを2 日間読み込んだ後でも検索エンジンに読み込むことができなかったため、より大きなデータセットに苦労しています。さらに、Meilisearch では、ドキュメントをロードするときにパフォーマンスが低下します。データセットが大きくなるにつれて、ドキュメントの後続の各バッチを読み込むのにかかる時間が長くなります。このパフォーマンスの問題は、Meilisearch にデータのスケーラビリティの問題があり、リアルタイムのデータ取り込みや大規模なデータセットのインデックス作成を必要とするアプリケーションで問題になる可能性があることを示しています。 Meilisearch はドキュメントの更新を単一のキューで処理するため、時間の経過とともにボトルネックやパフォーマンスの低下につながる可能性があります。


Meilisearch でのドキュメントの更新は、検索クエリにすぐには反映されないことに注意してください。これは、Meilisearch が更新を処理するために非同期タスク キューを採用し、集中的なインデックス作成操作中でも検索パフォーマンスが安定しているためです。

ドキュメントを更新すると、変更がタスク キューに追加され、バックグラウンドでエンジンによって処理されます。タスクが完了すると、更新されたデータが検索結果に表示されます。処理時間は、更新のサイズとサーバー リソースによって異なります。タスクのステータスを監視するには、タスクの進行状況と完了に関する情報を提供するTasks APIを利用できます。


マンティコアはリアルタイムのインセを提供します

rt、replace、および delete 機能により、クエリが完了するとすぐに変更を表示できます。


要約すると、Meilisearch は高速で効率的な検索機能を提供しますが、非同期のタスク処理が原因で、ドキュメントの更新が検索結果にすぐに表示されない場合があることに注意してください。

検索パフォーマンス

Meilisearch は、その印象的な速度で知られており、 多くの場合、Elasticsearch よりも優れています。ただし、そのパフォーマンスは、小さなデータセットを操作するときに最も顕著になります。データセットのサイズが大きくなると、Meilisearch のパフォーマンスが低下する可能性があります。


Manticore Search は、Meilisearch とElasticsearchの両方を上回り、さまざまなクエリ タイプとデータセット タイプに対して一貫して高速なクエリ パフォーマンスを提供します。最適化された行単位および列単位のインデックス作成方法により、Manticore は、高性能アプリケーションでユーザー エンゲージメントを維持するために不可欠な応答性の高い検索エクスペリエンスを保証します。


対照的に、Meilisearch は大規模なデータセットを効率的に処理するのに苦労しており、ドキュメントの読み込み中のパフォーマンスの低下に悩まされています。したがって、データセットのサイズを気にしたくない人にとっては、Manticore が優れた選択肢です。

ベンチマーク テスト

Hacker News Small Dataset (Hacker News Comments)

Hacker News の小さなデータセット ベンチマークは、数値フィールドを含む 110 万件の厳選された Hacker News コメントのコレクション (出典: https://zenodo.org/record/45901/ ) を特徴とし、Meilisearch よりも Manticore Search の検索パフォーマンスが高いことを強調しています。データセットには、コメントのテキスト データと、賛成票、タイムスタンプ、ユーザー ID などの数値フィールドが含まれています。ベンチマーク テストでは、検索エンジンの機能を評価するために全文および分析クエリを実行します。



ベンチマーク結果は、 このリンクからも確認できます。


残念ながら、Meilisearch は、集計クエリや否定的な全文検索用語を含むクエリなど、多くの種類のクエリを実行できません。


このベンチマークの興味深い点は、2 つの検索エンジンのディスク容量の使用量に大きな違いがあることです。


 [email protected] /perf/test_engines/tests/hn_small/manticore # du -sh idx 1.1G idx [email protected] /perf/test_engines/tests/hn_small/meilisearch # du -sh . 38G .


Meilisearch は、Manticore Search と比較して、同じデータセットを保存するために34 倍のディスク容量を必要とします。

データ読み込みのパフォーマンスに関しては、次のようになりました。


  • メイリサーチ 31分
  • マンティコア 65秒


データの読み込みを完全に完了します。

Hacker News 大規模データセット (1 億 1,600 万件のコメント)

このテストには、同じ 110 万件のキュレートされた Hacker News コメント データセット (出典: https://zenodo.org/record/45901/ ) が含まれますが、100 倍され、約1 億 1,600 万のドキュメントになります。このベンチマークは、全文クエリと分析クエリの両方をカバーしているため、検索エンジンの機能を大規模に評価するための優れたテスト ケースとなっています。


Meilisearch は 2 日でデータを読み込めませんでした。データベースが大きくなるにつれて、挿入のパフォーマンスが低下しました。最適化を試みましたが、並列化しようとしてもすべてのバッチが 1 つのキューに入ったため、うまくいきませんでした。その結果、Meilisearch のデータ負荷の改善は達成できませんでした。 Meilisearch がデータの 38% のみをロードするのに約 2 日かかりましたが、このデータはすでに 850 GB を超えるディスク容量を消費していました。これは、約 100 GB のディスク領域を使用してデータセット全体を保存し、単一の CPU コアを使用してロードするのに 2 時間 9 分かかった Manticore Search とはまったく対照的です (これは実質的に直線的にスケーラブルです)。


Meilisearch が Hacker News の大規模なデータセット全体を処理できないことは、より広範なデータ コレクションを管理およびスケーリングする際の課題を浮き彫りにしています。このベンチマークでの Manticore Search の優れたパフォーマンスは、大規模な検索要件を処理する能力を強調しており、大規模なデータ コレクションを持つアプリケーションにより適した選択肢となっています。

データを Meilisearch に読み込むことができなかったため、マンティコアのみの結果はこちらで確認できます。

1,000 万の NGINX ログ

このテストは、1,000 万の NGINX ログを含むデータセットに基づいています。このデータセットのソースはKaggleです。 Web サーバー ログはさまざまなイベントを記録し、Web サイトの訪問者、ユーザーの行動、サイトにアクセスするクローラー、ビジネス インテリジェンス、セキュリティの問題などに関する貴重な洞察を提供します。ベンチマークでは、ランダムな DevOps エンジニアが実行する可能性のある典型的なクエリの精選されたリストを使用します。

Manticore Search と Meilisearch では、データセットのディスク容量の使用量に大きな違いが見られました。 Manticore Search は 4.4 GB のディスク容量を使用しましたが、Meilisearch は 69 GB を使用しました。これは Manticore の約15 倍です。違いは Hacker News の小さなデータセット テストほど劇的ではありませんが、特に Logs10m データセットに含まれるテキスト データが少ないことを考えると、それでも注目に値します。


Meilisearch はデータを埋めるのに約20 分かかりましたが、Manticore は6 分で完了しました。

提供されたリンクを使用して、パフォーマンス結果の詳細な比較を見つけることができます。多くの空の結果は、単に Meiliesarch が特定の種類のクエリを処理できないことが原因であることに注意してください。その結果、これらのクエリはベンチマーク プロセス中にスキップされました。



マンティコアサーチとメイリサーチの機能比較

  • 全文一致
    • ✅ マンティコア: 20 以上の全文演算子。パーコレート検索 (逆検索)。
    • ❌ Meilisearch: 非常にシンプル: AND およびフレーズ検索。パーコレート検索はありません。
  • 検索の関連性
    • ✅ Manticore は、実証済みの古典的なランキング アルゴリズム (BM25、BM15) を採用しています。関連性はベンチマークで証明されています。 7 つのビルトイン ランカーと20 以上のランキング要素を持つカスタム ランカー。
    • ❌ Meilisearch は検索の関連性が高いと主張していますが、検証のための公開ベンチマークがありません。 6つのランキングルール
  • 保管所
    • ✅ Manticore: 小規模/中規模のデータセット用の独自の行単位ストレージ、大規模なデータセットに適した低 RAM 要件の独自の列型ストレージ
    • ❌ Meilisearch: LMDBとその長所、短所、および結果のすべて: たとえば、9.1 MB のデータセットに 205 GB の仮想メモリが必要というのは奇妙に思えます。
  • インデックスのサイズとデータの読み込み
    • ✅ Manticore は、列単位および行単位のインデックス方法で大規模なデータセットに対応します。 MySQL、PostgreSQL、MS SQL、および ODBC、XML、CSV をサポートするその他のデータベースからデータを簡単に同期できます。真のリアルタイムのトランザクション挿入、置換、および削除。バイナリログ。インプレース属性値の更新。
    • ❌ Meilisearch は大規模なデータセットを処理するのが難しく、ドキュメントの読み込み中にパフォーマンスが低下します。 CSV と JSON をアップロードできます。ドキュメントの非同期追加のみ。インプレース更新はありません。
  • スキーマ
    • ✅ マンティコア: 自動スキーマ。自動識別。すべての属性は、デフォルトでフィルター可能、ソート可能、およびグループ化可能です。
    • ❌ Meilisearch: 自動スキーマ。 ID はドキュメントから自動的に取得できます。すべてのフィールドはデフォルトで全文検索可能ですが、属性はフィルタリングまたはソートできません。完全な再索引付けを避けるために、データを索引にロードする前にスキーマを決定する必要があります。
  • 検索パフォーマンス
    • ✅ Manticore は検索パフォーマンスで Meilisearch を上回っています。
    • ❌ Meilisearch は、高速でスケーラブルな検索機能を必要とするアプリケーションにはあまり適していません。
  • 高可用性
    • ✅ Manticore: レプリケーション、ミラーリングによるリモート エージェントをサポートする分散テーブル、およびいくつかの HA 戦略。
    • ❌ Meilisearch: レプリケーションなし、分散検索なし、ミラーリングなし。
  • タイプミス耐性
    • ✅ Meilisearch は入力ミスの許容度を高めます。
    • ❌ Manticore は入力ミスを許容できますが、アプリでより多くの労力を必要とします。
  • 検索プレビュー
    • ✅ Meilisearch には、インスタンス内のデータを検索するための組み込み UI である便利な検索プレビューがあります。
    • ❌ マンティコアにはこの機能がありません。
  • トークン化
    • ✅ Manticore: 非常に柔軟なトークン化: トークン文字、混合文字、無視された文字、正規表現のトークン化規則など、ワードフォーム、ストップワード、同義語、トークン化プラグインを作成するオプション、ステマーとレンマタイザーに基づくさまざまな言語の形態学。
    • ❌ Meilisearch: トークナイザーは言語に依存します: ほとんどの言語の Unicode セグメンター、中国語、日本語、ヘブライ語、およびタイ語の特定のトークナイザー。同義語。ストップワード。
  • 認証
    • ✅ Meilisearch: 組み込み認証。
    • ❌ Manticore: 組み込み認証なし。
  • インターフェース
    • ✅ Manticore: SQL ファーストで、MySQL クライアントを使用して接続できます。 HTTP JSON インターフェイス。非常に短い応答時間のバイナリ インターフェイス。クライアント: PHP、Python、JavaScript、Java、C#、Elixir、Golang。
    • ❌ Meilisearch: HTTP JSON インターフェイス。クライアント: JavaScript、Python、PHP、Java、Ruby、Golang、C#、Rust、Swift、Dart。
  • ユースケース
    • ✅ Manticore: ログ検索、e コマース プラットフォーム、コンテンツの豊富な Web サイト、エンタープライズ アプリケーション。
    • ❌ Meilisearch: データと検索要件が限られている小規模プロジェクト。

ユースケース

マンティコア検索のユースケース

  1. e コマース プラットフォーム: Manticore Search は、大規模な製品カタログを効率的に管理し、高度なファセット機能を使用して顧客に関連する検索結果を提供できます。これにより、コンバージョン率が向上し、全体的なショッピング エクスペリエンスが向上するため、e コマース プラットフォームで非常に人気のある機能となっています。
  2. コンテンツが豊富な Web サイト: Manticore Search は、ニュース サイト、ブログ、ナレッジ ベースなどの広範なコンテンツ ライブラリをインデックス化および検索できます。適切な全文ランキングにより、ユーザーは必要な情報を迅速かつ効果的に見つけられるようになり、ユーザー エンゲージメントの向上に貢献します。
  3. エンタープライズ アプリケーション: Manticore Search のスケーラビリティと高度な検索機能は、顧客関係管理 (CRM) システム、ドキュメント管理システム、イントラネット ポータルなど、正確で効率的な検索機能が重要となる大規模なエンタープライズ アプリケーションに最適です。
  4. ログ検索: Manticore Search は、膨大なログを効率的に処理および検索できるため、ログの検索に最適です。その速度とパフォーマンスにより、ログの分析と監視に最適です。

Meilisearch のユースケース

小規模プロジェクト: Meilisearch の軽量性と導入の容易さは、小規模な e コマース、個人 Web サイト、ローカル ディレクトリ、単純な Web アプリケーションなど、データと検索の要件が限られている小規模プロジェクトに適しています。高度な検索機能とスケーラビリティは重要な要素ではありません。

結論

プロジェクトの検索エンジンを選択するときは、検索の関連性、スケーラビリティ、パフォーマンスなどの要因を考慮することが重要です。 Manticore Search は、データセットのサイズに関係なく、最適な検索パフォーマンスと関連性を保証する、さまざまなアプリケーションやユース ケースに対する優れた選択肢として際立っています。その高度な検索および分析機能により、高性能の検索機能を必要とするプロジェクトにとって信頼できる選択肢となります。


Meilisearch は、高度な検索機能とスケーラビリティが重要な要素ではない小規模なプロジェクトに適しています。


最終的に、Manticore Search と Meilisearch のどちらを選択するかは、特定のニーズとプロジェクトの要件によって異なります。


こちらにも掲載。