SharePoint Server でエンタープライズ検索アーキテクチャを計画する
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
エンタープライズ検索アーキテクチャを設定する前に、慎重に計画しなければならないことが数多くあります。 手順を追って、小規模、中規模、大規模、または超大規模のエンタープライズ検索アーキテクチャを計画するのに役立ちます。
SharePoint Server の検索システムのコンポーネントと、それらの操作方法についてよく理解していますか? 「SharePoint Server での検索アーキテクチャの概要」と「SharePoint Server 2016 の検索アーキテクチャ (または SharePoint Server2013 の検索アーキテクチャ)」を参照すると、検索アーキテクチャ、検索コンポーネント、検索データベース、および検索トポロジについて理解できるようになります。 検索アーキテクチャを計画する場合、考慮すべき事項に関するいくつかの提案を次に示します。
手順 1: コンテンツがどのくらいあるか。
検索インデックスにあるコンテンツのボリュームは、ファームをホストするために必要なリソースを何にするかに影響します。 検索可能にするおよそのアイテム数を算出します。 アイテムの例として、ドキュメント、Web ページ、SharePoint リスト エンティティ、イメージなどがあります。 SharePoint リスト内の各エントリが 1 アイテムとしてカウントされます。
数を確定したら、これに次の 12 か月間に予想されるコンテンツの増加率を掛けます。
たとえば、インデックス付きアイテムが 12,000 個から始まり、そのコンテンツの量が今後 12 か月間で 3 倍になると予想される場合です。 36,000 個の検索可能な項目を計画する必要があります。
手順 2: コンテンツのサイズ検索アーキテクチャ
検索アーキテクチャをどのくらい大きくまたは小さくするか評価することは必ずしも簡単なことではありません。 検索アーキテクチャのサイズは、必要とするコンテンツのボリューム、クロール レート、クエリ スループット、および高可用性のレベルにより異なります。 独自のファームを計画するための基礎として使用することをお勧めするサンプル検索アーキテクチャがあります。 選択するサンプルの検索アーキテクチャは、検索可能にする必要のあるコンテンツの量で決まります。
| コンテンツの量 (SharePoint 2016) | サンプルの検索アーキテクチャ | コンテンツの量 (SharePoint 2013) |
|---|---|---|
| 0 - 2,000 万アイテム | 小規模検索ファーム | 0 - 1,000 万アイテム |
| 0 - 8,000 万アイテム | 中規模検索ファーム | 0 - 4,000 万アイテム |
| 0 - 2 億アイテム | 大規模検索ファーム | 0 - 1 億アイテム |
| 0 - 5 億アイテム | 超大規模検索ファーム | 非サポート |
これらのサンプル検索アーキテクチャでは仮想マシンが使用されますが、検索アーキテクチャの SharePoint Server ソリューション全体の戦略に従って、物理サーバーと仮想マシンの両方を使用できます。
小規模検索ファーム
この検索アーキテクチャは毎秒 50 ドキュメントをクロールし、毎秒 10 クエリ程度を処理できると推定されています。 SharePoint Server 2016 ファームに最大 2,000 万個のアイテムがある場合は、おそらく小規模な検索ファームが最適なファームになります。 毎秒 50 ドキュメントのクロール レートでは、最初のフル クロールで 2,000 万個のアイテムをクロールするには、検索に 110 時間かかります。
中規模検索ファーム
この検索アーキテクチャは毎秒 100 ドキュメントをクロールし、毎秒 10 クエリ程度を処理できると推定されています。 SharePoint Server 2016 ファームに 2,000 万から 8,000 万個のアイテムがある場合は、おそらく中規模の検索ファームが最適なファームになります。 毎秒 200 ドキュメントのクロール レートでは、最初のフル クロールで 8,000 万個のアイテムをクロールするには、検索に 280 時間かかります。
大規模検索ファーム
この検索アーキテクチャは毎秒 200 ドキュメントをクロールし、毎秒 10 クエリ程度を処理できると推定されています。 SharePoint Server 2016 ファームに 80 から 2 億個のアイテムがある場合は、おそらく大規模な検索ファームが最適なファームになります。 毎秒 200 ドキュメントのクロール レートでは、最初のフル クロールで 2 億個のアイテムをクロールするには、検索に 280 時間かかります。
超大規模検索ファーム
Microsoft ではこの検索アーキテクチャをテストし、毎秒 300 から 500 ドキュメントをクロールし、毎秒 10 クエリ程度を処理できることを測定しました。 このサイズ検索アーキテクチャは、SharePoint Server 2016 でのみサポートされています。 最大 5 億個のアイテムがある場合は、超大規模検索ファームのようなファームが適しています。 毎秒 500 ドキュメントのクロール レートでは、最初のフル クロールに 5 億個のアイテムをクロールするには、検索に 300 時間かかります。
このサイズの検索ファームを作成するには、必要なパフォーマンスを得られるようファームを慎重に計画し調整する必要があります。 専門家の指導を受けることが適切な場合があります。 また、このサイズの検索ファームをバックアップおよび復元する方法と、データ センターで大規模な停止が発生した場合にファームを復旧する方法を計画することも重要です。 バックアップ、復元および復旧を練習することをお勧めします。
手順 3: 認識しておくべきハードウェア要件は何か。
コンテンツのボリュームを決定し、サンプルの検索アーキテクチャを選択したら、次の手順ではこのセクションで記載されているとおりに必要なハードウェアを計画します。
サーバーを物理的に実行するか仮想的に実行するかを選択する
見積もったアーキテクチャのいずれかを使用している場合は、仮想マシンで検索アーキテクチャを実行します。 仮想環境は管理が簡単ですが、パフォーマンス レベルが物理環境のものよりも少し低くなることがある点にも注意してください。 物理サーバーは仮想サーバーよりも、同じサーバー上でより多くの検索コンポーネントをホストできます。 「Overview of farm virtualization and architectures for SharePoint 2013」に役立つガイダンスがあります。
物理サーバーで検索アーキテクチャを実行することもできます。 サンプル ファーム アーキテクチャでは、検索コンポーネントを仮想マシンからホスト サーバーに移動し、仮想マシンを取り除きます。 各物理サーバーは、最大 4 つのインデックス コンポーネントをホストできますが、他の検索コンポーネントの種類ごとに 1 つだけです。 たとえば、物理サーバーを使用するように中規模のサンプル検索アーキテクチャを変更すると、ホスト E に 2 つのコンテンツ処理コンポーネントがあることがわかります。解決策は、コンテンツ処理コンポーネントの 1 つを取り除くものです。 これは、クロール、コンテンツの処理、分析の処理は、コンテンツ処理コンポーネントの数ではなく、使用可能なリソースの量によって異なるためです。
ホスト サーバーのハードウェア リソースを選択する
各検索コンポーネントと検索データベースが良好に機能するには、ホスト サーバーからの最小限のハードウェア リソースが必要です。 しかし、ハードウェア リソースは多ければ多いほど、検索アーキテクチャのパフォーマンスが向上します。 そのため、最小限のハードウェア リソースよりも多くのハードウェア リソースを用意することをお勧めします。 各検索コンポーネントで必要なリソースはワークロードによって異なり、大部分はクロール速度、クエリ速度、およびインデックス付けされたアイテムの数によって決まります。
たとえば、仮想マシンを Windows Server 2008 R2 Service Pack 1 (SP1) でホストする場合、仮想マシン 1 台につき最大で 4 個の CPU コアしか使用できません。 Windows Server 2012 以降では、仮想マシンごとに 8 個以上の CPU コアを使用します。 したがって、より多くの仮想マシンを使用してスケール アップする代わりに、仮想マシンごとにより多くの CPU コアを使用してスケール アウトできます。 同じ検索コンポーネントをホストし、同じハードウェア リソースを持つサーバーまたは仮想マシンをセットアップします。 例としてインデックス コンポーネントを取り上げます。 仮想マシンでインデックス パーティションをホストする場合、最低のパフォーマンスの仮想マシンによって検索アーキテクチャ全体のパフォーマンスが決まります。
汎用ストレージ
各ホスト サーバーに、Windows Server オペレーティング システムの基本インストールと SharePoint Server プログラム ファイル用の十分なディスク領域があることを確認します。 また、ホスト サーバーでは、ログ記録、デバッグ、メモリ ダンプの作成などの診断用、日々の操作用、およびページ ファイル用の空きハードディスク領域も必要です。 通常、Windows Server オペレーティング システムと SharePoint Server プログラム ファイルには、80 GB のディスク領域で十分です。
データベース サーバーごとに SQL ログ スペース用のストレージを追加します。 データベースを頻繁にバックアップするようにデーベース サーバーを設定していない場合は、SQL ログ スペースに大量のストレージが使用されます。 SQL データベースを計画する方法の詳細については、「ストレージとSQL Server容量の計画と構成 (SharePoint Server)」を参照してください。
分析レポート データベースが必要とする最低限のストレージは、異なる場合があります。 これは、ストレージの量は、ユーザーが SharePoint Server とやり取りする方法によって異なるためです。 ユーザーが頻繁に操作すると、通常は保存されるイベントが多くなります。 現在の検索アーキテクチャがデータベースの分析に使用しているストレージの量を確認し、再設計するトポロジにこの量以上を割り当ててください。
小規模検索ファーム用の最低限のハードウェア リソース
各アプリケーション サーバーまたはデータベース サーバーに必要なハードウェア リソースの最小量を次の表に示します。
| サーバー | 稼働するホスト | ストレージ | RAM | プロセッサ1 | ネットワークの帯域幅 |
|---|---|---|---|---|---|
| クエリ処理コンポーネントとインデックス コンポーネントを備えたアプリケーション サーバー。 | A、B | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x CPU コア2,3 | 1 Gbps |
| クロール、検索管理、分析、およびコンテンツ処理コンポーネントを備えたアプリケーション サーバー。 | A、B | 200 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| すべての検索データベースを備えたデータベース サーバー。 | C、D | 100 GB | 16 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
1 ここで指定しているのは、CPU スレッドの数ではなく、CPU コアの数です。
2SharePoint Server 2013 では、500 GB のストレージ、16 GB の RAM、4 つの CPU コアが必要な最小リソース量が必要です。
3SharePoint Server 2016 では、250 GB のストレージ、16 GB RAM、4 つの CPU コアを使用することもできますが、各インデックス コンポーネントは 1,000 万個のアイテムのみを保持でき、検索ファームは SharePoint Server 2013 検索ファームと同じ量のコンテンツのみをサポートします。
中規模検索ファーム用の最低限のハードウェア リソース
各アプリケーション サーバーまたはデータベース サーバーに必要なハードウェア リソースの最小量を次の表に示します。
| サーバー | 稼働するホスト | ストレージ | RAM | プロセッサ1 | ネットワークの帯域幅 |
|---|---|---|---|---|---|
| クエリ処理コンポーネントとインデックス コンポーネントを備えたアプリケーション サーバー。 | A、B、C、D | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x CPU コア2,3 | 1 Gbps |
| インデックス コンポーネントを備えたアプリケーション サーバー。 | A、B、C、D | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x CPU コア2,3 | 1 Gbps |
| 分析コンポーネントとコンテンツ処理コンポーネントを備えたアプリケーション サーバー。 | E、F | 300 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| クロール、検索管理、およびコンテンツ処理コンポーネントを備えたアプリケーション サーバー。 | E、F | 100 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| すべての検索データベースを備えたデータベース サーバー。 | G、H | 400 GB | 16 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
1 ここで指定しているのは、CPU スレッドの数ではなく、CPU コアの数です。
2SharePoint Server 2013 では、500 GB のストレージ、16 GB の RAM、4 つの CPU コアが必要な最小リソース量が必要です。
3SharePoint Server 2016 では、250 GB のストレージ、16 GB RAM、4 つの CPU コアを使用することもできますが、各インデックス コンポーネントは 1,000 万個のアイテムのみを保持でき、検索ファームは SharePoint Server 2013 検索ファームと同じ量のコンテンツのみをサポートします。
大規模検索ファーム用の最低限のハードウェア リソース
各アプリケーション サーバーまたはデータベース サーバーに必要なハードウェア リソースの最小量を次の表に示します。
| サーバー | 稼働するホスト | ストレージ | RAM | プロセッサ1 | ネットワークの帯域幅 |
|---|---|---|---|---|---|
| クエリ処理コンポーネントとインデックス コンポーネントを備えたアプリケーション サーバー。 | A、B、C、D、E、G、H | 500 GB2、3 | 32 GB2、3 | 1.8 GHz 8x CPU コア2、3 | 1 Gbps |
| インデックス コンポーネントを備えたアプリケーション サーバー。 | A、B、C、D、E、F、G、H、I、J | 500 GB2、3 | 32 GB2、3 | 1.8 GHz 8x CPU コア2、3 | 1 Gbps |
| 分析コンポーネントとコンテンツ処理コンポーネントを備えたアプリケーション サーバー。 | K、L、M、N | 300 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| クロール コンポーネントと検索管理コンポーネントを備えたアプリケーション サーバー。 | K、L | 100 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| 検索データベースを備えたデータベース サーバー。 | O、P、Q、R | 500 GB | 16 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
1 ここで指定しているのは、CPU スレッドの数ではなく、CPU コアの数です。
2SharePoint Server 2013 では、500 GB のストレージ、16 GB の RAM、4 つの CPU コアが必要な最小リソース量が必要です。
3SharePoint Server 2016 では、250 GB のストレージ、16 GB RAM、4 つの CPU コアを使用することもできますが、各インデックス コンポーネントは 1,000 万個のアイテムのみを保持でき、検索ファームは SharePoint Server 2013 検索ファームと同じ量のコンテンツのみをサポートします。
超大規模検索ファーム用の最低限のハードウェア リソース
各アプリケーション サーバーまたはデータベース サーバーに必要なハードウェア リソースの最小量を次の表に示します。 このサンプル ファームは、SharePoint Server 2016 でのみ構築できます。
| サーバー | 稼働するホスト | ストレージ | RAM | プロセッサ1 | ネットワークの帯域幅 |
|---|---|---|---|---|---|
| インデックス コンポーネントを備えたアプリケーション サーバー。 | A-X | 500 GB | 32 GB | 1.8 GHz 8x CPU コア | 1 Gbps |
| クエリ処理コンポーネントとインデックス コンポーネントを備えたアプリケーション サーバー。 | Y、Z | 500 GB | 32 GB | 1.8 GHz 8x CPU コア | 1 Gbps |
| クロール、検索管理、またはコンテンツ処理コンポーネントを備えたアプリケーション サーバー | AA-AF | 100 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| 分析処理コンポーネントを備えたアプリケーション サーバー | AG、AH | 800 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| 検索データベースを備えたデータベース サーバー | AI-AL | 500 GB | 16 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
1 ここで指定しているのは、CPU スレッドの数ではなく、CPU コアの数です。
ストレージ パフォーマンスの計画
ストレージの速度は検索のパフォーマンスに影響します。 ご使用のストレージが、検索コンポーネントおよびデータベースからのトラフィックを処理するのに十分な速度であることを確認してください。 ディスク速度は、IOPS (1 秒あたりの I/O 操作数) で測定されます。
検索コンポーネントおよびストレージのオペレーティング システムからデータをどのように分散するかによって、検索パフォーマンスに影響が出ます。 以下のようにすることをお勧めします。
Windows Server オペレーティング システム ファイル、SharePoint Server プログラム ファイル、および診断ログは、通常のパフォーマンスの 3 つの別個のストレージ ボリュームまたはパーティションに分割します。
検索コンポーネントのデータは、高パフォーマンスの別個のストレージ ボリュームまたはパーティションに保存します。
注:
SharePoint Server をホストにインストールするときに、検索コンポーネント データのカスタムの場所を設定できます。 ホスト上の検索コンポーネントは、データを保存する必要がある場合、この場所に保存します。 この場所を後で変更するには、そのホストに SharePoint Server を再インストールする必要があります。
ストレージを選択する
ストレージ アーキテクチャとディスクの種類の概要については、「記憶域とSQL Server容量の計画と構成 (SharePoint Server)」を参照してください。 インデックスまたは分析処理コンポーネントまたは検索データベースをホストするサーバーには、待機時間を短く維持しながら、1 秒あたりの十分な I/O 操作 (IOPS) を提供できるストレージが必要です。 以下の表は、これらの検索コンポーネントおよびデータベースの各々で必要とされる IOPS 数を示しています。
SAN/NAS などの共有ストレージを展開する場合、通常 1 つの検索コンポーネントのピーク ディスク負荷が別の検索コンポーネントのピーク ディスク負荷と同時に発生します。 共有ストレージから検索が必要とする IOPS 数を取得するには、これらのコンポーネントそれぞれの IOPS 要件をまとめる必要があります。
検索コンポーネントの IOPS 要件
| コンポーネント名 | コンポーネントの詳細 | IOPS 要件 | 別々のストレージ ボリューム/パーティションの使用 |
|---|---|---|---|
| インデックス コンポーネント | インデックスの結合時およびクエリの処理および応答時にストレージを使用します。 | 64 KB のランダム読み取りに 300 IOPS。 256 KB のランダム書き込みに 100 IOPS。 順次読み取りに 200 MB/s。 順次書き込みに 200 MB/s。 |
はい |
| 分析コンポーネント | データをローカルで一括処理で分析します。 | いいえ | はい |
| クロール コンポーネント | ダウンロードされたコンテンツをコンテンツ処理コンポーネントに送信する前にローカルに保存します。 ストレージはネットワーク帯域幅に制限されます。 | いいえ | はい |
検索データベースの IOPS 要件
| データベース名 | IOPS 要件 | I/O サブシステムでの一般的な負荷。 |
|---|---|---|
| クロール データベース | 中～高レベルの IOPS | 1 DPS (1 秒あたりのドキュメント) クロール レートあたり 10 IOPS |
| リンク データベース | 中速度の IOPS | 検索インデックスにおいて 100 万アイテムにつき 10 IOPS。 |
| 検索管理データベース | 低速度の IOPS | なし。 |
| 分析レポート データベース | 中速度の IOPS | なし。 |
検索アーキテクチャがどのように高可用性をサポートするかを選択する
高可用性の戦略について理解できていない場合には、はじめに「SharePoint Server の高可用性のアーキテクチャと戦略を作成する」の記事をお読みください。 冗長検索コンポーネントおよびデータベースを別々の障害ドメインでホストする場合には、検索アーキテクチャで高可用性がサポートされます。 サンプルの検索アーキテクチャはすべて、独立したサーバーで冗長検索コンポーネントをホストします。
検索アーキテクチャの各冗長ホスト サーバーには、次のものを設置するよう計画する必要があります。
冗長ネットワーク
独立した書き込みのある冗長電源または UPS (無停電電源装置)。
手順 4: 検索アーキテクチャが正常に機能していることをどのように確認するか。
検索アーキテクチャを運用環境に展開する前に、正常に機能するかどうかを確認する必要があります。 確認する内容のチェックリストは次のとおりです。
インデックス コンポーネントが十分な IOPS のあるストレージ I/O サブシステムを使用していることをテストします。 「ストレージ I/O サブシステムをテストする」をご覧ください。
検索アーキテクチャをパイロット環境に展開します。 パイロット環境は、運用環境の典型となるようにします。
パイロット環境の検索パフォーマンスをテストします。 「検索パフォーマンスをテストする」をご覧ください。
SharePoint での一般的なテストの概要については、「 SharePoint Server 2013 のパフォーマンス テスト」を参照してください。
ストレージ I/O サブシステムをテストする
ストレージ I/O サブシステムをテストするには、もっとも重要なディスク操作を実行して IOPS を測定します。 DiskSpd ツールを使用して、これらのテストを実行できます。 「DiskSpd: 堅牢なストレージ パフォーマンス ツール」を参照してください。
テスト環境を設定する
検索アーキテクチャ全体を設定したり、SharePoint Server をインストールしたりする必要はありません。 ストレージ I/O サブシステムの現実的なワークロードを生成するテスト環境を設定すれば十分です。
ローカル ストレージの場合を考えてみます。 たとえば、中規模検索ファームのホスト A がローカル ディスクを使用する場合、2 台の仮想マシンを設置して、両方の仮想マシンで同時にディスク操作テストを実行する必要があります。
共有ストレージには、別の設定が必要です。 たとえば、中規模検索ファームのすべてのインデックス コンポーネントからのワークロードと、他の関連性のないワークロードとが同じストレージを共有する場合には、次のようにする必要があります。
ホスト A、B、C、および D に 8 台の仮想マシンを設置し、関連性のないワークロードのソースを設定します。
ホスト A、B、C、および D のすべての仮想マシンで同時ディスク操作テストを実行するのと同時に、関連性のないワークロードが共有ストレージに適用されるようにしてください。
テスト ファイルを作成する
コマンドを使用して、256 GiBytes テスト ファイルを作成します
diskspd -c256G testfile。 このコマンドは、"testfile" という名前の 256 GiBytes サイズのファイルを作成します。 構文に従って、別のサイズのファイルを作成することもできます。diskspd -c<size>[K|M|G|b] <filename>テストするストレージ デバイスにこのテスト ファイルを保存します。 たとえば、中規模ファームのホスト A のハード ディスクなどに保存します。
サーバーを再起動します。 こうすることで、キャッシュによりテスト結果に歪みが生じないようにします。
テストを実行する
次のものを測定することをお勧めします。
中規模サイズのランダム アクセスのパフォーマンス (下記のテスト番号 1 および 2 を参照)。
大規模転送の読み取りおよび書き込みスループット (下記のテスト番号 3 および 4 を参照)。
次の表は、各テストの実行に使用する必要がある DiskSpd コマンドを示しています。 これらのコマンドはすべて、「testfile」が現在のディレクトリにあることを想定しています。 各テストは 300 秒間実行されます。
| テスト番号 | 範囲 | command |
|---|---|---|
| 1 | 64 KB の読み取り [IOPS] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | 256 KB の書き込み [IOPS] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | 100 MB の読み取り [MB/s] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | 100 MB の書き込み [MB/s] | diskspd -t1 -o1 -b100M -r -w100 -d300 testfile |
ローカル ディスク ストレージの結果例
下記の表のサンプル結果は、ディスク サブシステム容量の少なくとも 50% がテスト ファイルの追加前に使用されていた展開を示しています。
ディスク コントローラーおよびディスクのスピンドルがこれらの結果に大きく影響します。
空のディスクでテストした場合、テスト ファイルはすべてのスピンドルのなかで最適なトラック (ショート ストローク) に置かれるため、高い結果が得られます。 これにより、最大 2 ～ 3 倍までパフォーマンスを向上できます。 初期化されていないストレージ領域 またはすべてゼロを含むストレージ (たとえば、動的 VHD/VHDX ファイルなど) へのアクセスを最適化により除去するハード ディスクをテストした場合、非現実的なほど高い結果が得られます。 この場合は、DiskSpd コマンドを使用して合成テスト ファイルを生成するのではなく、実際のデータを含む非常に大きなテスト ファイルを使用します。
| ディスク レイアウト | テスト 1 | テスト 2 | テスト 3 | テスト 4 | |
| 通常の操作の間の推奨最小 IOPS | 300 | 100 | 200 | 200 | |
| Dell H710 RAID コントローラー の RAID5 の 4x 1 TB 7200 RPM NLSAS (64 KB ストライプ サイズ、64 KB ブロック サイズ) | 1181 | 206 | 284 | 296 | |
| Dell H710 RAID コントローラー の RAID5 の 8x 1 TB 7200 RPM NLSAS (64 KB ストライプ サイズ、64 KB ブロック サイズ) | 2082 | 337 | 610 | 645 | |
| Dell H710 RAID コントローラー の RAID5 の 16x 1 TB 7200 RPM NLSAS (64 KB ストライプ サイズ、64 KB ブロック サイズ) | 3763 | 595 | 1173 | 1181 | |
| Dell H710 RAID コントローラー の RAID50 (2x8) の 16x 1 TB 7200 RPM NLSAS (64 KB ストライプ サイズ、64 KB ブロック サイズ) | 3613 | 545 | 1139 | 1164 | |
| Dell H710 RAID コントローラー の RAID10 の 16x 1 TB 7200 RPM NLSAS (256 KB ストライプ サイズ、64 KB ブロック サイズ) | 4030 | 1146 | 970 | 775 | |
| Dell H710 RAID コントローラー の RAID5 の 4x SmartStorage Optimus 800GB SSD (64 KB ストライプ サイズ、64 KB ブロック サイズ) | 32385 | 3781 | 1714 | 1319 | |
| Dell H710 RAID コントローラー の RAID0 の 4x SmartStorage Optimus 800GB SSD (256 KB ストライプ サイズ、64 KB ブロック サイズ) | 31747 | 7149 | 1643 | 1798 |
検索パフォーマンスをテストする
検索アーキテクチャのテスト方法のチェックリストは次のとおりです。
テストを実行するコンテンツを選択する
運用コンテンツをよく表しているコンテンツを選択します。 テストの目的のためだけにあるコンテンツを選択する場合、何度も複製した 1 つだけのアイテムではなく、さまざまなタイプのアイテムがあることを確認してください。 これは、クエリ プロセッサが複製されたアイテムの検出に時間をかけてしまうことで、検索パフォーマンスに影響を及ぼし、結果が運用環境の典型にならなくなるためです。
コンテンツをクロールするには 1 つ以上のコンテン ツソースを設定してください。 必要なユーザー アカウントおよびネットワーク アクセスがあることを確認します。
クエリ パフォーマンスをテストする用語および語句を選択する
クエリに対して取得する結果数を再現性といいます。
クエリのパフォーマンスをテストするには、クエリとして使用する用語と語句のセットを最初に作成する必要があります。 または、既存のインストールからクエリを収集します。 このセットには、低い再現性と高い再現性を持つ用語と語句が含まれ、この用語と語句はご使用の環境に関連するものであることを確認してください。
例
製品カタログの製品番号を検索する場合、1 つの製品に対して番号は 1 つのみであることが多いです。 そのため、検索結果を速く取得できます。 これは低い再現性です。
会社のイントラネットで「プレゼンテーション」という一般的な用語を検索した場合、多くの結果が取得され、取得には時間がかかることが多いです。 これは高い再現性です。
たとえば、コンテンツが人事に関するものの場合、この分野に関係する検索用語を使用してください。
検索パフォーマンスを測定する
SharePoint Server は、クロール正常性レポートとクエリ正常性レポートで検索パフォーマンスの測定値を収集します。 これらのレポートは、サーバーの全体管理 の [検索管理] にあります。
最初に合成負荷で検索パフォーマンスを測定してから、運用中のユーザーおよび運用中のコンテンツの小さいセットで測定することをお勧めします。 運用中のユーザーおよび運用中のコンテンツを使用すると、検索アーキテクチャがどのように実行しているかを監視できます。 コンテンツが予想よりも速く増加する場合には、次のサイズの検索アーキテクチャを使用することを検討するとよいでしょう。 または、ユーザーが予想よりもアクティブな場合は、分析データベースのストレージ領域の量を増やすことをお勧めします。