2016-10-29 17 views
0

私はアプリのような筋金入りに取り組んでいます。弾性検索用語大量のユーザーを除外するクエリ

must_not:[{ "用語":{ "swipedusers":[ "USERID1"、 "USERID1"、「ユーザーが以前にスワイプしているプロファイルを排除するために、私はこのような "must_not" クエリを使用しますuserid1 "...]}}]

私はこのアプローチを使用してどのような制限があるのだろうか?これは、swipedusers配列に2000ユーザーIDが含まれている場合にも有効な、スケーラブルなアプローチですか?これに対してよりスケーラブルなアプローチがあれば、私は喜んで知っているでしょう...

+0

PUT /swipes { "settings": { "auto_expand_replicas": "0-all" } } 
の可能性のある重複[IがIDSフィルタまたは一般クエリ句で指定できる値の数の最大限界?](http://stackoverflow.com/questions/26642369/max-limit-on-the -number-of-values-i-can-specify-the -ids-filter-or-general-q) – ChintanShah25

+0

質問はelasticsearchによって強制される厳しい制限に関するものです。私の質問はスケーラビリティと優れた実践に関するものです。 –

答えて

1

良いアプローチがあります!リレーショナルデータベースで行うことができる従来の結合のようなものです...

私はここであなたを説明しようとする可能性がありますが、必要な情報はすべて公式に文書化されています弾性検索ページ:

https://www.elastic.co/guide/en/elasticsearch/reference/5.0/query-dsl-terms-query.html#query-dsl-terms-lookup

最終溶液は2つのインデックス、登録ユーザ用とユーザ毎にスワイプを追跡する別の1つを有するされています。 次に、スワイプごとに現在のユーザースワイプを含むドキュメントを更新する必要があります。ここでは配列に要素を追加する必要があります。これはElasticSearchの別の問題です(AWSマネージドElasticSearchを使用している場合は大きな問題です) ...スクリプトを使用して、あなたのケースではhttps://www.elastic.co/guide/en/elasticsearch/guide/current/partial-updates.html#_using_scripts_to_make_partial_updates

で 詳細情報を解決することができ、クエリは次のようになります:

GET /possible_matches/_search 
{ 
    "query" : { 
     "terms" : { 
      "user" : { 
       "index" : "swiped", 
       "type" : "users", 
       "id" : "current-user-id", 
       "path" : "swipedUserId" 
      } 
     } 
    } 
} 

アカウントに取るべきもう一つはのためのレプリケーション構成でありますスワイプインデックスは、各ノードがそのインデックスで「ジョイン」を実行するため、そのインデックスの完全なコピーをe achノード。これを達成するには、 "auto_expand_replicas"と "0-all"の値を持つインデックスを作成します。

+0

うわー、ありがとう。これはうまくいく。このアプローチでは1つの問題が発生します... ユーザーAがユーザーを検索(スワイプする)したときに、ユーザーBが既に好きだったユーザーをスコアリングしたいのは、一致する可能性が高いからです。ただし、用語の検索で固定IDを指定する必要があります。このidを動的にする方法は、現在照会されているレコードのIDです。たとえば、最初のヒット結果がユーザーcである場合、用語ルックアップでユーザーcのスワイプレコードがチェックされますか? –