容量の計画

DSE Searchを使用すると、メモリーの使用量が多くなります。探索プロセスに従って、十分なメモリー・リソースを確保するための容量の計画を立案します。

DSE Searchを使用すると、メモリーの使用量が多くなります。インデックスの更新時にSolrが行全体を再度読み取ると、回転式ディスクにかなりのパフォーマンス・ヒットを招くことがあるので、大がかりな挿入/更新要件を持つアプリケーションに対応した、ソリッド・ステート・ドライブ（SSD）を使用します。

この容量計画探索プロセスでは、動作要件を満たすために十分なメモリー・リソースを確保する計画を立案できます。容量計画に関する一般的なアドバイスについては、「クラスター・デプロイの計画およびテスト」を参照してください。

概要 

最初に、1つのノードにある多数のドキュメントのインデックスを作成し、通常のユーザー・クエリーを実行した後、ヒープ割り当てのためのフィールド・キャッシュ・メモリー使用量を調べることによって、サーチ・インデックスがどのくらい大きくなるかを見積もります。インデックスのサイズが、1つのノードで処理できるドキュメントの最大数に対応できるサイズを確実に見積もれるまでドキュメントの数を増やして、このプロセスを繰り返します。これによって、1つのクラスターのためにデプロイするサーバーの台数と最適なヒープ・サイズを決定できます。インデックスをSSDまたはシステムのIOキャッシュに格納します。

容量計画の際には運用担当者が真摯に取り組んで、以下の手順を実行する必要があります。

• 1ノードあたりの最適なヒープ・サイズを設定する。
• アプリケーションに必要とされるノード数を見積もる。
• 1秒で多くのクエリーをサポートできるようにレプリケーション係数を増やす。

注: プリフライト・ツールは、多くの無効または最適状態に及ばない構成設定を検知して修正できます。

1. schema.xmlファイルとsolrconfig.xmlファイルを作成します。
2. ノードを起動します。
3. N個のドキュメントを追加します。
4. 実稼働環境をシミュレートする一連のクエリーを実行します。
5. フィールド・キャッシュ・メモリーのステータスを表示してメモリー使用量を探索します。
6. Solrコアに関するステータス情報に含まれる、ディスク上のインデックスのサイズを表示します。
7. サーバーで使用可能なシステムIOキャッシュのサイズに基づいて、サーバーごとの最大インデックス・サイズを設定します。
8. メモリー使用量に基づいて、サーバーごとに必要な最大ヒープ・サイズを設定します。
   • 必須のパフォーマンスとメモリー容量を提供するJVMメモリーの場合、DataStaxでは14GB以上のヒープ・サイズを推奨しています。
   • 高速のライブ・インデックス作成の場合、オフヒープを割り当てられるライブ・インデックス作成（RT）の送信を構成する必要があります。
     注: クラスター1つあたりSolrコア1つにライブのインデックス作成を有効にします。
9. 手順6および手順7に基づいて、ノードごとのドキュメントの最大数を計算します。

   システムがノードごとの最大ドキュメント数に近づいたら、さらにノードを追加します。