ネストとpfパラメータに関する可能な問題
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/b70o8nkf6c5zndwtc11n17gc12o6z27w into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
このフォーラムに初めて投稿しますので、もし既知の問題であれば申し訳ありません。また、以前の投稿を十分に読んでいない場合もあるかもしれません。
私は図書館データを含むSolrで作業しています。私たちのデータには、"作品"があり、その"作品"に対するさまざまな"pid"（または表現）の子ドキュメントが存在するネスト構造があります。典型的な例としては、「ハリー・ポッターと賢者の石」がありますが、これにはオーディオブック、電子書籍、そしてもちろん、物理的な本など、さまざまな表現（pid）があります。タイトルや著者などの情報は作品レベルで保持され、資料タイプ（本/オーディオブック/電子書籍）や年などの情報は、子ドキュメントのpidレベルで保持されます。これが簡略化された説明ですが、私たちの試みを伝えるはずです。
必要に応じて、Solrのスキーマ全体を提供できますが、多くの情報が含まれており、どれが有益な情報であるかはわかりません。必要であれば提供することもできますが、まずは私が苦労している問題の簡略化されたバージョンを説明しようと思います。デンマークの作家ハンス・シェルフィグという作家がいますが、彼の物理的な本を検索したいです。Solrに対してこのクエリを発行します。queryレベルでデバッグを有効にしています。
{
"query": "(scherfig)+{!parent which='doc_type:work' v='pid.material_type:("bog")'}",
"filter": [
"doc_type:work"
],
"fields": "work.workid work.title, [child childFilter='pid.material_type:("bog")']",
"offset": 0,
"limit": 1,
"params": {
"defType": "edismax",
"qf": [
"work.creator",
"work.title",
"pid.material_type"
],
"pf": "work.creator",
"sort": "score desc",
"debug": "query"
}
}
このクエリを、Solrの /query エンドポイントに送信します（コア名は simple-search です）。
curl -H "Content-Type: application/json" "http://search-solr/solr/simple-search/query" -d @scherfig-filter-test.json
私は parent which 構文を使用しており、例えばこちらのドキュメントに記載があります: https://solr.apache.org/guide/8_2/other-parsers.html （私たちはSolr 8.10.1を使用しています）。デバッグ出力を見ると、次のような内容が見えます：
(work.creator:"scherfig parent which doc_type:work v pid.material_type")
これは少し心配です。"parent which" が work.creator フィールドの一部として見えるようですね？
興味深いことに、"pf":"work.creator" の行を削除すると、デバッグ出力のその部分が見えなくなります。ここで pf に問題があるのでしょうか？それともクエリのフォーマットが間違っていますか？
どうぞよろしくお願いします。
Noah
過去の類似のお問い合わせ
- Solr 8.7 を Java 11 Open J9 で起動するときに、コマンドラインオプションが認識されない
(The bot translated the original post https://lists.apache.org/thread/p3t5jbhwzy7xgyv1rlyzcqyl5d4295b5
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
現在、Java 8 から Java 11 への移行を進めています。
Windows上でOpenJ9 Javaを使ってSolr 8.7.0を起動すると、次のメッセージが表示されます：
JVMJ9VM007W Command-line option unrecognised: -Xlog:gc*:file="C:\solr\server\logs\solr_gc.log":time,uptime:filecount=9,filesize=20M JVMJ9GC063E Unable to open file '"C' for writingその後、コンソールにはガベージコレクションの出力が続きますが、Solrは問題なく起動し、動作しているように見えます。同じリリースのJava 11 Hotspotに変更すると、警告や他の問題は見られません。
Ubuntu上のJava 11 Open J9でも同様の問題が発生します。Solrログには「Command-line option unrecognised」というメッセージが表示されますが、コンソールには表示されません。
solr_gcログは正しく作成され、内容も記録されています。これを確認したのは、OpenJDK 11.0.10+9リリースを使用した場合です。
以下は私たちの起動コマンドの例です：
C:/solr/bin/solr.cmd start -c -p 8983 -s C:/data/solr/8/clusters/is_cluster/nodes/node1 -a "-Dcom.ibm.crypto.provider.DoRSATypeChecking=false -Djetty.server=com.i2group.disco.search.solr.jetty.wrapper.XmlConfigurationWrapper -Dpkiauth.ttl=60000 -Dsolr-node-id=node1 -DzkCredentialsProvider=com.i2group.disco.search.solr.common.zookeeper.auth.internal.EncodedZkCredentialsProvider -Djdk.nativeCrypto=false" -m 2g -z "localhost:9983/is_cluster"よろしくお願いします。
Lisa
- ZooKeeperのupconfigはZK_HOST形式のURLを認識しません
(The bot translated the original post https://lists.apache.org/thread/tfpn1tlgosx67n5omzpkmrdzvsbr02bd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
Solrのコントロールスクリプトを使用して新しいconfigsetをZooKeeperにアップロードしようとしたところ、-zパラメータがZK_HOST形式の文字列を認識しませんでした。
たとえば、
<ip-1>,<ip-2>,<ip-3>/solrを使用すると、configが/solr znodeではなく、直接<ip-1>にアップロードされます。これが意図された動作かどうかについて助けていただけないでしょうか？
注：
<ip-1>/solr,<ip-2>/solr,<ip-3>/solrはうまく機能するようです。 - CustomBreakIteratorのパフォーマンスに関する問題
(The bot translated the original post https://lists.apache.org/thread/4kryrpfp9bdl3dbyb77vnmlfdlcg0dcd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
現在、統合ハイライト機能でカスタムBreakIteratorを動作させる作業をしており、パフォーマンスに苦労しています。
私はパッセージの見出しをきれいにハイライトするためにBreakIteratorが必要です。これにより、ハイライトの開始が文の開始であり、終了が単語の終わりであるようにしたいです。また、いくつかの奇妙なエッジケースもあります。
すでにBreakIteratorをコーディングし、カスタムUnifiedHighlighterクラスに統合しましたが、このIteratorを使用すると、すべてのリクエストのqTimeが約1000から12000以上に上昇し、このアプリケーションでは許容できません。
こちらが私の実装へのリンクです。どこが非常に非効率的なのかを見つけることができません。（これらの関数が非常に頻繁に呼び出されることはわかっています）
他のアプローチも含め、すべての提案を歓迎します。
したがって、BreakIteratorや関連する情報について詳しく学ぶための良いリソースはありますか？ここではコードの調査が非常に難しいです。
次に検討しているもう1つのアプローチは、最終的なハイライトが見つかったときにこのハイライトの「トリミング」を行うことです。これにより、呼び出されるロジックの量が減少しますが、SOLRのスコアリングシステムが正しく考慮されない可能性があると思われます。
私が言ったように、すべての提案を歓迎し、先にお礼を申し上げます。
Jan Ulrich Robens
- 検索ストリーミング式で特定のシャードからドキュメントを取得
(The bot translated the original post https://lists.apache.org/thread/vdqjcy6frv9c2kg97xh244ppj1v5jgc2
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)「Search streaming expression」で単一の特定のシャード（または特定のレプリカ）からすべてのドキュメントをストリームできますか？ 通常の「shards」パラメータを使用しても、Search streaming exprと一緒に使用すると効果がないと思います。
--ufuk
- このクエリを最適に構成する方法は何ですか？
以下のディスカッションを参照してください：
- https://issues.apache.org/jira/browse/LUCENE-7148
- https://lucene.apache.org/core/8_11_0/sandbox/org/apache/lucene/search/CoveringQuery.html
--
よろしくお願いします、
Mikhail Khludnev
私もこれについて気付いています。pfの解析が、より複雑なクエリ構文に対して単純な方法で行われていることについても興味があります。他の方々の意見も聞いてみたいと思っています。もし誰も反応がない場合は、おそらくdev@solrリストへの質問が適切でしょう。
上記を除いても、現在の q パラメータで暗黙的に混合されたクエリ構文をお勧めしません。!parent クエリパーサーがスコアリングに影響しないと仮定すると、fq 内にそれを単独で配置する方が良いのではないかと思います。例えば fq={!parent [...]} です。また、SOLR-11501 [1] により、この種のネストしたクエリ構文の解析が7.2バージョン以降（luceneMatchVersionに依存）で変更される予定ですので、アプローチを切り替えるのが良いでしょう。
もし依然としてこれらを単一のクエリとしてまとめたい場合は、ブールクエリを明示的に組み合わせることをお勧めします。例えば次のように:
defType=lucene&q={!boolean should='{!edismax v=$qq}' filter=$myParentFilter}&qq=(scherfig)&myParentFilter={!parent which='doc_type:work' v='pid.material_type:("bog")'}
これらのより明示的な代替アプローチのいずれかを使用すると、pf パラメータが適切にブースティングフレーズクエリを構築するはずです（pf パラメータの目的に従って）。
トピックへ返信するには、ログインが必要です。