非常に大きな結果セットの代表的なフィルタリング

トピック作成者:ks-solruserml-bot (2024/06/20 15:25 投稿)
7
CloseClose

(The bot translated the original post https://lists.apache.org/thread/16x75r9f2qrpg1osbn3jfj9f4vhz37c7 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

非常に大きな結果セットの代表的なフィルタリングについて

フィールド値に基づいて結果を統合するためにcollapseクエリパーサーを使用し、他の多くのフィールドにもファセットを適用しています。collapseフィールドとファセットフィールドにはすべてdocValues=trueが設定されています。非常に大きな(数百万件のドキュメント)結果セットに対しては、ヒープ使用量が増えすぎて、結果としてGC(ガベージコレクション)が問題になります。ファセット対象となるドキュメントの数を減らしながらも、全体の結果セットを「代表する」ファセットを表示する方法を模索しています。

フィルタクエリのようなものが明らかな解決策のように思えますが、どのようなものが良いのでしょうか?最も関連性の高い結果を誤って除外してしまいたくありません。

上位N件の結果に対してのみファセットを適用する方法はありますか?

どんなヒントでも感謝します。

--
Jeremy Buckley

返信投稿者:ks-solruserml-bot (2024/06/20 15:25 投稿)

あなたが高カーディナリティのフィールドでコラプス(集約)を行っているか、高カーディナリティのフィールドでファセットを適用しているように思われます。問題の大きさを把握するために、フィールドのカーディナリティを説明していただけますか?

Joel Bernstein
http://joelsolr.blogspot.com/

返信投稿者:ks-solruserml-bot (2024/06/20 15:29 投稿)

コレクション内のドキュメントの数は約9000万件です。コラプスフィールドには約3000万の異なる値があるので、これは高カーディナリティに該当すると思います。以前は結果グルーピングを使用していましたが、パフォーマンス向上のためにコラプスに切り替えました。

ファセットフィールドはより混在しており、5~10のフィールドがあり、異なる値の数は約12から約25万までの範囲です。

返信投稿者:ks-solruserml-bot (2024/06/20 15:29 投稿)

3000万の異なる値に対してコラプスを行うと、確実にメモリ問題が発生します。結果セットが増えるとヒープが増加するということは、おそらく新しいバージョンのSolrを使用しており、これがハッシュマップにコラプスするためです。古いバージョンのSolrでは、3000万の長さの配列にコラプスしており、小さな結果セットでもメモリが爆発する可能性がありました。

良好なパフォーマンスを得るためには、シャーディングが必要になると思います。SolrCloudを使用すると、コラプスキーに基づいてシャードを作成できます(ドキュメントルーティングを参照)。これにより、同じコラプスキーを持つすべてのドキュメントが同じシャードに送られます。そして、シャードされたコレクションでコラプスクエリを実行します。

Joel Bernstein
http://joelsolr.blogspot.com/

返信投稿者:ks-solruserml-bot (2024/06/20 15:30 投稿)

ありがとう、Joel。それが私たちがしていることです。私たちは4つのシャードを持ち、コラプスキーでシャーディングしています。結果セットが比較的小さい場合(サブセカンド)、パフォーマンスは問題ありません。私は常にこのことが真実であるようにする最良の方法を本当に探しています。

返信投稿者:ks-solruserml-bot (2024/06/20 15:30 投稿)

うーん、それは難しい問題ですね。結果セットを小さく保つことなく、結果を失わないようにするのは難しいです。私には答えがありませんが、すでにおっしゃったようにクエリをある程度制限する方法がありますね。

Joel Bernstein
http://joelsolr.blogspot.com/

返信投稿者:ks-solruserml-bot (2024/06/20 15:30 投稿)

各コラプスされたグループの「トップドキュメント」をスコアに基づいて決定していますか?もし使用ケースが静的なフィールドで「トップドキュメント」を決定する場合、管理可能な数の値がある場合、他の選択肢があります。一部の使用ケースでは、クリエイティブなfqパラメータを使用してドメインを「プレフィルタリング」することが許容される場合があります。これは、あなたの「コラプス」が静的フィールドによって優先順位が決定された「重複排除」の一種であると見なされる場合に機能しますが、完全にコラプスされていないドメイン全体を検索する必要がある場合には不可能です。

Michael

返信投稿者:ks-solruserml-bot (2024/06/20 15:30 投稿)

ありがとうございます、Michael.

この方法でうまくいくと思いますし、私が進む方向でもあります。私たちは重複排除のためにコラプスしています。

私たちは完全にコラプスされていないドメイン全体を検索する必要がありますが、40万件の結果を見る必要がある人は誰もいないと思いますし、もし彼らがそのように多くのドキュメントに一致するクエリを入力する愚かさがあるなら、彼らが受け取る結果は当然とも言えます。

したがって、私の戦略は以下の通りです:

  1. クエリがある程度「安全」に見えるかどうかをいくつかのヒューリスティックスに基づいてチェックする。
  2. (1)が失敗した場合、rows=0での検索を実行して結果数のみを取得し、ファセティングやソートは行わない。通常、これはかなり高速です。
  3. (2)で返された件数があるしきい値を超える場合、完全なファセット検索を実行する前に追加のフィルタクエリを追加する。

皆さん、ありがとうございました!

トピックへ返信するには、ログインが必要です。

KandaSearch

Copyright © 2006-2024 RONDHUIT Co, Ltd. All Rights Reserved.

投稿の削除

この投稿を削除します。よろしいですか?