Algoliaについて思うこと（vs Solr & Elasticsearch）

BY admin
|
2016/06/01 Doug Turnbull
Category: Lucene

Algolia のあるブログ投稿で不機嫌になり、Algolia の Julien Lemoine CTO と Search Disco のエピソードを持ってから、私はそのソリューションに魅了されています。

Algolia, so hot now!

Algolia では、私たちがみな即時検索 (aka search-as-you-type) を求めることを前提に置いています。 そこで、彼らは非常に優れた、ホストされたインスタント検索を構築しました。 インスタント検索で行いたいことはすべてそこにあります。 クエリ理解に関するこの素晴らしい投稿を読んでみてください

  • タイポ耐性、”Doug Trunbull”
  • プレフィックス検索 “Doug Turn”
  • タイポ耐性を持つプレフィックス “Doug Trun”
  • 複号化（これはタイポ耐性である場合があります） DougTrun
  • クエリー時レンマタイザ、その他いろいろ……。

検索の代わりにステロイドのオートコンプリートがあるようなものです。 これを Elasticsearch や Solr よりも健全なデフォルトのランキングと組み合わせると、かなり魅力的な製品になります。 私は、Lucene における関連性についての本を書きました。 Solr や Elasticsearch で構築された多くの魅力的なソリューションを見てきたので、私は Lucene に非常に偏っています。

Lucene ベースの検索について学んだことの1つは、良いチームがいれば、どんな検索的なものでも構築できることです。 しかし、それにはチームが必要です。 Lucene ベースの検索は、あなたのソリューションに対して「箱から出してすぐに」うまく機能するようなものではありません。 Elasticsearchがどんなに簡単にしてくれたとしても、Luceneベースの検索はフレームワークであって、ソリューションではありません。 検索に特化した素晴らしいデータ構造のセットで、比較的簡単に組み立てることができ、Your Thing™を実現することができます。 たとえ、Your Thing™ が、インデックスがディスクに保存される方法と同じくらい低レベルの詳細を変更することを意味したとしてもです！

別の言い方をすると、Elasticsearch で Algolia を構築できる（または十分に近い）、ということです。 Algolia で Elasticsearch を構築することはできないのです。 Algoliaは特定の問題にフォーカスしています。 オープンソースのカスタマイズ性、拡張性は犠牲になります。 さらに別の言い方をすれば、検索ソリューションをWebアプリに例えることができます。 アルゴリアは、Wixのようなサイトビルダーでサイトを構築するようなものです。 Lucene は、開発者が背後にいる独自の Web アプリを構築するようなもので、関連するすべての低レベルの考慮事項、厄介なこと、しかしパワーもあります。

例として、Algolia と Elasticsearch のパフォーマンス比較を挙げます。 Algolia のテストでは、Algolia は最大 200 倍のパフォーマンス向上を主張しています。 平均すると、10～20 倍のパフォーマンス向上が見られます (それでも印象的です)。 しかし、アルゴリアはElasticsearchのインスタント検索において、ファジー・クエリとプリフィックス・クエリという最小公倍数を選択した。 Elasticsearchに書かれている通りです。 Elasticsearch: The Definitive Guideに書かれているように、速度を飛躍的に向上させるもう一つの一般的なアプローチは、ngramsを使うことです。 基本的には、クエリ時のファジーな作業を避け、それを処理できる巨大なデータ構造を構築します。

さて、ngram には独自の問題があります。 インデックスが大きくなってしまうのです。 しかし、短いテキストを多く含む 200 万のドキュメントの場合、それほどインデックスを肥大化させないかもしれません。 また、パフォーマンスも何桁も向上するのではないでしょうか。 もしインデックスの肥大化が問題になれば、より大きなサイズのngramをより少なく生成すればよいのです。 また、キャッシュも考慮しなければならない。 どちらのソリューションも、キー入力のクエリごとに結果をキャッシュしているはずです。

インデックスに配置された用語を逆にして、サフィックスクエリで以前のタイプミスを検出することもできます。 あるいは、ファジー・クエリと ngram を同時に使用してエキゾチックなことを行うかもしれません。 タイポに特化した Lucene クエリを書くこともできるかもしれません。 このパワーを見てください！

