1

求職者と求人情報があります。特定のリストにどの候補者が適格かを判断しようとしています。ES では、すべてのリストが既にインデックス化されています。私がこれを行うことができると私が見る2つの方法は次のとおりです。

  1. ES のすべての候補者にインデックスを付け、リストのパラメーターに基づいてクエリを作成して、資格のある候補者を検索/フィルター処理し、それらを結果として返します。
  2. パーコレート機能を使用して、候補ごとにパーコレート クエリを作成し、リストのデータを候補パーコレーター インデックスに対して実行して、一致する候補を見つけます。

大規模 (数百万レコード) でより効率的でパフォーマンスが高いのはどれですか? パーコレーターがどのように実装されているかを完全には理解していません (実際に実装を説明している記事は見つかりませんでした)。私の懸念は、パーコレーターを使用すると、実際にはリストごとに候補ごとに 1 つのクエリを実行することになり、非常に非効率的であるということです。

4

1 に答える 1

0

Percolator では、「クエリ」インデックスに対して検索クエリを実行しています。 したがって、あなたの場合、Elasticsearch によって実行される相対的な「作業」は、両方の場合で似ています。

C: Number of Candidates CQ: Number of Candidate-Job-Search-Alert-Queries

（あなたの説明に基づいて、あなたのシステムのC = CQ）

オプション 1。すべての候補者にインデックスを付けます。新しいジョブが追加されるたびに、候補インデックスに対して検索を実行して、一致するジョブの特性を探します。( Cレコードを検索)

オプション 2。求職者ごとに 1 つの求人検索アラートクエリを.percolatorインデックスに登録します。新しい求人が追加されるたびに、Percolate API を使用して、一致する Candidate-Job-Search-Alert-Queries を識別します。( CQクエリレコードを検索)

パフォーマンス/スケーラビリティの観点から、より大きな懸念は、パーコレーターが.percolatorインデックス全体をメモリにロードする必要があることです。

機能の観点から、Percolator は、必要になる可能性のある特定のクエリ タイプを制限します (これは、オプション 1 を支持する投票になります)。

ユーザーが保存した検索などの状況に陥った場合CQ << C 、Percolator アプローチは、候補インデックス全体をクエリする必要がある場合よりもパフォーマンスが優れている可能性が高くなります。

于 2015-11-05T16:38:26.533 に答える