4

それぞれに 14GB のインデックスを持つ 4 つのシャードがあります。各シャードにはマスターと 3 つのスレーブがあります (それぞれに 32GB の RAM があります)。

近い将来、インデックスのサイズが 2 倍または 3 倍になると予想しています。そのため、インデックスを 28GB のインデックスにマージして、各シャードに 28GB のインデックスを持たせ、各スレーブの RAM を 48GB に増やすことを考えました。

この変更をローカルで行い、同じ 10K の現実的なクエリを 14GB と 28GB のインデックスを持つ各サーバーに送信してサーバーをテストしたところ、

  1. 14GB インデックス (48GB RAM) のサーバーの場合: 検索時間は 480ms、インデックス ヒット数: 3.8G

  2. 28GB インデックス (48GB RAM) のサーバーの場合: 検索時間は 900 ミリ秒、インデックス ヒット数: 7.2G

そのため、インデックス全体を RAM に格納しても、検索時間に関してパフォーマンスを維持するのに役立たないことがわかりました。インデックス サイズが 2 倍になると、検索時間は直線的に増加し、2 倍になりました。

4 つのシャード構成のみを保持することを考えていましたが、各シャードに別のシャードまたは別のスレーブを追加する必要があるようです。

インデックスのサイズが 2 倍または 3 倍になってもパフォーマンスが影響を受けないようにサーバーを構成できる他の方法はありますか?

4

1 に答える 1

8

場合によるとは言いたくないが、それは… 場合による。

それぞれのインデックスの合計サイズは 14 GB ですが、これは基本的に SOLR にとってはあまり意味がありません。パフォーマンスの実際の感触をつかむために、索引付けされた用語の独自性は何ですか? 「cat」という単語が何度も含まれる 14GB 相当のデータのインデックスは、非常に高速です。

また、次の機能が必要であることを確認しましたか。無効にすると、パフォーマンスが大幅に向上します。

スキーマ

保存されたフィールド

保存されたフィールドが必要ですか? これを削除すると、パフォーマンスが大幅に向上します (保存されたフィールドなしでインデックス全体を安全に保持し、UX を駆動するために solr のファセット、ピボット、およびその他の機能に完全に依存することができます)。

省略ノルム

場合によっては、このフラグを false に設定して、一般的にメモリを削減し、パフォーマンスを向上させることができます。

omitTermFreqAndPositions

オフにすると、一般的にメモリが減少し、パフォーマンスが向上します。

システム

コア/インデックスの最適化 (セグメント数)

インデックスの最適化は、より大きなインデックス サイズを扱う場合に重要です。各コアが最適化されていることを確認し、コアを見るとセグメント数が 1 であることが示されていることを確認してください。インデックス サイズを大きくすると、これがより重要な役割を果たすことがわかりました (これは OS レベルのファイル キャッシュに影響し、実際には複数の小さなファイルよりも、1 つの大きなファイルを読む方が簡単です) そして、そうです、1 億 7100 万以上のドキュメントです。

ターム インデックス 間隔/頻度

非常に固有の値 (GUID/UUID または一般的な固有 ID など) を含むフィールドまたは複数のフィールドがある場合は、用語インデックス間隔の構成が必要になる場合があります (デフォルトでは 256)。通常、TIF が低いほど必要なメモリが多くなり、TIF が高いほど必要なメモリは少なくなりますが、ディスク シークが多くなる場合があります。

RAM の割り当てが多すぎる

Solr は、ファセット時に使用される OS レベルのディスク キャッシュと RAM を適切に分割することで最適に機能します。必要な RAM の使用量を減らし、ディスクのリソースを解放する他のパラメーターを微調整することで、実際にパフォーマンスが向上することに驚かれることでしょう。

于 2012-09-12T23:49:19.963 に答える