しかし、ポイントは、問題をどのように解決するかについて考え始めたということです。 アルゴリアはすでにソリューションを構築しています! なぜ、彼らと一緒に実行しないのですか？

  • Turn-key はしばしばロックインになる可能性があります。 ホスティングされた検索ソリューション（およびデータベース）が買収され、新しいオーナー（FoundationDB の場合は Apple）が既存のビジネスをサポートすることに興味を示さなかったという例があります。 Algolia のソリューションは、特定の文字列のマッチングに強く焦点を合わせています。 Lucene の関連性へのアプローチは、コンテンツの特徴としてより抽象的に用語に焦点を当て、特徴の類似性システムとして TF*IDF を使用します (私たちの本は、主にこの用語で関連性について論じています)。 特定のクエリ言語を実装する必要があります。 専門家と一般人の間の用語を明示的にマッピングする必要がある。 Learning-to-rank を行いたい。 統制された語彙を使用し、セマンティック検索を構築したい。 特定のGeoに関する懸念がある。 これらはすべて Solr/ES に組み込むことができる機能であり、Algolia が提供するものに縛られています。
  • 検索エンジンの動作を深く操作したい。 これは Lucene のスイートスポットの大きな部分です。

しかし、私が Algolia

  • を強く検討する理由がいくつかあります。 Algolia は、箱から出してもかなりうまく機能します。 テキストと、いくつかの地理的なサポートと人気のような数値の両方を含むことができる、ランキングの構成可能性の良いレベルを持っています。 Algolia のアプローチは、「バナナ」を検索してバナナでマッチングする必要があるような場合に最適です。 Algolia は、”minion fruit” と入力し、バナナを期待するユーザーには意味がないかもしれません。
  • タイプミスをサポートする必要があります。 これに対する Lucene のソリューションは厄介です。

Algolia のマーケティングで、私が同意しないものをいくつか挙げます：

  • Algolia は、Elasticsearch をホストするのは難しいだろうと指摘したがります。 Bonsai や Elastic Cloud のようなオプションでは、これはほとんど当てはまりません。 良い ES ホストを使えば、基本的に、他のサービスと同様に簡単に作業できる、優れた「クラウド上の API」を手に入れることができます。 それは、ビッグ データ解析と「ビッグ データ検索」（それが何を意味するかは不明）においてのみ優れています。 文字列ではないもの」を見つけるという精神で、私は反対します。 ただ、作業が必要であり、検索ソリューションについて何が特別なのかを理解する必要があります。
  • Algolia は、すべてがインスタント検索になることを望んでいます。 しかし、私の経験では、検索エクスペリエンスの大部分 (Algolia によって駆動される多くでさえ) は、最初にオートコンプリートでキーワードを選択し、次にキーワード検索を行います。 これはまだ Lucene の検索スイートスポットにあります。
  • Algolia が提供するベンチマークを信じますが、Elasticsearch でより速いインスタント検索戦略を試していないことが指摘されています。 私たちは彼らのベンチマークを自分たちで再現することができません。 Algoliaは信頼できそうですが、独自にテストできればと思います。 また、より新しい Elasticsearch バージョンに対して再実行することを望みます。

But Algolia points out important weaknesses in Lucene’s relevance model

  • Typos and fuzzy matching: 世間が誤字許容のあるインスタント検索を求めているという程度で、ルセンベース検索はなかなかうまくいかないようですね。 また、（ベンチマークを再現できませんが）Algolia の集中型ソリューションより遅いと思います。
  • Elasticsearch/Solr の関連性のデフォルトは調整しにくいです。 Algolia が正しく指摘するように、dismax ランキング関数はかなり紛らわしい結果をもたらします。 その現象については、こちらで書いています。 これらのデフォルトから離れることはできますし、そうすべきですが、検索が箱から出してももっと意味があるものであってほしいと思います。 Algolia のものはより高レベルで、ビジネスと開発者間の共通の理解を生み出すことに重点を置いているように感じます。 これが、私たちがQuepidを構築した大きな理由の1つです。 それでも、Solr/ESのすべてのオプションを使用して、ブール型クエリ、関数クエリ、およびその他について話し始めると、ビジネスから無表情で見つめられるでしょう。 しかし、あなたは、それがあなたのニーズを満たすと確信する必要があります。

    私たちの関連性コンサルティングでは、どのソリューションがあなたにとって正しいかを見極めるお手伝いをしたいと思います。 どのソリューション（Solr、Elasticsearch、Algolia）があなたのニーズに合っているかを議論するために、ぜひご連絡ください！

    .