アプリケーションやウェブサイトとシームレスに統合するために設計された超高速検索エンジン Meilisearch が、最近そのハイブリッド検索機能で注目を集めています。検索エンジン市場がAI機能を搭載して進化し続ける中、開発者たちは本番環境での Meilisearch の使用経験を共有し、Typesense や Elasticsearch、そして Orama のような新興ソリューションと比較しています。
本番環境での準備状況とパフォーマンス
Meilisearch はバージョン1.0以降、本番環境での使用が可能となり、数百万のドキュメントを処理する実装に成功した開発者が複数報告しています。あるユーザーは700万の記事コーパスに対して良好な結果を得たと述べ、別のユーザーは月額8ドルの Hetzner インスタンスで100万レコードを処理する簡単なセットアップについて言及しました。しかし、高可用性オプションについては疑問が残っており、冗長性のための唯一の解決策は複数の同期インスタンスを実行することであるとの指摘もあります。
この検索エンジンのメモリ使用量については議論が起きており、小規模なインスタンスでも高いメモリ消費（3GB以上）を観察するユーザーもいます。Meilisearch チームのメンバーはこの動作について次のように説明しています：
「実際、Meilisearch はキー・バリューストレージにLMDB（メモリマップされている）を使用しているため、設計上利用可能なRAMを使用します。これはバグではなく機能です。素晴らしいことに、どのプロセスにメモリを割り当てるかを選択するのはOSです。」
この設計上の選択は、Meilisearch がパフォーマンスのために利用可能なシステムメモリを活用する一方で、プロセス間のメモリ割り当てを管理するためにオペレーティングシステムに依存していることを意味します。
ハイブリッド検索の実装
議論の重要なトピックの一つは、Meilisearch のハイブリッド検索へのアプローチで、これは従来の全文検索とセマンティック（ベクトルベース）検索を組み合わせています。この実装は、結果を組み合わせるために相互ランク融合（RRF）を使用する Typesense などの競合他社とは異なります。
会話では、ハイブリッド検索に対するさまざまなアプローチ間の緊張が明らかになり、あるコメンター（後に Meilisearch チームのメンバーと判明）は、Typesense の融合検索方法を「ほとんど役に立たない、なぜならどちらか一方の検索戦略が常にひどい結果をもたらすから」と批判しました。これに対して Typesense の代表者は、彼らのアプローチが十分に研究され、学術論文で文書化されていると反論しました。
ハイブリッド検索の実装を検討している開発者に対して、あるコメンターはアドバイスしています：「常に掘り下げるべきことは、ハイブリッド検索ソリューションがどのようにベクター検索インデックスをフィルタリングするかです。これは全く標準化されておらず、見落とされがちですが、'クエリに埋め込みで最も類似したトップX、ただしYカテゴリ内/Z検索語に一致する'を求める場合、それがハイブリッド検索の核心となります。」
Meilisearch の主な機能：
- セマンティック検索とフルテキスト検索を組み合わせたハイブリッド検索
- 入力しながら検索（結果表示は50ミリ秒未満）
- タイプミス許容
- フィルタリングとファセット検索
- ソート機能
- 同義語サポート
- 位置情報検索機能
- 多言語サポート
- API キーによるセキュリティ管理
- マルチテナンシーサポート
- プラグインと SDK を備えた RESTful API
- langchain 統合によるAI対応
インデックス作成速度とドキュメント更新
複数のユーザーが、頻繁に変更されるドキュメントを処理する際の Meilisearch の課題を強調しました。あるユーザーは、ドキュメントが頻繁に変更され、検索結果にそれらの変更をすぐに反映させる必要がある場合、「何時間も保留中のタスクが発生する」と指摘しました。しかし、静的または変更頻度の低いコンテンツについては、Meilisearch はそのパフォーマンスと設定の容易さで称賛を受けました。
Meilisearch チームは、最新リリース（v1.12）での改善点を指摘し、これには「はるかに高速で、並列処理を高度に活用し、ディスク書き込みを削減する新しいインデクサーバージョン」が含まれています。また、コンテンツを主にメモリに保持するのではなくディスクに書き込む「ディスクファースト」アプローチを強調し、これにより即時再起動が可能になり、再インデックスなしでのアップグレードが容易になります。
Meilisearch の代替として挙げられたもの:
- Typesense - 高可用性オプションで注目されている
- Elasticsearch - 従来型のエンタープライズソリューション
- Quickwit - Tantivy ベース（ Datadog に買収された）
- ParadeDB - Postgres 統合型検索
- Orama - コンパクト（2KB未満）なブラウザ/サーバー/エッジソリューション
- Vespa - ハイブリッド検索機能で言及されている
代替ソリューション
議論では、開発者が検討している Meilisearch の代替案がいくつか明らかになりました。Typesense は特に高可用性シナリオで頻繁に言及されました。他にも Quickwit や ParadeDB などの Tantivy ベースのソリューションが挙げられましたが、Quickwit が Datadog に買収された後の将来性については懸念が示されました。新しい参入者である Orama は、そのコンパクトなサイズ（2KB未満）と、ブラウザ、サーバー、またはエッジネットワークで実行できる全文検索、ベクトル検索、およびハイブリッド検索のサポートが強調されました。
全文検索とベクトル埋め込みを組み合わせたいと考えている人には、Elasticsearch、Vespa、および Typesense が提案されましたが、実装の品質と使いやすさについては意見が分かれました。
検索技術がAI機能とともに進化し続ける中、Meilisearch は後方互換性を維持しながらパフォーマンスを向上させるアプローチにより、この分野での有力候補となっていますが、開発者は検索ソリューションを選択する際に、ドキュメントの更新頻度、メモリ使用量、および高可用性に関する特定のニーズを慎重に検討する必要があります。
参考：Meilisearch: AI-powered search in GA
 |
|---|
| スタイリッシュな映画検索アプリケーションのインターフェースで、 Meilisearch のような様々な検索テクノロジーがユーザーに関連コンテンツへの効率的なアクセスを支援する様子を示しています |