暗黙のシャーディング後にドキュメントが失われるのを防ぐ
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/lb6jy9ddlwd09xlq3x5tdgkoggs8y7nj into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
Solr開発者の皆さん、
問題の説明
私たちはSolr Cloudを使用しており、データを8つのシャードに分割していました。しかし、応答時間を短縮するために、データをさらに細かくシャーディングすることを考えました。
そのため、応答時間を短縮するために、Solrデータを56のシャードに分割することを計画しました。このシャーディング戦略に従って、ドキュメントのシャードを決定するために、マルチバリューフィールドの値の1つを使用しています。
しかし、これによりドキュメントの一部が失われる問題が発生しました。
問題の発生状況
例を用いて問題を説明します。
以下の3つのSolrドキュメントを考えます:
Doc1
{
"FieldA": "id21, id29, id60P",
"Field2": "val2"
}
Doc2
{
"FieldA": "id19, id9, id8P",
"Field2": "val1"
}
Doc3
{
"FieldA": "id101, id29, id108P",
"Field2": "val4"
}
Solrでのクエリ
次のクエリを考えてみます--- fq=FieldA: id21+id8+id108;
以前のシャーディングでは、Doc1、Doc2、およびDoc3が結果として返されていました。なぜなら、このフィルタークエリは、それぞれのドキュメントの少なくとも1つの値と一致していたからです。つまり、Doc1にはid21が、Doc2にはid8が、Doc3にはid108が含まれています。
しかし、新しいシャーディングでは、Doc2とDoc3のみが結果として返され、Doc1は結果に含まれません。なぜなら、このクエリはフィルタークエリに対応するシャード（shard21、shard8、shard108）にのみルーティングされ、Doc1はshard60に存在するためです。
インデックス作成とクエリの問題
このコレクションにクエリを実行しても、ドキュメント1が含まれるシャードにクエリが送信されないため、結果にドキュメント1が返されません。
考えられる解決策
この問題に対処するために、フィールドのすべての値に基づいて、同じドキュメントを複数のシャードにインデックス化することが考えられます。しかし、このフィールドの値が変更された場合、インデックス作成や削除の処理が非常に複雑になります。そのため、このインデックスの維持は非常に困難です。
これが最適な方法でしょうか？それとも、目標を達成しつつ、ドキュメントが失われないようにするためのより良い方法があるのでしょうか？
過去の類似のお問い合わせ
- 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
- 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はうまく機能するようです。 - 検索ストリーミング式で特定のシャードからドキュメントを取得
(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
間違っているかもしれませんが、ソースドキュメントの値に基づいてシャーディングするのではなく、ランダムにシャーディングしたほうが良いかもしれません。そうしないと、特定の検索が一部のシャードにしかヒットせず、過負荷になる可能性があります。このことが、以下の挙動の原因かもしれません。
Charlie
複数値フィールドはルーティングフィールドとしてサポートされていないと思っていました。おそらく、単一ドキュメントに複数の異なる値を持つフィールドの値ではなく、単一値の安定したプロパティをルーティングに選択する必要があります。
そのため、スキーマ内の他の候補となる単一値のルーティングフィールドを確認してください。見つからない場合は、CompositeID（つまりハッシュベース）の方が適しているかもしれません。CompositeIDを使用して8つのシャードを持つ場合、既存のシャードを分割して簡単に16 -> 32 -> 64に拡張できます。しかし、その場合も、より効率的なクエリを実行し、毎回すべてのシャードにヒットしないようにするためには、安定した単一値のIDを使用してルーティングする必要があります。
https://solr.apache.org/guide/solr/latest/deployment-guide/solrcloud-shards-indexing.html
Jan
トピックへ返信するには、ログインが必要です。