進化を続けるデジタル環境において、検索エンジンは、さまざまなプラットフォームで検索機能を強化する上でますます重要な役割を果たしています。人気のある検索エンジンの中で、 MeilisearchとManticore 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 の小さなデータセット ベンチマークは、数値フィールドを含む 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 倍のディスク容量を必要とします。
データ読み込みのパフォーマンスに関しては、次のようになりました。
データの読み込みを完全に完了します。
このテストには、同じ 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 ログを含むデータセットに基づいています。このデータセットのソースは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 が特定の種類のクエリを処理できないことが原因であることに注意してください。その結果、これらのクエリはベンチマーク プロセス中にスキップされました。
小規模プロジェクト: Meilisearch の軽量性と導入の容易さは、小規模な e コマース、個人 Web サイト、ローカル ディレクトリ、単純な Web アプリケーションなど、データと検索の要件が限られている小規模プロジェクトに適しています。高度な検索機能とスケーラビリティは重要な要素ではありません。
プロジェクトの検索エンジンを選択するときは、検索の関連性、スケーラビリティ、パフォーマンスなどの要因を考慮することが重要です。 Manticore Search は、データセットのサイズに関係なく、最適な検索パフォーマンスと関連性を保証する、さまざまなアプリケーションやユース ケースに対する優れた選択肢として際立っています。その高度な検索および分析機能により、高性能の検索機能を必要とするプロジェクトにとって信頼できる選択肢となります。
Meilisearch は、高度な検索機能とスケーラビリティが重要な要素ではない小規模なプロジェクトに適しています。
最終的に、Manticore Search と Meilisearch のどちらを選択するかは、特定のニーズとプロジェクトの要件によって異なります。