こんにちは、Noahさん。

いくつかの注意点があります。クエリの実行時間は結果の数に依存します。あるクエリが他のクエリより遅い場合、その理由を列挙されたドキュメントの数が多いせいにすることができます。
debugQuery 出力でクエリがどのように解析されているかを確認してください。クエリパーサには多くのトリックや落とし穴があります。例えば、なぜ which の後にコロンを置いたのか、Solrにどのように入力したのか、その解釈がどうなっているのかは不明です。
どのバージョンのSolr/Luceneを使用していますか？以前はLuceneに二相イテレーションがなく、冗長な列挙が発生することがありました。

期待通りに動作するのが普通です。仮説を確認するには、{!parent ..}.. と work_id:123 を intersect させることで、fq や + を使用して確認できます。それにより瞬時に結果が得られるはずです。

すべてが正しい場合、大規模なインデックスを実行していて、多くのシャードに分割する必要があるかもしれません。

よろしくお願いします、
Mikhail Khludnev

ご返信ありがとうございます。より具体的な例と測定値を提供いたします：

私たちは Solr 9.0.1 を使用しています。

以下のクエリを Solr に送信しています（親クエリの後にコロンではなくイコールがあることをお詫び申し上げます）：

{
  "query": "flotte huse",
  "filter": [
    "{!parent which='doc_type:work'}(pid.material_type:("lydbog" "artikel"))",
    "doc_type:work"
  ],
  "fields": "work.workid",
  "offset": 0,
  "limit": 10,
  "params": {
    "defType": "edismax",
    "qf": [
      "work.creator^100",
      "work.creator_fuzzy^0.001",
      "work.series^75",
      "work.subject_bibdk",
      "work.subject_fuzzy^0.001",
      "work.title^100",
      "work.title_fuzzy^0.001"
    ],
    "pf": [
      "work.creator^200",
      "work.fictive_character",
      "work.series^175",
      "work.title^1000"
    ],
    "pf2": [
      "work.creator^200",
      "work.fictive_character",
      "work.series^175",
      "work.title^1000"
    ],
    "pf3": [
      "work.creator^200",
      "work.fictive_character",
      "work.series^175",
      "work.title^1000"
    ],
    "mm": "2<80%",
    "mm.autoRelax": "true",
    "ps": 5,
    "ps2": 5,
    "ps3": 5
  }
}

このクエリは 21 件の workid を取得し、20 秒以上かかります。もしフィルタの最初の部分（親クエリを含む部分）を削除すると、33 件の workid が 200 ミリ秒未満で取得されます。フィルタの最初の部分があるかないかに関わらず（フィルタキャッシュが使用されないように新しい例を挙げた場合でも）、パフォーマンスに差はありません。

ドキュメントの返却件数には依存しないようです。

再度ご協力いただきありがとうございます。非常に感謝しています。

親クエリは実際にどのように解析されましたか？ debugQuery=true の出力で確認できますか？

よろしくお願いします、
Mikhail Khludnev

ちょっと待ってください。

Noahさん、子クエリだけのパフォーマンスはどうですか？
q=pid.material_type:("lydbog" "artikel")
クエリの実行時間（qtime）はどのくらいで、どのように解析されていますか？

よろしくお願いします、
Mikhail Khludnev

再度ご意見ありがとうございます、ミハイル。!parent which の使い方や debugOutput についてもっと調べる必要があります。

「どのように解析されているか」を確認するために、debug 出力のどの部分を見れば良いか、もう少し詳しく教えていただけますか？その出力は Solr のソースコード以外にどこかで文書化されていますか？

よろしくお願いします、

/Noah

次のように見えます：

"debug": {
  ...
  "parsedquery": "name:some",
  "parsedquery_toString": "name:some",
  ...
  "QParser": "LuceneQParser",
  "filter_queries": ["features:here"],
  "parsed_filter_queries": ["features:here"],
}

よろしくお願いします、
Mikhail Khludnev

スキーマをデノーマライズ（フラット化）することを検討すると良いでしょう。これにより、物事がはるかにシンプルになります。作業レベルのフィールドに対するプレフィルタは、マニフェストレベルのオブジェクト内の作業フィールドのフィルタに過ぎないので、簡単で迅速ですし、フィルタキャッシュにキャッシュされます。シャーディングも必要ならば簡単に行えるでしょう。

多くのフィールドについては心配する必要はありません。我々は150k ドキュメントの小規模なインデックスで、1ドキュメントあたり30,000フィールドを持っていました。各クエリで検索やランキングに使用されるフィールドはほんの数個でしたが、非常に速かったです。

作業レベルの更新があると、すべてのマニフェストレベルのドキュメントを更新する必要がありますが、それは頻繁に発生するものではないはずです。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)