こんにちは、

インデックスを高速化したい場合は、次のことを確認してください。

• Solr側で大量のデータを処理するための十分なハードウェアを用意すること。
• クライアント側で複数のスレッドを使用してインデックスを作成し、受信側のCPU数に基づいて最適な数を見つけるために実験すること。
• クライアントでJavaを使用する場合、CloudSolrClientを使用すること。これはドキュメントを正しいシャードに送るのに十分賢いです。
• バルクロード中にコミットしないこと。終わるまで待ってからコミットすること。
• バッチサイズを実験すること。例えば、各更新リクエストで500件のドキュメントを送信してから1000件など、最適な妥協点を見つけるまで試すこと。
• 可能であればJavaBinを使用すること。JSONよりも少し速いはずですが、大差はないでしょう。
• 最終的にRDBMSがボトルネックになるかもしれないことを覚えておいてください。どれくらいの行を配信できますか？各クライアントが並行して読み取るためにSELECT ... WHERE句を使用してデータセットを分割する必要があるかもしれません。

Jan

それは複数のクライアントを持つことも意味します。我々は42M行の全体をインデックスするのに約8時間かかっていたのが、10個のインデクサークライアントを同時に実行することで約1.5時間に短縮されました。各インデクサーはデータの約1/10を処理します。どのクライアントもコミットを行いません。インデクサーがすべて完了した後、最後にもう一度キューを通してコミットを行います。

Janが言うように、データベースがボトルネックにならないように確認し、同時に実行するクライアントの数を実験してみてください。

Andy

もう一つの方法は、インデックス作成コードをSolrインデックスサーバーが持つコアの数だけ並列に実行させることです。コードを何度も並行して実行させるのは非常に簡単ですし、SQLクエリとテーブルが適切にインデックスされていれば、データベースがボトルネックになることはありません。インデックスサーバーに必要なリソースがあることを確認するだけです。インデックス作成サーバーはクエリサーバーと異なり、クエリサーバーは高速な読み取りのために調整されたコピーであり、書き込みのためではありません。

変更がない限り、これは少しリスクがあります。非常に大きなトランザクションログや、起動時のトランザクションログの非常に長い再生につながる可能性があります。インデックス作成中にSolrがOOM（メモリ不足）などでダウンした場合、再起動に非常に長い時間がかかる可能性があり、人々が停止したと思って再起動すると、再び最初からやり直す必要があります...（参照：https://lucidworks.com/post/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/ ）。
頻繁なコミットがないよりもましですが（ただし、間違いなく頻繁なコミットは避けるべきで、特にバッチごとや、さらに悪いことにドキュメントごとにコミットするのは避けるべきです）。

-Gus

自動コミットを openSearcher を false に設定し、比較的低い maxTime 値で構成することは常に良い習慣です。Solr が出荷する設定では、これを 15 秒（実際の値は 15000 ミリ秒）に設定していると思いますが、システム全体の負荷を減らすために私は 60 秒にすることを好みます。この設定により、大きなトランザクションログの問題を解消できます。これは、リンクされた Lucidworks の記事で議論されていると思います。

新しい検索者を開くコミットは、大規模なインデックス作成作業の終了時に行うべきです。私はこれをソフトコミットとして行いますが、openSearcher を true に設定したハードコミットにしても問題ありません。大規模なインデックス作成作業では、これらの2種類のコミット間のパフォーマンスの違いはほとんどないでしょう。

ありがとうございます。
Shawn

7000万という数は多いか少ないか、ケースによります。ドキュメントの数だけでは全体像はわかりません。これらのドキュメントはデータベースでどれだけのストレージスペースを占有していますか？テキストがツイートサイズなのか、数メガバイトのCLOBなのか、ファイルストアのリンクファイルで取得して解析する必要があるのか（OCRや音声/ビデオからの文字起こしの変換も含む）？非常に少ないテキストを持つIoTタイプのドキュメントは、50ページのPDFドキュメントよりもはるかに早くインデックスを作成できます。非常に大規模なクラスターとインデックス作成システムを使用してSparkクラスター全体に作業を分散させると、1秒あたり最大130万ドキュメントを見たことがあります...そのシステムでは70Mは取るに足らない数でした（数千億単位でした）。しかし、テキストドキュメントは通常、それよりもはるかに遅いです。特に、PDFやワードデータなどの汚れた形式からテキストを抽出する必要がある場合や、複雑なカスタム分析が関与している場合、またはドキュメントに統合するために追加のファイルやデータを取得する必要がある場合は特にそうです。

2つの形式について：Javaコードを使用してインデックスを作成する場合は、Java Binaryを選択してください。非Java言語を使用する場合は、JSONを使用できます。JavaからJSONを使用する稀なケースは、データがすでにJSON形式である場合です。その場合、Solrがボトルネックであるかどうかによります（インデクサーで作業を行い、Java Binaryを使用して解析の負荷を軽減する）または、インデックス作成マシンがボトルネックであるかどうか（JSONを使用してインデクサーが変換する必要をなくす）に依存します。検索の多くのことと同様に「それは依存します」:)

こんにちは、Gus

追加の質問があります。まったく同じドキュメントを表現している場合、SolrによるJSONの解析はXMLよりも速いのでしょうか？

Thomas

テストはしていませんが、XMLよりも速いものは何でもあると思います。テキストファイルを使ったほうがいいでしょう。XMLはゴミです。それが理由で、JSONの親であるYAMLが作られたのです。

入力データの解析速度が他のすべてに費やす時間に比べてごくわずかであるケースは想像できません。これは大量のI/Oを行うメモリ内操作の話です。

どちらの方法でも目立った違いは生じないでしょう。

最近変更があった場合を除いて、ロード中に少なくともソフトコミットを行わないとメモリリークが発生する可能性があります。これは、リアルタイム検索に使用されるインメモリのトランザクションログ（tlog）データによるものです。このインメモリのtlogデータは、新しい検索者が開かれるときに解放されます。

したがって、バルクデータのロード中にメモリの問題が発生している場合は、自動ソフトコミットを設定し、負荷のパフォーマンスとメモリの保持をバランスさせる間隔に調整してください。

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