問題タブ [elasticsearch-5]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
elasticsearch - ngram を使用して、検索パターン以上の最小文字をテキスト内で検索する
エラスティック サーバーにテキストのインデックスがあります。次のような ngram トークナイザーを実装しました。
私のデータが
「こんにちは美しい世界エル」
クエリ一致「Hell」を配置すると、最初の単語 (Hello) のみが検索され、ell という単語は検索されないため、基本的に、データ内で検索パターンを検索するためだけに検索パターンを「破る」ことは望ましくありません。は(4文字で、以下ではありません)
ありがとうございました
elasticsearch - ファジー検索を使用した Elasticsearch パーコレート クエリ
最近パーコレート クエリに出会いましたが、あいまい検索オプションと一緒に使用できるかどうか疑問に思っています。リンクにある例に従っていますが、タイプミスがあると一致しないことに気付いたので、あいまい検索を使用してこれを修正する方法があるかどうか疑問に思っています。
ruby-on-rails - Elasticsearch-rails で ingest-attachment プラグインをどのように使用しますか?
私は以前、現在非推奨となっている mapper-attachments プラグインを使用していましたが、これは通常のインデックス作成と一緒に使用するのがかなり簡単でした。ingest-attachment がそれに取って代わり、パイプラインなどが必要になったため、これを適切に使用する方法がわかりにくくなっています。
という名前のモデルがMedia
ありfile
、base64 でエンコードされたファイルを含むフィールドがあるとします。そのファイルには次のマッピングがあります。
curl を介して添付パイプラインを作成しました。
現在、プラグインを介してMedia.last.__elasticsearch__.index_document
実際のレコードと一緒にレコードをインデックス化するには、以前はシンプルで十分でした。file
mapper-attachments
ingest-attachment
パイプラインとelasticsearch-rails
宝石を使用してこれを行う方法がわかりません。
curl を介して次の PUT を実行できます。
これにより、エンコードされたファイルがインデックス化されますが、明らかに、モデルの残りのデータはインデックス化されません (または、以前にインデックス化されていた場合は完全に上書きされます)。curl コマンドでファイルとともにすべてのモデル属性を含める必要はありません。これを行うためのより良い方法またはより簡単な方法はありますか? パイプラインなしで完全にオフになっていて、取り込みが機能するはずですか?
elasticsearch - ngram と空白のアナライザーを使用して単語の一部を強調表示する
次のデータを含むelasticsearchインデックスがあります。
「Aチーム」(例)
私のインデックス設定は次のとおりです。
私が検索するとき:
ハイライト結果が得られることを期待しています:
しかし、私はハイライトをまったく取得しません。
検索に空白を使用し、インデックス作成に ngram を使用する理由は、検索フェーズで検索している単語を分割したくないためです。たとえば、「Team」を検索している場合、「Tea」、「eam」、「」が見つかります。チーム"
ありがとうございました
elasticsearch - Elasticsearch Aggregation: 親ごとの最新の子の合計
の合計を示す のヒストグラムを生成したいと思いorder
ます。order_revision
price
quantity
次の集計は基本的に機能しますが、既存のすべてのリビジョンの合計を返します。
最終バージョンでは、すべての注文の最新リビジョン (最上位/最新) のquantity
フィールドの合計のみを返す必要があります。グループ化を行い、最新の子のみを選択するような集計を作成する方法が完全にはわかりません。また、この親子構造がこのデータをモデル化するのに最適かどうかもわかりません。timestamp
order_id
elasticsearch - postman を使用してインデックスを作成中に Elasticsearch でエラーが発生する
ubuntu 14.04 に Elasticsearch 5.1 をインストールしました。インデックスの作成、インデックスの削除など、Elasticsearch でいくつかの操作を実行しました。その後、Kibana 5.1 をインストールしました。ここで、postman (localhost:9200/my_index with PUT) を使用して、elasticsearch に新しいインデックスを作成したいと考えています。しかし、私はこのエラーが発生しています。
country
インデックスまたはタイプとして使用したことを覚えています。しかし、その後、elasticsearch と kibana をパージしました (それらに関連するディレクトリも削除しました)。両方再インストール。しかし、まだこのエラーが発生しています。誰かが解決策を知っていれば、それは高く評価されます。
問題を解決するために必要なクエリの出力を次に示します。
ローカルホストを取得:9200/_mapping
{ ".kibana": { "mappings": { "server": { "properties": { "uuid": { "type": "keyword" } } }, "config": { "properties": { "buildNum" ": { "タイプ": "キーワード" } } } } }
(取得) localhost:9200/_cat/indices?v
[ { "health": "yellow", "status": "open", "index": ".kibana", "uuid": "O_ORG0ONQNCEe8JU_C0SKQ", "pri": "1", "rep": "1" , "docs.count": "1", "docs.deleted": "0", "store.size": "3.1kb", "pri.store.size": "3.1kb" } ]
(取得) ローカルホスト:9200/国
{ "error": { "root_cause": [ { "type": "index_not_found_exception", "reason": "そのようなインデックスはありません", "resource.type": "index_or_alias", "resource.id": "country", "index_uuid": " na ", "index": "country" } ], "type": "index_not_found_exception", "reason": "no such index", "resource.type": "index_or_alias", "resource.id ": "country", "index_uuid": " na ", "index": "country" }, "status": 404 }
elasticsearch - kibana がサーバーの Elasticsearch インデックスに接続できない - ECONNREFUSED
サーバーXX.XXX.XXX.XXX:9200など、インデックスを持つelasticsearchサーバーを実行しています。
サーバー ES クラスター XX.XXX.XXX.XXX:9200 にインデックスがあり、localhost:5601 (Kibana) でダッシュボードを作成しようとしています。
私のkibana.ymlには、次の構成があります。
Elasticsearch.yml には、次の構成があります。
しかし、 kibana.yml を実行すると、次のエラーが発生します。
connect ECONNREFUSED http://XX.XXX.XXX.XXX:9200 http://XX.XXX.XXX.XXX:9200で ElasticSearch に接続できません
ESのサーバーインデックスでキバナを起動して実行するために、ここでどこが間違っているのか誰か教えてもらえますか?
elasticsearch - ファセット検索のポストフィルターとグローバル集計の違いは何ですか?
検索インターフェースでよくある問題は、選択した結果を返したいが、すべてのドキュメントに関する情報を返したい場合があるということです。(例: 赤いシャツをすべて見たいが、他にどんな色があるか知りたい)。
これは、「ファセット結果」または「ファセット ナビゲーション」と呼ばれることもあります。Elasticsearchリファレンスの例は、理由/方法を説明する上で非常に明確であるため、これをこの質問のベースとして使用しました。
概要/質問: これには、ポスト フィルターまたはグローバル アグリゲーションの両方を使用できるようです。どちらもまったく同じ機能を異なる方法で提供しているようです。私が見ていない利点や欠点があるかもしれませんか?もしそうなら、私はどれを使うべきですか?
リファレンス ガイドの例に基づいて、いくつかのドキュメントと両方のタイプのメソッドを使用したクエリを含む完全な例を以下に示します。
オプション 1: ポストフィルター
Elasticsearch リファレンスの例を参照してください
できることは、元のクエリでより多くの結果を取得することです。そのため、これらの結果を「集計」し、後で実際の結果をフィルター処理できます。
例はそれを説明する上で非常に明確です:
ただし、他の色の Gucci シャツが何枚あるかをユーザーに伝えたい場合もあります。color フィールドに用語集計を追加するだけでは、クエリが Gucci の赤いシャツのみを返すため、赤色のみが返されます。
代わりに、集計中にすべての色のシャツを含めてから、検索結果にのみ色フィルターを適用します。
これが以下のコード例でどのように見えるかを参照してください。
これに関する問題は、キャッシュを使用できないことです。これは、(5.1 ではまだ利用できません)elasticsearch ガイドで次のように警告されています。
パフォーマンスに関する考慮事項 post_filter は、検索結果と集計を区別してフィルター処理する必要がある場合にのみ使用してください。通常の検索に post_filter を使用することがあります。
これをしないでください!post_filter の性質上、クエリの後に実行されるため、フィルタリングによるパフォーマンス上の利点 (キャッシュなど) は完全に失われます。
post_filter は、集計と組み合わせてのみ使用し、差分フィルタリングが必要な場合にのみ使用してください。
ただし、別のオプションがあります。
オプション 2: グローバル集計
検索クエリの影響を受けない集計を行う方法があります。したがって、たくさん取得して集計してからフィルター処理する代わりに、フィルター処理された結果を取得するだけで、すべての集計を行います。リファレンスを見てみよう
まったく同じ結果が得られます。このためのキャッシュに関する警告は読みませんでしたが、最終的にはほぼ同じ量の作業を行う必要があるようです。それが唯一の省略かもしれません。
サブ集計が必要なため、少し複雑です ( と を同じ「レベル」にすることはできませんglobal
) filter
。
これを使用したクエリについて私が読んだ唯一の不満は、複数のアイテムに対してこれを行う必要がある場合は、自分で繰り返す必要があるかもしれないということです。結局、ほとんどのクエリを生成できるので、私のユースケースでは自分自身を繰り返すことはそれほど問題ではなく、これを「キャッシュを使用できない」と同等の問題とは実際には考えていません。
質問
両方の機能が少なくとも重複しているか、まったく同じ機能を提供しているようです。これは私を困惑させます。それとは別に、どちらにも私が見たことのない利点があるかどうか、そしてここにベストプラクティスがあるかどうかを知りたいです?
例
これは主にpost-filter リファレンス ページからのものですが、グローバル フィルタークエリを追加しました。
マッピングとドキュメント
現在、すべての赤のグッチ シャツ (アイテム 1 と 3)、これら 2 シャツのシャツの種類 (スリムとノーマル)、グッチの色 (赤と青) をリクエストしています。
最初に、ポスト フィルター: すべてのシャツを取得し、赤いグッチ シャツのモデルとグッチ シャツの色 (すべての色) を集約し、赤いグッチ シャツのポスト フィルターを使用してそれらのみを結果として表示します: (これは、可能な限り明確なポストフィルターの適用に近づけようとするためです。)
また、すべての赤いグッチ シャツ (元のクエリ) を取得し、モデル (すべての赤いグッチ シャツ) と色 (すべてのグッチ シャツ) のグローバル集計を行うこともできます。
両方とも同じ情報を返します。サブ集計によって追加のレベルが導入されたため、2 番目の情報のみが異なります。2 番目のクエリはもう少し複雑に見えますが、これはそれほど問題ではないと思います。実際のクエリはコードによって生成されますが、おそらくもっと複雑であり、それは優れたクエリである必要があります。