Elasticsearchオートコンプリートガイド

Opsterチーム

最終更新日:2012/03/18 2021

オプスターチーム

マーチ2021

このガイドを読むことに加えて、Elasticsearchヘルスチェックを実行することをお勧めします。 シャードサイズ、threadpools、メモリ、スナップショット、ディスク透かしなどを分析することで、問題を検出し、Elasticsearchのパフォーマンスを向上させます。Elasticsearchチェックアップは無料で、インストールは必要ありません。

このガイドを読むことに加えて、Elasticsearchで検索パフォーマンスを向上させたい場合は、OpsterのSearch Log Analyzerを実行する必要があります。

Opsterのアナライザを使用すると、遅い検索を簡単に見つけて、システムに追加の負荷を追加する原因を理解することができます。 検索の待ち時間を短縮し、検索のパフォーマンスを向上させる方法について、カスタマイズされた推奨事項が表示されます。 このツールは無料で、実行にはわずか2分かかります。

背景

この記事では、重大なパフォーマンスミスを回避する方法、Elasticsearchのデフォルトソリューションがそれをカットしない理由、および重要な実装上の考慮事項
すべての現代のウェブサイトは、ユーザーエクスペリエンスを向上させるために、検索バーにオートコンプリート機能(入力したときに検索)を備えています(誰も オートコンプリートの全体のポイントは、ユーザーが入力している間に結果の表示を開始することであるため、オートコンプリートは、標準の検索よりも高速であることが不可欠です。 レイテンシが高い場合は、ユーザーエクスペリエンスが不十分になります。

以下は、有名な質問と回答サイトQuoraのオートコンプリート検索の例です。 これはオートコンプリートの良い例です:elasticsearch autoを検索すると、次の投稿が検索バーに表示され始めます。

この画像には空のalt属性があります; そのファイル名はGtQyiRxpwyXg_NmYFLO5mSlG5Zwa-k6a-s2AIi-uP3EsEP8dRql8eR0CrfGZlN_PIcUMU9K-GDZ2WfEASrxgxGSXiE37pzwNNffIcjq-xlBA982DZe8TQJFzYaLl8WojdrdlVNjQ

検索結果には、Elasticsearchの自動スケーリング、自動タグ、および自動補完機能に関する質問があります。 ユーザーはさらにいくつかの文字を入力して検索結果を絞り込むことができます。

Elasticsearch/searchでのオートコンプリートのさまざまなアプローチ

を入力すると、オートコンプリート機能を実装するには、大きく四つの主要なカテゴリに分類される複数の方法があります:

  1. インデックス時間
  2. クエリ時間
  3. 完了サジェスタ
  4. 検索-as-you-typeデータベース

1. 索引時間

場合によっては、オートコンプリートでの接頭辞補完または中置補完が必要になることがあります。 カスタム-アナライザを使用してオートコンプリートの実装を見ることは珍しいことではありません。
この例を続けると、”elasticsearch autocomplete”、”elasticsearch auto-tag”、”elasticsearch auto scaling”、”elasticsearch automatically”で構成されるドキュメントを見ています。 デフォルトのアナライザは、”オートコンプリート”、”自動スケーリング”、および”自動的に”の部分トークンを生成せず、”自動”を検索しても結果は生成されません。
上記の問題を解決するために、公式のES docとsearch time analyzerで説明されているように、edge ngramまたはn-gram tokenizerを使用してElasticsearchのトークンをインデックス化し、オートコンプリート
上記のアプローチでは、文字列比較(hashcodeを使用する)を使用するため、高速であり、インデックス内のトークンは比較的正確ではありません。

2. クエリ時間

オートコンプリートは、マッチクエリをプリフィックスクエリに変更することで実現できます。 一致クエリはトークン(インデックス付き)からトークン(検索クエリトークン)の一致で動作しますが、接頭辞クエリは(名前が示すように)検索トークンで始まるすべ

説明したように、prefix queryは正確なトークン一致ではなく、文字列内の文字一致に基づいており、非常にコストがかかり、多くの文書を取得します。 Elasticsearchは内部的にb+ツリーの種類のデータ構造を使用してトークンを格納します。 逆インデックスで使用されるデータ構造の内部構造と、異なるタイプのクエリがパフォーマンスと結果にどのように影響するかを理解することは役

3. Completion suggester

これは、eコマースやホテル検索サイトなどの検索用語の提案を提供している場合に便利です。 検索バーには、実際の検索結果に表示される候補とは対照的に、クエリ候補が表示され、補完候補が提供する候補のいずれかを選択すると、検索結果が提公式のES文書に記載されているように、それはまだ開発中の使用であり、この例で説明したように検索用語に基づいて検索結果を取得しません。

内部的には、既存の文書に基づいていないユーザーが提案したいトークンにインデックスを付けることによって動作します。

コードサンプル

1. インデックス時間

インデックス定義:

{ "settings": { "analysis": { "filter": { "autocomplete_filter": { "type": "edge_ngram", "min_gram": 1, "max_gram": 10 } }, "analyzer": { "autocomplete": { "type": "custom", "tokenizer": "standard", "filter": } } } }, "mappings": { "properties": { "title": { "type": "text", "analyzer": "autocomplete", "search_analyzer": "standard" :-> note search_analyzer } } }}

検索クエリ:

{ "query": { "match": { "movie_name": { "query": "avengers inf" } } }}

2. クエリ時間

インデックス定義:

{ "mappings": { "properties": { "movie_name": { "type": "text" } } }}

検索クエリ:

{ "query": { "bool": { "should": } }}

4.

と入力したときの検索これは、カスタムアナライザの設定に関する事前知識がなくてもオートコンプリートクエリを容易にすることを目的とした、最近リリースされたデータ型(7.2でリリース)です。 Elasticsearchは、同じテキストのさまざまなトークン(エッジn-gram、帯状疱疹)を内部的に格納するため、接頭辞と中置の両方の補完に使用できます。 Elasticsearchの高度な機能に精通していない場合は、他の3つのアプローチの場合と同様に便利です。 単純なユースケースで動作させるためにはあまり設定が必要ではなく、コードサンプルと詳細は公式のES docsで入手できます。

パフォーマンスの考慮事項

上記のアプローチはほとんどすべて、検索負荷が軽い小さなデータセットで正常に動作しますが、大量のインデックスが多数の自動提案クエリを取得している場合は、上記のクエリのSLAとパフォーマンスが不可欠です。 次の箇条書きは、お客様のニーズに最も適したアプローチを選択する際に役立ちます:

  • Ngramまたは端のNgramトークンは索引のサイズをかなり増加しま、適用および容量に従って最低および最高のグラムの限界を提供します。 計画は生産の重要な悩みを救う。
  • 空または少数の文字プリフィックスクエリを許可すると、インデックス内のすべてのドキュメントが表示され、クラスタ全体がダウンする可能性が 接頭辞クエリをn番目の用語(いくつかのフィールド)でのみ実行し、接頭辞クエリの最小文字を制限することを常にお勧めします。
  • ESは、入力したテキストをさまざまな形式でトークン化する”search as you type”データ型を提供しました。 これはすべてのユースケースに対処できないES提供のソリューションであるため、ビジネスユースケースに必要なすべてのコーナーケースを確認することをお勧 さらに、前述のように、elasticsearchインデックスストアサイズを増やすことができる複数の形式でフィールドをトークン化します。
  • 補完は、提案のインデックスを個別に提案することを示唆しており、その一部はまだ開発モードであり、検索結果を取得するユースケースに対処していません。
  • インデックス時間のアプローチは、クエリ時間中のオーバーヘッドが少ないため高速ですが、インデックスの再作成、容量計画、ディスクコストの増加など、よ クエリ時間は簡単に実装できますが、検索クエリにはコストがかかります。 これは、ほとんどの場合、ユーザーがそれらのいずれかを選択する必要があり、このトレードオフを理解することは、多くのトラブルシューティングのパフォーマ

その他

ほとんどの場合、ESはオートコンプリートのソリューションを提供していますが、ビジネス固有の要件に対処していないか、大規模システムにパフォーマ ほとんどの場合、ユーザーは最適化されたソリューション(より高性能でフォールトトレラント)を得るために微調整する必要があり、Elasticsearchのパフォーマンスの問題 Opsterはそれらを早期に検出するのに役立ち、それらを効果的にデバッグして防止するためのサポートと必要なツールを提供します。

:

  1. いくつかの洞察を得て、パフォーマンスを向上させるための検索レイテンシの増加に関するOpsterのガイド。
  2. Opster’s guide on how to use search slow logs on how to quickly debug slow search issues迅速に遅い検索の問題をデバッグする方法について

Elasticsearchのパフォーマンスを向上させる

分析を実行する

コメントを残す

メールアドレスが公開されることはありません。