問題タブ [elasticsearch-7]

simple_query_string接頭辞演算子* とあいまい値を同じ単語で使用~Nすると、接頭辞検索が無効になっているように見えます。

あいまいさを 0 に設定すると、プレフィックスが無効になり、クエリがAbcd*~0プレフィックス検索もあいまいさもなくなることは明らかです。

これはドキュメントに記載されていないため、間違っているかどうかはわかりません。

私はもう試した：

• 演算子の順序を入れ替える: Abcd~2*--_explainこれではあいまいなバリエーションが導入されますが、前置演算子は省略されます
• 優先順位に括弧を使用: (Abcd*)~2--_explainこれでは接頭辞を使用しますが、あいまい演算子^{1を省略します}
• 単語の複製: (Abcd* Abcd~2)-- これは機能します。両方の効果の構成ではなく、両方のクエリの再結合を明らかに示しています²。

¹~2句がない (引用符がない) ため、この場合は SLOP 演算子として解釈されるべきではないと想定しています。

²これらの効果を合成すると、可能なバリエーションが多すぎる可能性があることは理解できます。ファジーは 50 のバリエーションを追加し、それらのそれぞれについてプレフィックス検索を行います。

200 万のドキュメントのインデックスを作成しましたが、一致するすべてのドキュメント ID を一度に返そうとしています。私はPHPクライアントを使用しています。

私のマッピングは次のとおりです。

私のクエリ文字列は次のとおりです。

私のプロファイル API の出力は次のとおりです。

目標は、一致するすべてのドキュメントを一度に取得することです。ドキュメント ID のみが必要なので (指定された用語がドキュメントに存在するかどうかのみを確認します)、index_options をドキュメントとして使用しました。スクロール API については理解していますが、max_result_window を使用したいです。私はシャードを 1 つだけ使用し、レプリカは使用していません。また、検索操作を実行するときにドキュメントのスコアリングを回避しました。

私の質問は次のとおりです。

1. ドキュメント ID のみを取得し、ドキュメントのフェッチ フェーズを回避したいので、ソース フィールドを無効にしました。他のメタデータを回避するために、このリンクに従って "stored_fields": " none ", "docvalue_fields": ["_id"] を試し、フェッチ フェーズを回避しました。ただし、ドキュメントの種類とインデックス名は引き続き表示されます。ドキュメント ID のみを取得し、フェッチ フェーズを回避するために必要なことはありますか?

2. 一致するすべてのドキュメントを取得しているので、スコアリングは私には関係ないので、フィルター句を使用しましたが、以下のプロファイル API の結果でなぜブーストクエリのタイミングが得られるのか疑問に思っていました。しかし、Booleanquery スコアのタイミングがゼロであることにも注意してください!

3. ブール クエリ検索が Lucene インデックスだけでどれくらいの時間を要したかを知るには、ブール クエリによって報告された時間を取るべきですか、それともすべての子 (ターム クエリ) のタイミングを合計する必要がありますか? これらすべての用語クエリのタイミングを追加すると、ブールクエリによって報告されたものよりも高いためです。これについて考えられる理由はありますか？

4. ブールクエリのタイミングのためにコレクターも含める必要がありますか?プロファイル api では、「Lucene は、トラバーサル、スコアリング、および一致するドキュメントのコレクションの調整を担当する「コレクター」を定義することによって機能すると言われています。」. また、「コレクターの時間はクエリの時間とは独立していることに注意してください。それらは独立して計算、結合、および正規化されます! Lucene の実行の性質上、コレクターの時間を「マージ」することは不可能です。クエリ セクションなので、それらは別々の部分に表示されます。」私の理解では、Lucene インデックスの投稿リストを走査してブール クエリ操作を実行するのに役立ちます。この点で私は正しいですか？

5. Elasticsearch でインデックス作成時間を調査するための同様の API はありますか? 設定 API でインデックス作成時間を取得できましたが、プロファイル API に似たものを探していますか?

5.5 から 7.7 への移行では、"index" の "_type" は 1 つだけです。5.5 では、"index" の "_type" が複数あります。現在の構造に従ってデータ構造を変更しています。 Elastic Search 7.7 では、各インデックスに 1 つのタイプがあることを意味します。

今年後半に、エラスティック検索サーバーを 7.7 から 8 にアップグレードします。
また、7.8 の EOL である Java を使用するトランスポート クライアントを使用しており、クライアント側の REST クライアントに移行します。

現在、バージョン 7.7 では単一の「_type」が「index」にマッピングされています。ドキュメントによると、バージョン 8 ではタイプレスになることがわかります。したがって、_type を追加する最良の方法は何ですか、またはタイプの使用を削除する方法はありますか? 7.7 に変更したため、エラスティック サーチ サーバー側でバージョン 8 に変更を加える必要はありません。

ありがとう、
ハリー

Elastic Search バージョン 7.7 では、インデックス内の複数の _types が削除されました。複数のインデックスにわたってクエリを実行する場合は、次の方法で実行しています。

7.7 で、Transport Java API を使用して複数のインデックスからクエリを実行する最良の方法は何ですか?

編集:
1) " user " と " tweet " の 2 つのインデックスがあるとします。インデックス - user と tweet の両方を以下のように検索したいとします。

フィールドの " user " インデックスを {"username" = " Opster "} としてクエリし、フィールドの " tweet " インデックスを {"data" = " some_text "}としてクエリしたい場合

これは可能ですか？

2) 各インデックスはエラスティック検索の個別のパーティションであることは理解していますが、インデックス間の検索はエラスティック検索で内部的にどのように機能しますか?

ありがとう、
ハリー