schemaVersion 1.7 docValues

(The bot translated the original post https://lists.apache.org/thread/g2mc9ck5yhfd2j493lbjlgt2jcjy3cs6 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
Solr 9.7 のリリースノートによると、さまざまなフィールドタイプに対して docValues
がデフォルトで有効になりました。しかし、Lucene の仕様では、既存のインデックスで docValues
が未使用の場合、それを docValues
に変換することはできないという警告があります。この変更について、インデックスを破損させないために、私の理解が正しいかを確認したいです。
私の理解では、再インデックスが必要になる唯一のケースは、以下の条件を満たす場合です:
- 特定のフィールドとフィールドタイプの組み合わせで、
- Solr のプリミティブなフィールドタイプを使用しており、
- そのフィールドで
docValues
が設定されていない場合。
具体例:
フィールドに
docValues
が設定されている(true または false)場合:
→ このフィールドは問題ない。フィールドに
docValues
が設定されていなくても、そのフィールドタイプに設定されている場合:
→ このフィールドは問題ない(フィールドタイプからdocValues
の振る舞いを継承するため)。動的フィールドが上記 2 つのケースのいずれかに該当する場合:
→ このフィールドも問題ない。
この理解が正しいか、どなたか、もしくは複数の方に確認していただきたいです。
よろしくお願いします。
- Kevin
過去の類似のお問い合わせ
- 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
- 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
はうまく機能するようです。 - 検索ストリーミング式で特定のシャードからドキュメントを取得
(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
- 音声検索
javadocによると、BeiderMorseFilterFactory はStandardTokenizerの後に使用することが推奨されています。
おそらく、GermanNormalizationFilterFactoryやGermanLightStemFilterFactoryはBeiderMorseFilterFactoryと一緒に使用すべきではありません。ステムが切り捨てられると、その発音が一致しなくなる可能性があります。
一方、異なる表記法(ß <-> ss)で書かれたドイツ語の単語を一致させたいだけなら、GermanNormalizationFilterFactoryだけで十分です。BeiderMorseFilterFactoryは必要ありません。
追伸:私はドイツ語の話者ではなく、上記の主張を実際にテストしたわけではありません。ただの推測です。
トピックへ返信するには、ログインが必要です。