ストリーミング式 - シャーディングのメモリ使用量

トピック作成者:ks-solruserml-bot (2024/08/15 10:34 投稿)
5
CloseClose

(The bot translated the original post https://lists.apache.org/thread/bjbjzwb5h6w3rlr6ykpqpqk4gfvn4kql into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

こんにちは、

現在、Solr Cloud クラスターでシャーディングの実装に取り組んでいます。主な目的は水平スケーリングを実現することです。

現在、シャーディングを行わない場合、すべてのコレクションがすべてのサーバーに配置されています。また、非常に多くのIDを返す重いストリーミング式も使用しています。平均で300,000件のIDを結合しています。

シャーディングを行った後、CPUとメモリの使用量が大幅に増加し、クエリの速度が遅くなりました。シャーディングを行っていない場合と比較して、クエリが大幅に遅くなっています。

これは予想通りかと思います。なぜなら、ジョイン処理がサーバー間でネットワークを通じてデータを送信する必要があるからです。

ここでのベストプラクティスについて何か考えがありますか? 可能なアプローチの一つは、シャードをさらに分割することだと思います。

よろしくお願いします。
Sergio

返信投稿者:ks-solruserml-bot (2024/08/15 10:34 投稿)

ストリーミング式を共有できますか? そうすれば、シャーディングがどのように関わってくるかを議論できます。

Joel Bernstein
http://joelsolr.blogspot.com/

返信投稿者:ks-solruserml-bot (2024/08/15 10:35 投稿)

わかりました。まずは最もシンプルなストリーム式から始めましょう。この式は、person コレクションのみを対象としています。

ストリーム式:

search(person, q="((((SmartSearchS:"france [$CU] [$PRJ] [$REC] "~100)^4 OR
(SmartSearchS:"france [$CU] [$PRJ] [$RECL] "~100)^3 OR
(SmartSearchS:"france [$CU] [$PRJ] "~100)^2) OR (((SmartSearchS:(france*)))
OR ((SmartSearchS:("france")))^3)) AND ((*:* -StatusSFD:("\*\*\*System
Delete\*\*\*")) AND type_level:(parent)))", fl="PersonIDDoc,score",
sort="score desc,PersonIDDoc desc", rows="1000")

スキーマ:

<field name="PersonIDDoc" type="string" indexed="true" stored="true"
docValues="true" />

シャーディングなし:

  • 1つのシャード、45.38GB、ドキュメント数:64,348,740
  • ストリーム式の実行時間:660ms

シャーディングあり:

  • 2つのシャード、各23GB
  • ストリーム式の実行時間:4000ms
返信投稿者:ks-solruserml-bot (2024/08/15 10:35 投稿)

まず最初に目に付くのは、select ハンドラーを使用して検索を行っており、スコアでソートする必要がある点です。このシナリオでは、行数が増えるにつれて深いページングの問題に直面することになります。これにより、メモリとパフォーマンスの両方に影響が出ます。export ハンドラーを使用した検索では、スコアリングはサポートされていませんが、シャードを追加することでスループットが向上し、メモリのペナルティは発生しません。

この場合、1000行はそれほど多くのドキュメントではないので、ペナルティが非常に高いことに驚いています。しかし、結果セットを大きく引き出し始めると、確実に大きなメモリとパフォーマンスのペナルティに直面します。

具体的なユースケースについて教えていただけますか?例えば、スコア付きデータのストリームを結合して、大量のドキュメントを抽出する必要がありますか?それとも、結合されたストリームの上位N件のドキュメントを表示するだけでよいのでしょうか?

Joel Bernstein
http://joelsolr.blogspot.com/

返信投稿者:ks-solruserml-bot (2024/08/15 10:35 投稿)

Joel、回答ありがとうございます。

実際に私が必要なのは、異なるコレクションからスコアを返し、そのスコアを使っていくつかの計算を行い、最終的に「people」を取得することです。より複雑な例をお見せします。すべてのコレクションが同じサーバー上にあるときには非常に高速ですが、シャーディングが行われると非常に遅くなります。

select(
  select(
    rollup(
      innerJoin(
        select(
          search(person, q="((((SmartSearchS:"madrid [$CU] [$PRJ] [$REC] "~100)^4 OR (SmartSearchS:"madrid [$CU] [$PRJ] [$RECL] "~100)^3 OR (SmartSearchS:"madrid [$CU] [$PRJ] "~100)^2) OR (((SmartSearchS:(madrid*))) OR ((SmartSearchS:("madrid")))^3)) AND ((*:* -StatusSFD:("***System Delete***")) AND type_level:(parent)))", fl="PersonIDDoc,score", sort="PersonIDDoc desc,score desc", rows="2147483647"),
          PersonIDDoc, score as PersonScore
        ),
        select(
          rollup(
            search(contactupdate, q="(((UpdateTextS:(cto)) AND IsAttachToPerson:(true)) AND (((AssignConfidentialS:(false) OR (AssignAuthorisedEmplIdsS:((cc)))))))", fl="PersonIDDoc,score", sort="PersonIDDoc desc,score desc", rows="2147483647"),
            over=PersonIDDoc, sum(score), sum(PersonIDDoc)
          ),
          PersonIDDoc, add(0,0) as DocumetScore, sum(score) as ContactUpdateScore
        ),
        on="PersonIDDoc"
      ),
      over=PersonIDDoc, sum(PersonScore), sum(ContactUpdateScore), count(PersonIDDoc)
    ),
    PersonIDDoc, sum(ContactUpdateScore) as ContactUpdateScore, sum(PersonScore) as PersonScoreTotal, count(PersonIDDoc) as TokenCount
  ),
  PersonIDDoc, TokenCount, add(mult(PersonScoreTotal, 0.6), mult(ContactUpdateScore, 0.4)) as CalculatedScore
)

かなり複雑なクエリであることは理解していますが、単一のシャードで約3秒かかり、シャーディングを行うと基本的に処理が爆発的に遅くなります。

これは、シャーディングされたコレクションではこのような動作を達成できないということなのでしょうか?

よろしくお願いします。

返信投稿者:ks-solruserml-bot (2024/08/15 10:35 投稿)

残念ながら、現在のSolrには、あなたが行っているようなスコアリングを伴う大量のデータ抽出に対する最適な解決策はありません。エクスポートハンドラは大量データの抽出を目的としていますが、スコアリングは行いません。セレクトハンドラは、スコアリングを伴う上位N件のデータの取得を目的としています。単一シャードでのスコアリングを伴う大量データ抽出がこれほど良好に機能しているのには驚きました。

Joel Bernstein
http://joelsolr.blogspot.com/

トピックへ返信するには、ログインが必要です。

KandaSearch

Copyright © 2006-2024 RONDHUIT Co, Ltd. All Rights Reserved.

投稿の削除

この投稿を削除します。よろしいですか?