Solr 8.8.1におけるEnumFieldsの部分更新

(The bot translated the original post https://lists.apache.org/thread/7c1cz696x8o6gb53xlcrv69vcynk1mjy into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
みなさん、こんにちは。
Solr 8.2.0 から 8.8.1 にアップグレードした後、いくつかの問題が発生しています。
これはおそらく Lucene の問題かもしれませんが、確信はありません。
Solr のスキーマには、EnumFieldType を使用したフィールドが含まれています。たとえば、以下のようになります。
<fieldType name="languages" class="solr.EnumFieldType" docValues="true" enumsConfig="enumsConfig.xml" enumName="language"/>
enumsConfig.xml は次のようになっています:
<?xml version="1.0" ?>
<enumsConfig>
<enum name="language">
<value>de</value>
<value>fr</value>
</enum>
</enumsConfig>
部分更新を使用して、ドキュメントの「stock」といった異なるフィールドを更新すると、
stored=false のすべての Enum フィールドがドキュメントから消えてしまいます。
エラーログにはこれに関するエラーや警告が表示されません。
ご挨拶
Daniel Exner
過去の類似のお問い合わせ
- 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
- 検索ストリーミング式で特定のシャードからドキュメントを取得
(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
- 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
- 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
はうまく機能するようです。 - 音声検索
javadocによると、BeiderMorseFilterFactory はStandardTokenizerの後に使用することが推奨されています。
おそらく、GermanNormalizationFilterFactoryやGermanLightStemFilterFactoryはBeiderMorseFilterFactoryと一緒に使用すべきではありません。ステムが切り捨てられると、その発音が一致しなくなる可能性があります。
一方、異なる表記法(ß <-> ss)で書かれたドイツ語の単語を一致させたいだけなら、GermanNormalizationFilterFactoryだけで十分です。BeiderMorseFilterFactoryは必要ありません。
追伸:私はドイツ語の話者ではなく、上記の主張を実際にテストしたわけではありません。ただの推測です。
トピックへ返信するには、ログインが必要です。