大きなリストを設計し、リストのパフォーマンスを最大限に高める (SharePoint Server 2010)
適用先: SharePoint Server 2010
トピックの最終更新日: 2016-11-30
この記事では、大規模なドキュメント ライブラリと大規模なリストのパフォーマンスについて説明します。この記事で示す推奨事項は、Microsoft SharePoint Server 2010 で実施したパフォーマンス テストの結果に基づいています。この記事では、大規模なリストのパフォーマンス上の特性と、大規模なリストやファームのパフォーマンスに構成が及ぼす影響を中心に説明します。SharePoint Server 2010 では、いくつかの新しい機能強化によって、大規模なリストの作成と使用が容易になりました。それでも、大規模なリストの作成と実装には入念な計画が必要です。情報アーキテクチャ、パフォーマンス、障害復旧、ガバナンスなど多くの要素について検討する必要があります。この記事では、大規模なリストの実装に使用する情報アーキテクチャと機能、および特定の構成がパフォーマンスに及ぼす影響について説明します。
大規模なリストのパフォーマンスは、設計上の重要な選択肢からも影響を受けます。権限、リストに追加する列の数、ビューのルックアップ列の数、リストを整理するフォルダーとインデックスなどです。これらの決定はリストのパフォーマンスに影響し、リストのサイズが大きくなるほどその影響も大きくなります。この記事では、さまざまな設計上の選択によって大規模なリストのパフォーマンスがどのように変わるかについて説明し、パフォーマンス要件を満たすと同時にビジネス要件も満たし、良好なユーザー エクスペリエンスを提供する大規模なリストを適切に設計する方法を示します。
この記事の対象は SharePoint Server 2010 に限定されますが、調整と制限については Microsoft SharePoint Foundation にも適用されます。この記事では大規模なリストの処理を大幅に向上させる各種機能について説明しますが、これらの機能は SharePoint Server 2010 でのみ使用できます。この記事では、SharePoint Foundation と SharePoint Server を区別していません。
この記事の内容:
クエリ方法について
大規模なリストのシナリオ例
大規模なリストと SharePoint Server 2010
パフォーマンス測定とテスト方法
調整と制限
その他の制限
大規模なリストと通常のリストの相違点
大規模なリストの設計と実装
まとめ
クエリ方法について
リストのデータにアクセスする手段は、主に 3 つあります。リスト ビューとメタデータ ナビゲーション、コンテンツ クエリ Web パーツ、および検索です。それぞれに長所と短所があり、用途に応じて使い分けます。
リスト ビューとメタデータ ナビゲーション
リスト ビューは、常に Microsoft SQL Server データベースにアクセスします。したがって、他の方法よりクエリ パフォーマンスは遅くなり、SQL Server リソースへの負荷は高くなります。リスト ビューでは、レンダリングする HTML が最も多いので、他の方法よりページの読み込み時間が長くなります。ビューの構成、データの動的フィルター処理、ドキュメントの操作 (バージョン管理、プロパティ編集など) を行うユーザー エクスペリエンスは、リスト ビューが最適です。メタデータ ナビゲーションを利用すると、リスト ビューの結果をフィルター処理できます。詳細な列データやリスト アイテム アクションを使用する必要がある場合は、リスト ビューを使用してください。読み込みやクエリが大量に発生するシナリオでは、他の方法を使用することを検討してください。
コンテンツ クエリ Web パーツ
コンテンツ クエリ Web パーツは、ポータル サイト マップ プロバイダーを使用してキャッシュされたデータを静的な構成のビューに表示してパフォーマンスを向上させます。コンテンツ クエリ Web パーツでは、レンダリングする HTML が最も少なく、HTML はキャッシュされます。その結果、ページの読み込み時間が短くなり、1 つのページで複数のクエリを行うことが容易になります。関連するリスト アイテム、ドキュメント、またはページへのリンクを表示するには、コンテンツ クエリ Web パーツを使用してください。コンテンツ クエリ Web パーツは、キャッシュしないように構成することもできますが、そのような構成は、スループット要件が低いページや、ページにアクセスするユーザーに応じてクエリが変化する場合などキャッシュの有効性がないページにのみ使用してください。
検索
検索 Web パーツを使用すると、(プロパティの編集やリアル タイムの更新表示ではなく) コンテンツの検索に最適化されたシステムへクエリの負荷を移すことができます。検索 Web パーツは、静的クエリまたはユーザー指定のクエリを使用するように構成できます。検索 Web パーツのパフォーマンスは良好です。ただし、データは最後にクロールした時点のものに限られます。したがって、結果はリスト ビューやコンテンツ クエリ Web パーツの結果より古くなります。
大規模なリストのシナリオ例
大規模なリストを使用する一般的なシナリオがいくつかあり、設計上の各種決定はそのようなシナリオに基づいて行います。たとえば、共同作業用の大規模なリストのシナリオでは、ユーザーはコンテンツの追加とプロパティの更新を頻繁に行います。このようなシナリオでは、リストが何百万アイテムという大きさにならないようにする必要があります。コンテンツの更新や変更が多く、コンテンツのフィルター処理が困難になるからです。構造化されていないドキュメント ライブラリを操作する場合、SQL Server のパフォーマンスを維持するために、この記事で説明する調整と制限が役立ちます。大規模なリストのシナリオの考慮事項を次の表に示します。
| シナリオ | リスト サイズ | 管理 | 読み取り/更新/追加の比率 | 新しいコンテンツ | ユーザー数 |
|---|---|---|---|---|---|
構造化されていないドキュメント ライブラリ |
数百 |
マネージャーなし |
読み取りは大量、追加と更新は均等 |
手動アップロード |
数十 |
共同作業用の大規模なリストまたはライブラリ |
数千 |
非公式のサブジェクト オーナー |
読み取りは大量、追加より更新が多い |
手動アップロード |
数百 |
構造化された大規模なリポジトリ |
数万 |
専任のコンテンツ担当者 |
読み取りは非常に大量、追加は少量、更新は非常に少量 |
送信とアップロード |
数万 |
大規模なアーカイブ |
数百万 |
コンテンツ担当チーム |
読み取りと更新は少量、追加は大量 |
送信 |
数万 |
構造化されていないドキュメント ライブラリ
構造化されていないドキュメント ライブラリは、チームやワークグループで使用されることが多く、通常、数十個から数百個のドキュメントが含まれます。このようなライブラリは、無計画なままリスト ビューのしきい値を超えやすく、列の追加などの操作に影響することがあります。ビューのアイテムが 5,000 個を超えた場合にリスト ビューのしきい値の例外が発生する可能性もあります。これを防ぐには、リスト ビューのしきい値に近づいているライブラリを監視します (ドキュメント ライブラリのライブラリ設定ページに、リスト ビューのしきい値に近づいていることを示すメーターを表示します)。
通常、このシナリオのユーザーは数十人から数百人ですが、同時実行ユーザーはほとんどいません。したがって、1 つのライブラリ内の負荷が問題になることはほぼありません。ただし、このようなライブラリが多数存在する可能性があります。特定の状況へのサポートを計画するより、このようなライブラリが多数存在する場合のサポートに重点を置くことが重要です。
共同作業用の大規模なリストまたはライブラリ
共同作業用の大規模なリストは、数百個から数千個のアイテムが含まれ、大量のアクティブ コンテンツの保存に使用されます。一般的な共同作業用の大規模なリストとしては、ナレッジ マネジメント ソリューション、エンジニアリング ライブラリ、セールスとマーケティング関連のリポジトリなどがあります。ユーザーは頻繁にコンテンツを追加、編集します (大量の読み取り操作と書き込み操作が発生します)。ライブラリを整然と維持するには、構造と管理を投入します。ただし、多くの作業がユーザーによって実行されるので、管理者の制御が及ばない事態が発生する可能性もあります。そのため、リストが予想以上に急速に大きくなったり、計画していた制限を超えたりしやすくなります。このようなリポジトリのユーザーは数百人から数千人、同時実行ユーザーは数十人から数百人です。
構造化されたリポジトリやアーカイブと比べ、共同作業用の大規模なリストでは、フォルダーの追加と削除、コンテンツ タイプと列の追加、コンテンツの再編成など管理上の変更が発生しやすくなります。このような操作は、リストのサイズに基づいてリスト ビューのしきい値で防ぐことができます。
構造化された大規模なリポジトリ
構造化された大規模なリポジトリには、数千個から数十万個のアイテムが含まれます。通常、コンテンツは最終版であり、ユーザーまたはワークフローなどのシステム プロセスから送信されます。構造化された大規模なリポジトリは、部門別レコード アーカイブ、重要な文書の保管、Web ページに表示されるドキュメントの最終版などに使用されます。一般に、コンテンツは構造化されて高度に管理されるので、リスト サイズ増加の管理は容易です。このシナリオの同時実行ユーザーは数十人から数百人、ユーザー総数は数千人です。読み取りの比率が書き込みより大幅に多くなります。ただし、コンテンツの更新もあり、コンテンツが頻繁に追加および削除される場合もあります。構造化された大規模なリポジトリの例として、部署や組織のナレッジ マネジメント リポジトリがあります。
このシナリオでは、ユーザーのニーズを十分に理解し、ソリューションの運用前に包括的なテストを実施することが重要です。したがって、大量のコンテンツを格納する前に、ソリューションを十分に完成させておきます。たとえば、コンテンツの適切なブラウズ操作を提供するには、適切なメタデータ ナビゲーション階層およびフィルターを構成しておくことが必要です。
大規模なアーカイブ
大規模なアーカイブでは、1 つのリストまたは複数のリストに、あるいは最大級では複数のサイト コレクションに、数千個から数百万個のアイテムが含まれます。一般に、このシナリオは読み取りと更新が少なく、法令遵守やその他の目的で長期保管が必要なドキュメント (法令で 7 年間の保管が義務付けられている文書など) を保存する目的でのみ使用されます。このシナリオでは、ドキュメントの送信および削除のスループットが高いことが重要です。コンテンツを取得する主な手段は検索になります。
大規模なリストと SharePoint Server 2010
Office SharePoint Server 2007 で大規模なリストに利用できた機能は SharePoint Server 2010 でも利用でき、その多くは強化されて大規模なリストに提供されるパフォーマンスが向上しています。SharePoint Server 2010 では、大規模なリストのパフォーマンスとユーザー操作の効率を向上させる多くの新機能も追加されています。このセクションでは、SharePoint Server 2010 の新機能と機能強化について説明します。
機能強化
次の各セクションでは、Microsoft Office SharePoint Server 2007 から強化された SharePoint Server 2010 の機能について説明します。
コンテンツ クエリ Web パーツ
コンテンツ クエリ Web パーツは、リスト、コンテンツ タイプ、および列をフィルター処理した結果を表示するように構成できます。結果を並べ替えたり、表示する列を選択したりできます。このようにして、コンテンツ クエリ Web パーツでは、大規模なリストのコンテンツを最適な形式で Web ページに表示できます。通常、コンテンツ クエリ Web パーツはキャッシュされます。これによって、ページの読み込みは高速になり、データベースの読み込みは少なくなります。たとえば、ナレッジ マネジメント シナリオでは、Web ページのコンテンツに関連するドキュメントへのリンクを表示するページの発行にコンテンツ クエリ Web パーツを使用できます。
SharePoint Server 2010 では、主に次のようなシナリオのパフォーマンスが強化されます。
単一リスト クエリの最適化によるインデックスの有効利用の向上
無効化および更新のアルゴリズムと既定の設定の強化によるユーザーの書き込み操作中のキャッシュ使用率向上
検索
SharePoint Server 2010 では、検索語句絞り込みパネルなどの新しい検索機能が導入され、1 億個のドキュメントを 1 秒未満のクエリ待機時間で処理できるようにスケーラビリティが強化されました。SharePoint Server 2010 Search より大きな規模ポイントを実現できる Microsoft FAST Search Server 2010 for SharePoint もあります。
大規模なリストのコンテンツの検索に役立つ新しい機能強化として、フリー テキスト クエリのブール演算子サポート、次の値に等しい、次の値より小さい、次の値より大きいなどの演算子サポート強化、範囲の絞り込み、キーワードとプロパティの前方一致などがあります。たとえば、"share*" というクエリの検索結果には "SharePoint" が含まれます。ユーザーの入力に応じてクエリの候補が提示されるクエリ候補機能もあります。検索のユーザー インターフェイスも、関連検索、おすすめコンテンツ、関連ユーザー、キーワード絞り込みなどのパネルで強化されました。
SharePoint Server 2010 Search では、スケーリング関連機能も強化されました。SharePoint Server 2010 Search では、インデックス サーバー、クロール サーバー、およびクエリ サーバーのスケール アウトがサポートされます。また、インデックスの更新頻度、復元性、可用性も向上しました。FAST Search Server 2010 for SharePoint には、SharePoint Server 2010 Search の全機能のほか、超大規模に対応するスケーリング、エンティティ抽出、調整可能な関連性ランク、ビジュアルおすすめコンテンツ、縮小表示、プレビューなどの追加機能もあります。
ドキュメント センターとレコード センターのサイト テンプレート
SharePoint Server 2010 のドキュメント センターとレコード センターのサイト テンプレートは、構造化されたリポジトリの作成に利用できます。ドキュメント センター サイト テンプレートには、ログイン ユーザー別に関連結果を返す構成済みのコンテンツ クエリ Web パーツ、メタデータ ナビゲーションが構成されているドキュメント ライブラリなどの機能が含まれています。
レコード センター サイト テンプレートは、ドキュメント センター サイト テンプレートと似ていますが、ドキュメントをルーティングできるコンテンツ オーガナイザー機能と、追加するアイテムが自動的にレコードとして宣言されて削除できなくなるレコード ライブラリを備えています。レコード センター サイト テンプレートは、組み込みサイト テンプレートのうちドキュメント解析が有効になっていない唯一のテンプレートであり、送信されるコンテンツの再現性が維持されます。ドキュメント解析が無効になっていると一部の操作のパフォーマンスが向上するので、他のサイト テンプレートより大規模ドキュメント ストレージ (数千万個のアイテム) に適しています。
新機能
このセクションでは、大規模なリストの管理とパフォーマンスに役立つ SharePoint Server 2010 の新機能について説明します。
コンテンツ オーガナイザー
コンテンツ オーガナイザーは、コンテンツを特定のドキュメント ライブラリ、フォルダー、または他のサイトにルーティングするサイトに使用できます。コンテンツ オーガナイザーを使用すると、メタデータ プロパティに基づいてコンテンツのフォルダーが自動的に作成されます。ユーザーは他のサイトからコンテンツをコンテンツ オーガナイザーに送信するだけで済み、そのコンテンツをファイル プラン内のどこへ保存すればよいかを気にする必要はありません。コンテンツ オーガナイザーを使用すると、コンテンツを複数のフォルダーに振り分け、各フォルダーの最大サイズを自動的に管理できます。指定したサイズの上限に達すると、追加アイテムを格納する新しいサブフォルダーが作成されます。
メタデータ ナビゲーション
メタデータ ナビゲーションは、ユーザーがリストを動的にフィルター処理して必要な要素を見つけられるようにする SharePoint Server 2010 の新しい機能です。メタデータ ナビゲーションは、ユーザーによるフィルター オプションの選択を可能にし、実行できる最も効率的な方法でのクエリの実行を処理します。メタデータ ナビゲーションは 2 つの部分で構成されます。1 つは、ユーザーがナビゲーション階層とキー フィルターを持つリストをフィルター処理できるようにするナビゲーション コントロールのセットです。もう 1 つは、クエリの再配置と再試行を行うためのメカニズムです。
メタデータ ナビゲーションには、インデックスを使用したクエリの効率的な実行を試みる再試行およびフォールバックのロジックがあります。クエリの返す結果が多すぎる場合、クエリはフォールバックし、パフォーマンス向上のために結果のサブセットを返します。適切なクエリを実行できない場合は、フォールバックが発生し、制限された結果のセットに対してフィルターが実行されます。メタデータ ナビゲーションは、インデックスを自動的に作成します。再試行、フォールバック、およびインデックス管理の組み合わせにより、メタデータ ナビゲーションは大きなリストを効果的に操作するうえで非常に重要な部分になっています。フィルター処理のメカニズムには、ナビゲーション階層とキー フィルターの 2 種類があります。
ナビゲーション階層では、ツリー コントロールを使用して、フォルダー、コンテンツ タイプ、選択フィールド、または管理されたメタデータの用語セットの階層内を移動します。これにより、ユーザーはツリー コントロールを使用して、フォルダー間を移動するように、メタデータ階層に従った移動ができます。ユーザーが管理されたメタデータ列のある階層でアイテムを選択すると、指定の用語、またはその下位にある子の用語に一致するすべてのアイテムが表示されます。これは子孫包含と呼ばれ、管理されたメタデータの用語セットに関連付けられているフィールドで使用できます。ユーザーはそのアイテムを再度選択することで、下位の子の用語を含めずに対象の用語のみに対してフィルター処理を実行できます。すべてのメタデータ ナビゲーション クエリは再帰的に処理され、リスト内のすべてのフォルダーから結果を取得して表示します。
キー フィルターは、階層内の結果に対して追加のフィルター処理を実行するように構成できます。たとえば、[更新者] 列をキー フィルターとして追加してユーザー名を入力すると、[更新者] が入力したユーザーに一致する結果を取得できます。詳細については、「メタデータ ナビゲーションとフィルター処理」(https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x411) を参照してください。次の図に、メタデータ ナビゲーション階層とキー フィルターの例を示します。
.gif "キー フィルター リストのスクリーンショット")
Managed Metadata Service
管理されたメタデータは、情報アーキテクチャに関するより多くの機能を SharePoint Server に追加する機能の新たなセットです。管理されたメタデータの機能には、Managed Metadeta Service という共有サービスが含まれます。Managed Metadeta Service は、SharePoint Server 2010 展開内の全域で再利用できる用語セットを格納するために使用できます。以下に、管理されたメタデータの機能の一部を示します。
フラットまたは深い階層をサポートする用語セット
用語セットを利用可能なプロパティとして使用する管理されたメタデータの列の種類
だれでも新しい用語を追加できるようにオープンにしたり、特定のユーザーのみが用語セットを管理できるように制限したりできる用語セット
管理されたメタデータの列および用語セットを使用してコンテンツを構成すると、コンテンツ クエリ Web パーツやメタデータ ナビゲーションといった機能を活用して、ユーザーによるコンテンツの検索や探索を支援できます。また、管理されたメタデータは、ドキュメントの分類に使用できるキーワードを追加するため、通常の検索クエリにも役立ちます。管理されたメタデータは、検索絞り込みパネルで使用できます。次の図に、管理されたメタデータ ナビゲーションの例を示します。
.gif "用語のスクリーンショット")
調整と制限
SharePoint Server 2010 には、ファームのパフォーマンス管理に役立つ構成可能な制限がいくつか導入されています。Web アプリケーションのレベルでは、構成可能な調整および制限が導入されています。これらは、個々のユーザーまたはプロセスからの操作がファームのパフォーマンスに悪影響を及ぼすことがないように追加されたものです。たとえば、リスト ビューのしきい値は、一定の数を超えるリスト アイテムに影響を与えるクエリを回避するための制限値です。
複合インデックス
インデックスは、リストが大きい場合に重要になります。SharePoint Server 2010 では、複合インデックスを作成できるようになりました。複合インデックスは、1 つの列のみに対するクエリでは十分な選択が行えない可能性があるという理由で、同じクエリが 2 つの列に対して実行される場合に便利です。複合インデックスは、ビューでは利用されませんが、メタデータ ナビゲーションで利用されます。調整の条件が発生した場合、メタデータ ナビゲーションのロジックでは、再試行を行い、選択されたフィルター条件に対して適用可能な複合インデックスと単一インデックスを使用して、クエリを満たす完全または部分的な結果を検索できます。
開発者ダッシュボード
開発者ダッシュボードは、それぞれのページ読み込みについて詳細な診断情報を表示します。このダッシュボードは、既定ではオフになっています。ただし、手動でオンにしたり、ダッシュボードを常に表示するように構成したりできます。開発者ダッシュボードがオンになっている場合は、これを使用してデータベース クエリ、読み込み時間、およびエラーに関する情報を取得できます。開発者ダッシュボードを使用すると、パフォーマンスの問題の迅速な分析および診断が容易になります。次の図に、開発者ダッシュボードを示します。メタデータ ナビゲーションの機能は、リストのサイズが大きくて調整の条件が発生した場合に開発者ダッシュボード内に表示されます。その場合は、再試行に使用されるインデックスのリストと部分的な結果が左側の操作ツリーに表示され、試行された各種のインデックス付き SQL Server クエリが右側のリストに表示されます。
.gif "開発者ダッシュボードのスクリーンショット")
開発者ダッシュボードは、カスタム Web パーツおよびクエリのデバッグにも有用です。開発者ダッシュボードを有効にする方法の詳細については、「Blog: Enable the Developer Dashboard using the Object Model / Powershell (英語)」(https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x411) (英語) を参照してください。
コンテンツ反復子
コンテンツ反復子に関する開発者向け API は、大きなリストに対するコードの記述を簡素化し、新しいリスト ビューしきい値の制限で特に重要になります。コンテンツ反復子は、データのセット全体に対して操作を実行するのではなく、コンテンツの小さなセットに対して操作を実行するためにコンテンツを取得する手法です。これにより、リスト ビューのしきい値を超えるような操作を回避できます。
リモート BLOB ストレージ
既定では、SharePoint Server 2010 はファイル (バイナリ ラージ オブジェクト (BLOB)) データを SQL Server データベースに格納します。通常、コンテンツ データベースの多くは BLOB データです。リモート BLOB ストレージ (RBS) を使用すると、こうしたデータを SQL Server の外側に格納できます。これにより、より安価な記憶域の選択やコンテンツ データベース サイズの削減が可能になります。リモート BLOB ストレージは、SQL Server 2008 のアドオン機能パックとして組み込まれているライブラリ API セットです。リモート BLOB ストレージ API を利用するには、サードパーティ製のリモート BLOB ストレージ プロバイダーが必要です。
パフォーマンス測定およびテストの方法
このセクションでは、この記事で解説しているテストで使用したテスト方法を説明します。この方法から逸脱した点については、データの提示箇所で説明します。
ハードウェアとファームの構成
テスト用ファームの構成を以下の図および表に示します。このテスト用の構成は、2 つの点で現実にあるほとんどの展開と大きく異なっていました。具体的には次のとおりです。
ドメイン コントローラーがボトルネックになるのを避けるために NTLM 認証を使用しました。その結果、パフォーマンスがいくらか向上しています。
アプリケーション サーバーには、ログ記録用のデータベースで使用される SQL Server インスタンスが含まれていました。これは、ログ記録のレベルが現実の展開よりもずっと高いため、メインの SQL Server インスタンスに対する負荷を軽減するための措置です。
.gif "このテスト ファームのトポロジの図")
| コンピューター名 | 2 台の Web サーバー | 1 台のアプリケーション サーバー | 1 台のデータベース サーバー |
|---|---|---|---|
役割 |
フロントエンド Web サーバー |
アプリケーション サーバー |
SQL Server インスタンス |
プロセッサ |
2px4c@2.33 GHz |
2px4c@2.33 GHz |
4px2c@3.19 GHz |
RAM |
8 GB |
8 GB |
32 GB |
オペレーティング システム |
Windows Server 2008 R2 x64 |
Windows Server 2008 R2 x64 |
Windows Server 2008 R2 x64 |
記憶域とその配置 (SQL Server ディスク構成を含む) |
50 + 18 + 205 GB |
50 + 18 + 300 GB |
ディスク アレイ - 450 GB @ 15 K RPM のディスク 15 基 |
NIC の数 |
2 |
2 |
2 |
NIC の速度 |
1 ギガビット |
1 ギガビット |
1 ギガビット |
認証 |
NTLM |
NTLM |
NTLM |
ソフトウェアのバージョン |
SharePoint Server 2010 (プレリリース版) |
SharePoint Server 2010 (プレリリース版)、 SQL Server 2008 CTP 3 |
SQL Server 2008 CTP 3 |
SQL Server インスタンスの数 |
該当なし |
1 |
1 |
負荷分散の種類 |
ハードウェア |
該当なし |
該当なし |
出力キャッシュ設定 |
|
|
|
オブジェクト キャッシュ設定 |
|
|
|
BLOB キャッシュ設定 |
|
|
|
ULS ログ レベル |
中 |
中 |
中 |
利用状況データベースの場所 |
|
X |
|
利用状況データベースの設定 (ログの対象) |
|
|
|
IRM の設定 |
なし |
なし |
なし |
ウイルス対策の設定 |
なし |
なし |
なし |
| データベースの種類 | データベースの数 | RAID 構成 |
|---|---|---|
一時データベース |
1 |
0 |
構成データベース |
1 |
0 |
コンテンツ データベース #1 |
1 |
0 |
プロファイル データベース |
1 |
0 |
検索データベース |
1 |
0 |
分類データベース |
1 |
0 |
テストの負荷
テストは、最適な負荷のポイント (グリーン ゾーン) で、操作の一般的な組み合わせを使用して実施しました。特定の変化を測定するために、変数が変化するポイントごとにテストを実施しました。最適な負荷のポイントを見つけるために、余分なスレッドを追加して、以下の基準を満たしつつ環境を飽和状態にしました。
遅延の 75 パーセンタイル値が 1 秒未満
フロントエンド Web サーバーの CPU 使用率が 50% 未満
SQL Server の CPU 使用率が 50% 未満
アプリケーション サーバーの CPU 使用率が 50% 未満
障害発生率が 0.01% 未満
テストの定義
次の表に、テストの定義内容と、各テストで使用したプロセスの概要を示します。
| テスト名 | テストの説明 |
|---|---|
ドキュメントのアップロード |
ドキュメントをアップロードします。 ドキュメントのプロパティを編集および更新します。 |
ドキュメントのアップロードとルーティング |
ドキュメントをアップロードします。 ドキュメントのプロパティを編集および更新します。 ルーティング ルールに一致するドキュメントのルーティングを行います。 |
ドキュメントのダウンロード |
ドキュメントをダウンロードします。 |
ドキュメント ライブラリへのアクセス |
ドキュメント ライブラリのリスト ビュー ページにアクセスします。 |
コンテンツ クエリ Web パーツのあるホーム ページへのアクセス |
3 つのコンテンツ クエリ Web パーツを持つドキュメント センター サイトのホーム ページにアクセスします。 キャッシュされたコンテンツ クエリ Web パーツが評価の高いものから順に 15 件のドキュメントを返します。 キャッシュされたコンテンツ クエリ Web パーツが最新のものから順に 15 件のドキュメントを返します。 キャッシュされていないコンテンツ クエリ Web パーツが現在のユーザーによって変更されたアイテム 15 個を最新のものから順に返します。 |
管理されたメタデータのフォールバック クエリ |
5,000 件を超える結果を返し、単一値の管理されたメタデータ列に対するフィルター処理を実行するリスト ビュー クエリです。 |
管理されたメタデータの選択クエリ |
1,000 件の結果を返し、単一値の管理されたメタデータ列に対するフィルター処理を実行するリスト ビュー クエリです。 |
コンテンツ タイプのフォールバック クエリ |
5,000 件を超える結果を返し、コンテンツ タイプによるフィルター処理を実行するリスト ビュー クエリです。 |
コンテンツ タイプの選択クエリ |
1,000 件の結果を返し、コンテンツ タイプによるフィルター処理を実行するリスト ビュー クエリです。 |
テスト ミックス
テスト ミックスごとに構成を変えました。テストは Visual Studio のテスト システムを使用して実行しました。特定のデータ ポイントをテストごとに事前設定し、テスト ミックスは 2 分間のウォームアップと 10 分間のデータ収集で実行しました。この記事に提示されている結果は、その 10 分間の平均値です。次の表に、1 つのテスト ミックスで各ソリューションが占める割合 (%) を示します。
| ソリューション名 | ミックスに占める割合 (%) |
|---|---|
ドキュメントのアップロード (ドキュメント プロパティの編集を含む) |
20 |
ドキュメントのダウンロード |
20 |
ドキュメント ライブラリへのアクセス |
20 |
コンテンツ クエリ Web パーツのあるホーム ページへのアクセス |
10 |
管理されたメタデータのフォールバック クエリ (5,000 件を超える結果) |
5 |
管理されたメタデータの選択クエリ (100 件の結果) |
10 |
コンテンツ タイプのフォールバック クエリ (5,000 件を超える結果) |
5 |
コンテンツ タイプの選択クエリ (100 件の結果) |
10 |
調整と制限
制限を設けることで、ファームのパフォーマンスに悪影響を及ぼす操作を回避できます。こうした既定の設定は、テストされ、入念に選択されています。リスト ビューのしきい値など、一部の制限については値を変更しないことを強くお勧めします。これらの制限を変更した場合の影響を慎重に検討してください。これらの制限によって操作を実行できない場合は、制限の変更によって実行方法の不適切な操作を許容するのではなく、より効率的にインデックス付けされた方法でその操作を実行することを最初に検討してください。このセクションで説明するほとんどの調整と制限は、サーバーの全体管理で構成できます。そのためには、[Web アプリケーションの管理] に進み、特定の Web アプリケーションのリボンから [全般設定 - リソースの調整] を選択します。
リスト ビューのしきい値
SharePoint Server 2010 は、何千万というアイテムを持つドキュメント ライブラリやリストをサポートしています。フォルダー、標準ビュー、サイト階層、およびメタデータ ナビゲーションを使用すると、非常に大きなドキュメント ライブラリを作成できます。リスト ビューまたは Collaborative Application Markup Language (CAML) クエリを使用して大きなリストからデータを取得するには、フォルダーまたはインデックス、あるいはその両方を使用してデータを分割しておく必要があります。そうでない場合は、検索がデータへの効率的なアクセスに使用できる唯一のメカニズムになります。1 つのドキュメント ライブラリでサポートできるアイテムの数は、ドキュメントやフォルダーの構成、格納されるドキュメントのサイズと種類、ドキュメント ライブラリの使用状況、およびドキュメント ライブラリ内の列の数によって変化します。
ヒント
リスト ビューしきい値の導入に関しては、これが Office SharePoint Server 2007 でのフォルダーあたり 2,000 アイテムという推奨値にどのように関連しているのかと思う人もいるでしょう。新しい制限値は 5,000 になっており、2,000 ではありません。ユーザーが主にフォルダーを使用してコンテンツを閲覧する場合は、この推奨値と同じ考え方になります。しかし、メタデータ ナビゲーションによる再試行およびフォールバックの導入により、大きなクエリはパフォーマンス向上のために結果のサブセットを返すようになっています。つまり、フォルダーには何千個というアイテムがあってもよく、クエリの返す結果が多すぎる場合でもパフォーマンスは保護されるわけです。
既定では、リスト ビューのしきい値によって、5,000 個を超えるアイテムを返すクエリ、5,000 個を超えるアイテムを含むリストへの列の追加など、影響を受けるアイテム数が 5,000 を超えるような操作はブロックされます。この既定の設定は構成できますが、既定値をそのまま使用することを強くお勧めします。アイテム数が 5,000 を超えるリストに対して実行方法の不適切なクエリが使用された場合、この上限を増やしていると全体のスループットが著しく低下する可能性があるからです。
インデックス付けされていないクエリ、リストへの列の追加など、一部の操作は、リスト内のアイテム数に比例した時間とリソースを必要とします。リストが小さい場合は、アイテム数が少なく操作が短時間で完了するので、この点は問題になりません。リストのサイズが大きくなると、操作に必要な時間やリソースも増えます。リスト ビューのしきい値を使用すると、こうした操作は無制限に実行されることがなくなり、ブロックされます。リスト ビューのしきい値は、幹線道路のガード レールのようなものであり、クエリの内容やデータ アクセスの方法を変更するか、ファームの使用率が低い状況で操作を実行する必要があることを教えてくれます。
リスト ビューのしきい値は、クエリのようなデータベース操作が一度に影響を与えることのできるリスト アイテムまたはライブラリ アイテムの最大数です。既定では、この値が 5,000 アイテムに設定されています。この制限は、大きなリストにかなりの影響を及ぼします。というのも、このしきい値の定義により、この上限値を超える数のアイテムを持つリストが大きなリストとなるためです。この制限を超える操作は調整されます。この制限を超えるリストに対するインデックスの作成といった操作は、5,000 個を超えるアイテムに影響を及ぼすのでブロックされます。この制限により、5,000 個を超えるアイテム (フィルター基準を使用して効率的にフィルター処理できるアイテム数) を選択し得るクエリは実行できなくなります。また、インデックス付けされていない列に対するフィルター処理を実行するクエリもブロックされます。インデックス付けされていない列に対するフィルター処理 (および場合によっては並べ替え) を行うクエリは、適切なデータセットを取得するためにリスト内のすべてのアイテムに対してフィルター処理を行う必要があり、リスト ビューのしきい値を超える数のアイテムを処理することになるからです。この制限の既定値は、ファームおよびリストのパフォーマンスと SQL Server によるロックの管理方法に基づいています。この制限は変更しないことをお勧めします。
データベースの競合を最小限に抑えるために、SQL Server では、他の行にアクセスするユーザーに悪影響を及ぼさずに正確な更新を確実に行う方策として行レベルのロックを使用します。ただし、クエリのようなデータベースの読み取りまたは書き込み操作によって 5,000 を超える行が同時にロックされる場合は、SQL Server でデータベース操作が完了するまでロックの対象をテーブル全体に拡大したほうが効率的です。こうしたロックのエスカレーションが発生すると、他のユーザーはテーブルにアクセスできなくなります。ロックの詳細については、「ロックのエスカレーション (データベース エンジン)」(https://go.microsoft.com/fwlink/?linkid=219156&clcid=0x411) を参照してください。
次のグラフは、リスト ビューのしきい値を調整しながら各種クエリの組み合わせを大きなリストに対して実行したときのスループットを示しています。このクエリの組み合わせには、リスト内のすべてのアイテムを返すクエリが含まれているため、リスト ビューのしきい値が高くなるほど、返されるアイテムの数が増えます。上限値を既定の 5,000 から 10,000 に変更しただけでも、パフォーマンスはかなりの影響を受けます。リスト ビューのしきい値の増減によってパフォーマンスを向上させるよりも、既定のリスト ビューしきい値を変更せずにクエリの適切な実行に注力することをお勧めします。
.gif "リスト ビューのしきい値のスループットを示す図")
リスト ビューのしきい値に関する例外は、操作の実行方法が不適切なために発生します。こうした操作は構成し直す必要があります。上限値を高くするよりも、なぜ非効率的な操作が実行されているのかを検討し、それらの操作を修正する必要があります。最悪の場合は、特定のリストに対する EnableThrottling の設定を一時的に false に変更することで、リスト ビューのしきい値を無視できます。これはリスト レベルでしか行えず、サイトでは利用できません。この措置は、リストへのアクセスを許可するために、リスト ビューのしきい値によってブロックされる不適切な実行方法による操作を修正するための変更が可能になるまでの間に限って実行してください。EnableThrottling の設定は、できるだけ早く true に戻す必要があります。
重要
リスト ビューのしきい値に関する例外は、特にアップグレードの直後によく発生します。この問題はリスト ビューのしきい値の変更によって簡単に解決できるように思えるでしょうが、ここではリスト ビューのしきい値を変更しないことを強くお勧めします。
クエリの生成元であるフロントエンド Web サーバー上にいるファームの管理者やローカル コンピューターの管理者は、リスト ビューのしきい値によってブロックされません。これらのユーザーは、適切に構成されていない大きなリストを注意深く閲覧し、またテストの際にも注意を払う必要があります。期待どおりの動作が行われているように見えても、ユーザーに返されるデータはかなり異なったものになる場合があります。リスト ビューのしきい値によってブロックされる操作のリストについては、後述する「リスト ビューのしきい値によってブロックされる操作」を参照してください。
同様に、タイマー サービスもリスト ビューのしきい値によって保護されないアカウントを使用して実行できます。これにより、大きなリストでのインデックスの遅延作成など、特定のシナリオを実現できますが、通常は大規模なリスト操作の実行をコードによって確実に避けるように特に注意してください。
リスト ビューのしきい値
既定値: 5,000 |
2007 における有無: なし |
構成: 可 |
構成場所: サーバーの全体管理、Web アプリケーションごと |
監査者と管理者に対するリスト ビューのしきい値
既定値: 20,000 |
2007 における有無: なし |
構成: 可 |
構成場所: サーバーの全体管理、Web アプリケーションごと |
監査者と管理者に対するリスト ビューのしきい値は、検索クエリ アカウント、オブジェクト キャッシュのスーパーリーダーおよびスーパーライター アカウントなど、特定のサービス アカウントで使用されるリスト ビューのしきい値です。たとえば、コンテンツ クエリ Web パーツは、この制限を自動的に使用して大きなクエリの結果をキャッシュするため、サーバー リソースの節約になります。カスタム コードを使用すると、Web アプリケーションのセキュリティ ポリシーに従ってスーパーリーダーまたはスーパーライターのアカウントとして実行している場合にこのより高い制限値を使用するように要求できます。
オブジェクト モデルの上書きを許可する
既定値: はい |
2007 における有無: なし |
構成: 可 |
構成場所: サーバーの全体管理、Web アプリケーションごと |
オブジェクト モデルの上書きの許可では、監査者と管理者に対するリスト ビューのしきい値をサービス アカウントで使用できるかどうかを指定します。ファームの管理者は、オブジェクト モデルの上書きを有効にし、リストが例外であることをプログラムによって指定する必要があります。その場合、適切なアクセス許可を持つプログラマは、自らのクエリまたはリストがこれを活用する監査者および管理者向けのより高いリスト ビューしきい値サイズを使用することをプログラムによって要求できます。この値をいいえに変更すると、監査者または管理者によって実行されるカスタム コードは、たとえ上書きを要求していても、監査者および管理者向けの高い制限値ではなく、リスト ビューのしきい値の影響を受けるようになります。この設定は既定値のままにしておき、監査者と管理者に対するリスト ビューのしきい値のみを必要に応じて構成することをお勧めします。
実行時間帯
既定値: オフ |
2007 における有無: なし |
構成: 可 |
構成場所: サーバーの全体管理、Web アプリケーションごと |
実行時間帯を設定すると、リスト ビューのしきい値の影響を受けることなく操作を実行できます。この時間は 15 分単位で、最大 24 時間まで調整できます。この時間帯に開始されたデータベースの操作またはクエリは、たとえ指定された時間帯内に終了しなくても、完了するまで続行されます。既定では、実行時間帯が構成されていません。これは、ピーク外の時間帯が展開ごとに大きく異なるためです。そのため、時間帯の決定は管理者に委ねられています。実行時間帯は、Web アプリケーションの使用者がほとんどいなくなる適当な時間帯が存在する場合にのみ指定することをお勧めします。これにより、ユーザーは大きなリストに対する管理操作 (インデックスの作成など) をファームの使用率がかなり低い時間帯に実行できます。
固有のアクセス許可
リスト内の固有のアクセス許可の数が増えると、パフォーマンスは低下します。大きなリスト内のすべてまたはほとんどのコンテンツを固有のセキュリティで保護する必要があるような設計は、再検討する必要があります。固有のアクセス許可の数が 0 の場合と 1,000 の場合では、リストに対する操作のスループットが 20% ほど違ってきます。構成可能な既定値では、リストあたりの固有のアクセス許可数が 50,000 になっています。しかし、ここでは、この制限値を低くして固有のアクセス許可数を 5,000 にするように検討すること、また大きなリストの場合は使用する固有のアクセス許可数ができるだけ少なくなる設計を採用するように検討することをお勧めします。これは、パフォーマンスのみならず管理容易性の点でも有用です。
以下のことをお勧めします。
個々のアイテムに対する固有のアクセス許可の使用を最小限に抑え、ほとんどのアイテムが固有のアクセス許可を必要とするようなリスト設計を簡素化します。
固有のアクセス許可が必要な場合は、リストまたはフォルダーのレベルでのみ設定し、固有のアクセス許可を必要とする個々のアイテム数を最小限に抑えるようにしてください。
アイテムごとに個別のアクセス許可が必要になる場合は設計を見直します。複数のリストに分割されているアイテムを調査したり、すべてのアイテムに固有のアクセス許可を設定しなくても適切なアクセス権を付与できるようにアイテムをフォルダーやグループにまとめたりします。
詳細なアクセス許可を設定すると、パフォーマンスに影響を及ぼす可能性があり、多数のアイテムのそれぞれで設定が異なる場合は管理も困難になります。リスト ビューのしきい値を超えるリストまたはフォルダーに対する詳細なアクセス許可の設定は、更新が必要な個々のアイテム数が多すぎるという理由でブロックされます。しかし、詳細なアクセス許可の設定は、それ以外の形でもパフォーマンスに影響します。そのため、リストあたりの固有のアクセス許可数を既定で最大 50,000 とする構成可能な制限が存在します。この上限に達した後に固有のアクセス許可を宣言しようとした場合、その試みはブロックされます。リスト ビューのしきい値とは異なり、この制限はクエリの実行時ではなく、アイテムに対する固有のアクセス許可の作成時に適用されます。
あるアイテム (フォルダーなど) でアクセス許可の継承が破棄されるときは必ず、この制限の対象となる固有のアクセス許可としてカウントされます。アクセス許可の継承が破棄されるたびに、新しいスコープ ID が作成されます。また、ビューに対してクエリを実行するたびに、スコープ テーブルに従わない結合を行うことになります。さらに、クエリが実行されると、固有のアクセス制御リスト (ACL) をそれぞれ解析して処理しなければなりません。リスト内に数多くの固有のアクセス許可が存在すると、パフォーマンスに悪影響を及ぼすため、そうした状況は推奨されません。リスト内にある固有のアクセス許可の数が増えると、クエリのパフォーマンスは低下します。たとえ固有のアクセス許可数の既定の上限が 50,000 であっても、この固有のアクセス許可数の制限値を 5,000 に下げるように検討が必要になる場合があります。
固有のアクセス許可
既定値: 50,000 |
2007 における有無: なし |
構成: 可 |
構成場所: サーバーの全体管理、Web アプリケーションごと |
行の折り返し
リストに追加された列は、SQL Server データベース テーブル内の列にマップされます。データベース テーブル内の各行がサポートしているいくつかの列の種類の数は、それぞれ固定されています。たとえば、データベース テーブルの 1 つの行は、8 つの日時列と 12 の数値列をサポートしています。日時列が 8 つを超える場合は、それぞれのリスト アイテムで 2 つのデータベース テーブル行が使用されます。
小さなリストの場合、こうした行の折り返しによるパフォーマンスへの影響は無視できます。しかし、大きなリストの場合はかなりの影響を及ぼす可能性があります。列の数がいくつであっても行の折り返しが発生しないように、上限を高く設定できます。ただし、列の種類が 1 つでもその制限値を超えると、行の折り返しが発生します。
次の表に、特定のデータ型で行の折り返しが発生しない最大の列数を示します。
| 列の種類 | テーブルの行あたりの列数 |
|---|---|
1 行テキスト または 選択肢および複数行テキスト |
64 32 |
日時 |
8 |
はい/いいえ |
16 |
数値および通貨 |
12 |
集計値 |
8 |
整数、単一値のルックアップ、ユーザーおよびグループ、管理されたメタデータ |
16 |
一意識別子 |
1 |
行の折り返しにより、ほとんどの操作では行が追加されるたびにスループットが約 35% 低下します。リストで使用している行数を確認するには、リスト スキーマを分析し、リスト上にあるフィールドの列の種類を調べる必要があります。
次のグラフは、より多くの管理されたメタデータ列に対応できるようにリストで使用される SQL Server データベースの行数を増やしたときの読み取り専用クエリのパフォーマンスを示しています。行数を 2 にするためには 15 の管理されたメタデータ列をリストに追加し、行数を 3 にするためには 31 の管理されたメタデータ列をリストに追加しました。テストの実施には、リスト内のアイテムに対してフィルター処理を行うクエリのみを使用しました。行が追加されるたびにスループットは 35% 低下しています。
.gif "行の折り返しのスループットを示す図")
行のサイズ制限
既定値: 6 |
2007 における有無: なし |
構成: 可 |
構成場所: オブジェクト モデルのみ、SPWebApplication.MaxListItemRowStorage |
行のサイズ制限では、リスト内のそれぞれのアイテムで使用されるデータベースの内部にあるテーブルの最大行数を指定します。多くの列を持つ幅の広いリストに対応するために、各アイテムはいくつかの内部テーブル行 (最大で 6 行) にわたって折り返されます。たとえば、多数の小さな列を持つリスト (何百というはい/いいえ列を含むリストなど) が存在する場合は、この上限に達する可能性があります。その場合は、はい/いいえ列をそれ以上リストに追加できなくなります。ただし、その他の種類の列は追加できる場合があります。行が追加されるたびにオーバーヘッドが増加するため、大きなリストの場合は同じ種類の列の数を最小限に抑えて行の折り返しを避ける必要があります。
ルックアップ列とリスト ビュー
リスト ビュー内にあるルックアップ列のそれぞれは、別のテーブルとの結合を発生させます。ビューにルックアップ列が追加されるたびに、メタデータ ナビゲーションの複雑さが増し、リスト ビューのクエリが増加します。標準のルックアップ列に加えて、単一値の管理されたメタデータ、複数値の管理されたメタデータ、単一値のユーザーおよびグループ列、複数値のユーザーおよびグループ列もルックアップ列と見なされます。ルックアップ列をビューに追加しても、パフォーマンスが段階的または線型に低下することはなく、むしろパフォーマンスは列数が 8 を超えるまでは安定しており、その後急激に低下します。
次のグラフは、ビュー内のルックアップ列の数を増やしたときのスループットの変化を示しています。ご覧のように、列の数が 0 から 8 までの範囲でのパフォーマンスの変化はいくらか安定していますが、ルックアップ列の数が 10 になるとスループットが大幅に低下しています。このテストは、リストで 1 行のみを使用して実施しました。リストに行の折り返しがある場合、パフォーマンスはもっと急速に低下します。
.gif "ビューのスループットでの検索列を示す図")
次のグラフは、ビュー内のルックアップ列の数を増やしたときの SQL Server の CPU 使用率を示しています。ご覧のように、ルックアップ列の数が 10 になったところで大きな変化が生じています。多数のクエリを持つリストの場合、ビューに含まれるルックアップ列の数が 8 を超えると、クエリで使用される SQL Server リソースの量が不相応に多くなります。この制限値は 9 以上には変更しないことをお勧めします。
.gif "SQL CPU 使用率を示す図 - 検索列")
こうしたパフォーマンスの低下は、リスト上のルックアップ列の総数ではなく、ビューまたはクエリ内のルックアップ列の数のみによるものですが、SharePoint Workspace ではルックアップ列の数が 8 を超えているリストを同期できません。このことは、ルックアップ列がビュー内で使用されているかどうかには無関係です。
リスト ビュー参照のしきい値
既定値: 8 |
2007 における有無: なし |
構成: 可 |
構成場所: サーバーの全体管理、Web アプリケーションごと |
その他の制限
このセクションでは、この記事のほかの部分では言及していない制限について説明します。
リストあたりのインデックス数
既定値: 20 |
2007 における有無: あり (制限値は 10) |
構成: 不可 |
上の表は、1 つのリストで作成できるインデックス数の上限を示しています。これには、複合インデックスや SharePoint Server 2010 によって作成されるインデックスの数も含まれます。この制限値は構成できません。
データシート ビューと Excel へのエクスポート
既定値: 50,000 |
2007 における有無: なし |
構成: 不可 |
上の表は、Microsoft Excel へのエクスポートとデータシート ビューで使用できるアイテムの最大数を示しています。ただし、データシート ビューはリスト ビューのしきい値による制限を受けます。そのため、リスト ビューのしきい値が 5,000 アイテムで、リスト ビュー内のアイテム数が 5,000 ～ 50,000 個の場合、データシート ビューの使用を試みると、たとえデータシート ビューの制限値のほうが高くても、リスト ビューに関する例外メッセージが表示されます。
SharePoint Workspace
既定値: リストごとに 30,000 個のアイテム |
2007 における有無: なし |
構成: 不可 |
Microsoft SharePoint Workspace には、リスト 1 つあたりのアイテム数が 30,000 個を超えるリストの同期をブロックする構成不可能な制限があります。リストに 30,000 個のアイテムが含まれている場合、ユーザーは SharePoint Workspace を使用してそうしたリストを同期できず、アイテムを選択的に同期することもできません。
大きなリストと通常のリストとの違い
リストがリスト ビューのしきい値を超えると、それまで正常に機能していた一部の操作がブロックされる場合があります。最も注意が必要なのは、ユーザーがリストにアクセスするために頻繁に使用する既定のリスト ビューです。リスト ビューは、大きなリストで適切に動作するように構成する必要があります。たとえば、リストのルートにリスト ビューのしきい値を超える数のアイテムが含まれている場合にそのリストにアクセスすると、エラーが発生します。ただし、メタデータ ナビゲーション機能が有効になっている場合は、結果のサブセットが表示され、エラーは発生しません。
リスト ビューのしきい値により、その値を超える数のアイテムに影響するデータベース操作はすべてブロックされます。つまり、このしきい値は、返されるアイテムや変更されるアイテムの数を制限するだけのものではありません。たとえば、100 件の結果を返すインデックス付けされていない列に対するフィルターがあり、リストに 10,000 個のアイテムが含まれている場合、クエリは 10,000 個のアイテムすべてのスキャンを実行する必要があるので失敗します。この列にインデックスを追加すると、この操作は対象が 100 個のアイテムに制限されるので成功します。
大きなリストに対する操作は、次の 2 つのグループに分類できます。
リストがリスト ビューのしきい値を超える場合 リスト全体のサイズがリスト ビューのしきい値を超えていると、たとえアイテムが複数のフォルダーに分かれていても、一部の操作がブロックされます。こうした操作には、アイテムがどんなフォルダーに入っているかに関係なくすべてのアイテムを操作の対象とする再帰的なクエリ (チェックアウトされたバージョンの管理など) が含まれます。また、フォルダーを使用せずにすべてのアイテムを返すビューもブロックされます。さらに、列の追加、インデックスの作成または削除など、リスト全体に影響を及ぼす操作もブロックされます。
コンテナーがリスト ビューのしきい値を超える場合 操作によっては、フォルダー、またはリストのルートにリスト ビューのしきい値を超える数のアイテムが含まれているという理由でブロックされるものがあります。たとえば、10,000 個のアイテムを含むリストと 3,000 個のアイテムを含むフォルダーがある場合、そのフォルダーに対して名前の変更や削除を実行できます。しかし、フォルダーに (リスト ビューのしきい値を超える) 6,000 個のアイテムが含まれている場合は、リスト ビューのしきい値を超える操作になるのでこのフォルダーの削除を実行できません。
リストがリスト ビューのしきい値を超えた場合には、ビューやその他のナビゲーション オプションの適切な構成を計画する必要があります。ビューをはじめとするナビゲーション オプションは事前に構成しておくのが理想的ですが、リストの拡大によってリスト ビューのしきい値を超え、対処が必要になることも少なくありません。操作によっては、多数のアイテムを持つリストでの列の作成や列のインデックス作成のように、長い時間がかかるものがあります。これらの操作はリスト ビューのしきい値によってブロックされます。ただし、実行時間帯の間に実行したり、ファームまたはコンピューターの管理者によって実行したりすることはできます。こうした操作については、実行前に計画しておく必要があります。リストが既に大きくなりすぎている場合は、実行時間帯または管理者資格情報を利用してこれらの操作を実行するように計画してください。
ヒント
リストの設定中に一般的に行われる管理操作のなかには、リスト ビューのしきい値によってブロックされるものがあります。可能であれば、リストのサイズがリスト ビューのしきい値を超える前に、リストのすべてのコンテンツ タイプ、列、およびインデックスを構成するようにしてください。
リストは非常に大きくなる可能性があるため、一部の操作では Web ブラウザーを使用して実行するとタイムアウトが発生する場合があります。たとえば、リストに何百万件ものドキュメントが含まれている場合、新しい列の追加に膨大な時間がかかることがあります。こうした操作を完了するためには、Windows PowerShell を使用し、他のユーザーの操作に支障が出ないようにピーク外の時間帯に実行する必要があります。
リスト ビューのしきい値によってブロックされる操作
次の表に、リスト ビューのしきい値によってブロックされる操作を示します。
リストがリスト ビューのしきい値を超えるとブロックされる操作
| 操作 | 説明 |
|---|---|
リストの列の追加/削除/更新 |
ルックアップ列および集計列を含むすべての列を対象とします。種類の変更、一意性の変更など、多くの種類の更新も含まれます。ただし、名前の変更など、一部の更新は、リスト内のすべてのアイテムに影響するわけではないので、ブロックされません。 |
リスト コンテンツ タイプの追加/削除/更新 |
リスト内のすべてのアイテムに影響するので、リスト ビューのしきい値より多くのアイテムが含まれるリストではブロックされます。 |
インデックスの作成/削除 |
リスト内のすべてのアイテムに影響するので、リスト ビューのしきい値より多くのアイテムが含まれるリストではブロックされます。 |
チェックイン バージョンがないファイルの管理 |
インデックス付きでない再帰的なクエリは、リスト ビューのしきい値を超える数のアイテムを持つすべてのリストで失敗します。 |
インデックス付きでない再帰的なクエリ |
フィルターと一部の並べ替えを含みます。リストのサイズがリスト ビューのしきい値よりも大きい場合、この操作は失敗します。インデックスが存在しないため、リスト全体に対してフル スキャンを実行します。また、すべてのアイテムを返し、フォルダーは無視されます。 |
クロス リスト クエリ |
コンテンツ クエリ Web パーツによるクエリを含み、監査者と管理者に対するリスト ビューのしきい値の設定 (既定では 20,000 アイテム) に従います。20,000 個を超えるアイテムが操作の影響を受ける場合、このクエリは失敗します。 |
リレーションシップの動作を強制するルックアップ列 |
参照されるリストにリスト ビューのしきい値を超える数のアイテムが含まれている場合は、リレーションシップの動作を強制するルックアップ列を作成できません。 |
リストの削除 |
リスト内のすべてのアイテムに影響するので、リスト ビューのしきい値より多くのアイテムが含まれるリストではブロックされます。 |
サイトの削除 |
サイト内にあるアイテムの総数がリスト ビューのしきい値を超えている場合は、影響を与えるアイテム数が多すぎるという理由でそのサイトを削除できません。 |
データ付きテンプレートとしてリストを保存 |
リスト内のすべてのアイテムに影響するので、リスト ビューのしきい値より多くのアイテムが含まれるリストではブロックされます。 |
リスト ビュー内の総数の表示 |
リスト内のすべてのアイテムに対してクエリを実行するので、リスト ビューのしきい値を超える数のアイテムを持つリストではブロックされます。 |
リスト内の添付ファイルの有効化/無効化 |
リスト内のすべてのアイテムに影響するので、リスト ビューのしきい値より多くのアイテムが含まれるリストではブロックされます。 |
コンテナーがリスト ビューのしきい値を超えるとブロックされる操作
| 操作 | 説明 |
|---|---|
フォルダーの削除/コピー/名前変更 |
フォルダーにリスト ビューのしきい値を超える数のアイテムが含まれている場合は、影響を与える行の数が多すぎるという理由で失敗します。 |
インデックス付きでない列に対するフィルター処理を行うクエリ |
コンテナー (フォルダーまたはリスト) にリスト ビューのしきい値を超える数のアイテムが含まれている場合は、失敗します。この操作では、インデックスが存在しないのでフォルダー全体に対してフル スキャンが実行されます。 |
詳細なセキュリティ アクセス許可の設定 |
詳細なアクセス許可を設定しようとするリストまたはフォルダーにリスト ビューのしきい値を超える数のアイテムが含まれている場合は、影響を与える行の数が多すぎるという理由で失敗します。リスト ビューのしきい値を超える数のアイテムが含まれているリスト自体またはフォルダーにアクセス許可を設定することはできませんが、大きなリスト内にある子のアイテム (ドキュメントなど) に対しては詳細なアクセス許可を設定できます。 |
エクスプローラーで開く |
コンテナーにリスト ビューのしきい値を超える数のアイテム (サブフォルダー内のアイテムを除く) が含まれている場合は、アイテムが一切表示されません。フォルダーに 8,000 個のアイテムがあっても、そのうち 4,000 個のアイテムがサブフォルダーに含まれていてルートには残り 4,000 個のアイテムしかなければ、エクスプローラーで開く操作は問題なく機能します。リストのルートにリスト ビューのしきい値を超える数のアイテムが含まれている場合は、エクスプローラーで開く操作を行っても何も表示されません。[エクスプローラーで開く] を使用するには、リストが持つアイテムをフォルダーに整理して、どのコンテナーについてもルートにあるアイテムの数がリスト ビューのしきい値よりも少なくなるようにする必要があります。 |
使用できるが期待どおりに動作しない可能性がある機能
このセクションでは、大きなリストの使用時に期待どおりに動作しない可能性がある機能について説明します。
データシート ビュー
ドキュメント ライブラリのライブラリ リボン タブにある [データシート ビュー] ボタンは、リストのサイズがリスト ビューのしきい値を超えた場合でも無効になりません。ただし、リストのサイズがリスト ビューのしきい値を超えると、アイテムがビューにある程度読み込まれた時点で、"このリストは、管理者が設定したリスト ビューのしきい値を超えています。このようなリスト全体を表示する権限がありません。" というメッセージが表示されます。リストの設定を使用すると、リボンのデータシート ビュー オプションを無効にすることができます。また、アイテムの制限値は 50,000 個に固定されているので、リスト ビューのしきい値が 50,000 を超えた場合もデータシート ビューはブロックされます。
大きなリストの設計および実装の計画
大きなリストを実装する前に、ビジネス ケースと要件について検討してください。サービス レベル契約 (SLA)、バックアップと復元に要する時間、コンテンツのサイズ、コンテンツの量 (アイテム数)、アクセス回数などの要件は、いずれも十分な検討が必要な重要事項です。アプリケーションのサイズと需要によって、ハードウェア、コンテンツ ストレージ、SharePoint Server 2010 情報アーキテクチャなど、複数のレベルで重大な選択を行う必要があります。 数百万単位のアイテムがあり、数百人単位の同時接続ユーザーがいる大きなアプリケーションでは特定のプロジェクトのために専用のスタンドアロン ハードウェアを必要とする可能性がありますが、数十人単位の同時接続ユーザーと数万単位のドキュメントがあるドキュメント リポジトリであれば、既存の共有ハードウェアと既存のサイト内の単一ドキュメント ライブラリで滞りなく動作できます。
計画プロセスの産物として、列の種類 (名前、データの種類、および使用状況)、インデックス、フォルダー構造、ナビゲーション用のページおよびリンクの使用状況、計画されたアクセス許可構造、アイテムの予測数、およびデータの全体サイズを一覧にまとめます。また、実行するクエリの種類やこの一覧のデータのアクセス、作成、および更新を行うための手順など、詳細な情報も併せて記載します。
大きなリストの設計および実装の計画が完了したら、次のステップでプロトタイプの設計と構築を行います。この計画の段階では、大きなリストの設計、概念実証の実装、およびその動作の検証を行います。この段階で、データ アクセスとパフォーマンスの想定条件を検証できるように大量のコンテンツをテスト用環境に準備すると便利です。設計プロセスの産物として、一覧化した予測項目の概念実証、列のドキュメント、コンテンツ タイプ、フォルダー構造、ビュー、インデックス、メタデータ ビゲーションまたはその他のコンテンツ取得方法に使用する列、使用する分類方法、各種の Web パーツの使用状況、およびコンテンツ オーガナイザーなどのその他の機能の使用状況を明確化します。
コンテンツ サイズの見積もり
大きなリストを使用する場合は、さまざまな数値を見積もって、容量の計画と設計の決定を行う必要があります。以下に、計画する必要があるいくつかの重要な数値を示します。
コンテンツ データベースの合計サイズ
ファイルの平均および最大サイズ
バージョンの数
コンテンツの量 – リストに含まれるアイテムの総数
コンテンツ データベースのサイズ
コンテンツ データベースの合計サイズは、必要なディスク領域とハードウェアを計画するうえで重要な数値であると共に、バックアップ、復元、およびサービス レベル契約に対応するために必要なものを見積もるうえでも重要です。コンテンツ データベース全体のサイズは、バックアップと復元を行うために必要なダウンタイムを見積もるプロセスで最も重要な数値です。
コンテンツ データベースのサイズは、ドキュメントの平均サイズと 1 ドキュメントあたりの平均バージョン数を掛け、さらに予測されるドキュメントの数をこれに掛けることによって見積もることができます。ファイルのサイズに加え、コンテンツ データベースデータ分として 20 % を上乗せします。これが大きな数値になる理由は、一般にバージョンが増えるにつれてしだいにサイズが増加し、チェックイン済みドキュメントの平均ファイル サイズがすべてのバージョンの平均ファイル サイズよりも概して大きくなるからです。コンテンツの量を効果的に制御できるしくみがある場合を除き、リストが予測を超えて大きくなる事態に備え、余裕を見てバッファーを追加することをお勧めします。
ファイルの平均サイズと最大サイズ
ファイルの最大サイズは、アップロードされる可能性があるファイルを Web アプリケーション設定で正しく指定するために必要です (既定値は 50 MB ですが、最大で 2 GB に増やすことができます)。ファイルの平均サイズは、コンテンツが増加する割合を把握するための目安となると共に、コンテンツの合計サイズを見積もるためにも使用されます。ファイルの平均サイズは、想定されるシステムの役割を現在満たすシステムにあるファイルの数を評価することによって見積もることができます。
ヒント
ファイルのサイズに加え、データ分としてコンテンツ データベースに 10 ～ 20 % のサイズを上乗せしたり、検索インデックスのサイズがコンテンツ データベースのサイズの約 75 % になるという予測のもとに計画する必要があります。
バージョンの平均数
バージョンの数はコンテンツのサイズに顕著に影響するため、バージョン管理には十分に注意してください。バージョンの数を制限する方法はいくつかあります。たとえば、情報管理保持ポリシーを使用して一定の時間が経過した後ですべての前のバージョンを削除したり、保存されるバージョンの数を制限したりできます。これ以外にもバージョンに影響する要素があります。たとえば、コンテンツ オーガナイザーを使って送信されたすべてのコンテンツがリポジトリにある場合、コンテンツ オーガナイザーは最新のチェックイン済みバージョンのみをコピーすることから、バージョンは 1 つも存在しない可能性があります。リポジトリ内のドキュメントが頻繁に編集される場合は、共同編集の使用の検討が必要となる可能性があります。共同編集セッションを行うと、その都度バージョンが自動的に作成されます。リポジトリの使用状況を検討し、1 つのドキュメントに作成されるバージョンの平均数を見積もるために既存のソリューションを評価してください。
コンテンツの量
コンテンツの量とは、1 つのリストに含まれるアイテムの総数です。コンテンツの量を見積もるには、コンテンツの既存のソースと新しいシステムにどのコンテンツが移動されるのかを評価したり、そのシステムを使用するユーザーの数とシステムがどのような目的で利用されるのかを調べたりします。これ以外にも、1 コンテナーあたりのアイテム数や 1 メタデータ ピボットまたは 1 インデックス フィルターあたりのアイテム数などの数値も、コンテンツ量の見積もりに関係します。これらの数値は、ビューやメタデータのナビゲーションを計画するときにも重要です。
リモート BLOB ストレージ
大きなストレージを必要とするリストがあると、これがドキュメントの保管方法を選択する過程で決定的な役割を演じる可能性があります。既定で、SharePoint Server 2010 はすべてのドキュメントを BLOB として SQL Server データベースに格納します。SharePoint Server 2010 および SQL Server 2008 ではリモート BLOB ストレージ API が提供されており、これを使用してドキュメントを SQL Server データベースの外部に保管することができます。このようにすることで、データベースのサイズが削減されます。リモート BLOB ストレージを使用するかどうかは、主にコスト削減の観点から判断します。
マイクロソフトが実施した最近のテストによれば、リモート BLOB ストレージの導入によってスループットが 5 ～ 10 % 低下し、大きなファイルについては体感できるほどの待機時間は発生しないことがわかっています。ただし、使用するリモート BLOB ストレージ プロバイダーによってパフォーマンスが異なる可能性があります。リモート BLOB ストレージを使用すると、コンテンツ データベースのサイズは小さくなります。ただし、これは必ずしもコンテンツ データベースに格納できるアイテムの数が増えることを意味しません。パフォーマンスは、SQL Server データベース内のリストに含まれるアイテムの量に左右されます。仮に BLOB を削除したとしても、リストのサイズは変わりません。パフォーマンスが低下する懸念があっても、コスト削減によるメリットがそれを上回るシナリオとして次のものがあります。
アーカイブされた非共同作業データ
頻繁に更新されないビデオや画像などの非常に大きな BLOB
リモート BLOB ストレージを使用するには、ファームへのサーバーやテクノロジの追加が必要となる可能性があり、リモート BLOB ストレージ プロバイダーを追加することも必要です。リモート BLOB ストレージ プロバイダーは、SQL Server データベースの外部にある低コストのストレージに BLOB を格納するサービスを提供できます。SQL Server Enterprise では、リモート BLOB ストレージ API を使用する必要があります。
リモート BLOB ストレージの導入によって費用効果が見込まれるのは、データのサイズがテラバイト単位に達したあたりです。ただし、テラバイト規模のコンテンツ データベースがあるからといって、それだけの理由でリモート Remote BLOB ストレージを使用する必要はありません。バックアップと復元およびサービス レベル契約について慎重に考慮する必要があります。リモート BLOB ストレージの障害復旧を行うには 2 つのテクノロジを同期する必要があるため、通常の障害復旧よりも作業が難しくなります。懸念される大きな問題点は、障害の発生後にシステムを復元し、BLOB のバックアップと復元を処理するために要する時間です。詳細については、「RBS の概要 (SharePoint Server 2010)」を参照してください。
リストのアーキテクチャ
大きなリスト プロジェクトの場合、適切なアーキテクチャを選択することは重要です。実装した後でアーキテクチャを変更するのは困難だからです。コンテンツのサイズと量、リポジトリの使用状況、コンテンツをどのような方法で追加または更新するか、コンテンツにどのような方法でアクセスするかをあらかじめ計画し、十分に検討してください。これらはいずれも、コンテンツをどのように編成するのか (1 つのリスト、複数のリスト、または複数のサイト コレクションに格納するのか)、どのメタデータを使用するのか、コンテンツをどのような方法で取得するのかに影響する可能性がある要素です。これらのすべての決定事項は、リストのサイズが大きい場合にとりわけ重要性を増します。コンテンツの量が多いほど、システムの使用方法を見直す作業がはるかに困難になるからです。
単一リスト、複数リスト、または複数サイト コレクション
大きなリスト ソリューションの設計にあたって重要なのは、単一リスト アーキテクチャが適切かどうかを検討することです。コンテンツを 1 つのリストに配置するかどうかは、業務での使いやすさやコンテンツの見つけやすさなど、ビジネス要件に基づいて決定してください。多くのシナリオでは、複数のリストを使うアーキテクチャがより合理的です。SharePoint Server 2010 の機能と使用可能なリソースを活用して、優れた操作性とユーザー エクスペリエンスを効果的に提供することに、最優先事項として取り組む必要があります。
単一リストを使用すると、ユーザーはコンテンツの保存先を決める必要に迫られたり、目的のコンテンツを見つけるためにどのリストにアクセスする必要があるかを判断したりする必要がないため、コンテンツの検索や操作が容易になります。ただし、コンテンツの量が増えるにつれて、コンテンツを見つけることがしだいに難しくなります。ビューのフィルター処理やフォルダー間の移動でコンテンツを見つけようとする場合、特にこの問題が顕著となります。リストに含まれるアイテムの数が数十万個に達すると、メタデータ ナビゲーションが困難になる可能性があります。絞り込みが十分ではないクエリを行うと、数百から数千の結果が返されることがあります。
たとえば、インデックスのドメインに 5,000 個のキーワードがあるときに、各キーワードについてフィルターに一致するアイテムの量が等しいと仮定した場合、1 つのキーワードをフィルター処理すると、結果が 20 件であれば 100,000 アイテムのリストが返され、200 件であれば 1,000,000 アイテムのリストが返されます。リストのサイズが大き過ぎると、ユーザーが選択する多くのフィルターによって返される結果セットは、探しているデータを簡単には見つけられない量になります。複数の種類のコンテンツがプロジェクトにあり、ユーザーがそれらの違いを簡単に区別できるのであれば、複数のリストを使用することを検討してください。
大規模なアーカイブを使用するといった、非常に規模の大きなケースでは、複数サイト コレクション アーキテクチャの採用を検討する価値があります。SharePoint Server 2010 の新機能を使用すると、サイト コレクションをグループ化してドキュメントの負荷を分散できます。コンテンツ オーガナイザー機能は、サイト コレクション間でのドキュメントの受け渡しに使用できます。ドキュメントを取得するには、検索を使用する必要があります。このアーキテクチャは、長期保存用のストレージに適しています。そのようなストレージでは、コンテンツを複数のサイト コレクションに均等に振り分けることができ、単一リストと比較してはるかに多くのドキュメントに対応できるからです。
リストに関する推奨事項の概要
多数のアイテムに単一リストを使用する:
アイテムを複数のリストに分けて配置するのが論理的ではない場合。
最良のユーザー エクスペリエンスが得られる場合。
多数のアイテムに複数リストを使用する:
アイテムを複数のリストにグループ化するのが論理的な場合。
最良のユーザー エクスペリエンスが得られる場合。
コンテンツを追加したり探したりする際に、どのリストを使用すればよいのかユーザーが混乱しない場合。
複数サイト コレクション アーキテクチャを使用する:
リポジトリが数千万個以上のアイテムを単独でサポートする必要がある場合。
アイテムを複数のサイト コレクションにグループ化するのが論理的な場合 (データを年度別に分割するなど)。
メタデータ
SharePoint Server 2010 では、メタデータとコンテンツ タイプを利用して情報アーキテクチャを作成できます。管理されたメタデータ、用語セット、メタデータ ナビゲーションなどの新機能が導入されたことによって、メタデータはコンテンツの取得に非常に便利であり、重要な役割を演じるものとなりました。コンテンツ タイプや列の変更のような操作は大きなリストではブロックされるため、メタデータの要件をあらかじめ十分に検討する必要があります。メタデータ ナビゲーションまたは同様にメタデータをコンテンツの取得に利用する他の方法の使用を計画する場合は、設計段階でコンテンツ タイプとその列を十分に計画することを強くお勧めします。
大きなリストを使用するシナリオでは、多くの場合にメタデータは単に便利なだけでなく、それがなくてはユーザーがシステムを満足に利用できないほどです。メタデータを適用する方法として、主に、組み込みシステム プロセス、カスタム構成とコード、およびユーザーによる手動での適用の 3 つがあります。列を使用してコンテンツを取得する場合は、ほとんどのアイテムでその列に値が設定されている必要があります。したがって、どの列をナビゲーションに使用するか、メタデータをどのようにして列に設定するかを適切に計画することが重要です。正しいメタデータが適用されるように保証する唯一の方法は、組み込みプロセスとカスタマイズを使用することです。たとえば、すべてのアイテムにコンテンツ タイプが割り当てられるので、コンテンツ タイプ別にドキュメントを分類すると、すべてのアイテムにこのメタデータが与えられます。このようにすると、コンテンツ タイプに基づいて簡単にフィルター処理を行えます。
コンテンツ タイプ
コンテンツの最も基本的なカテゴリがコンテンツ タイプと対応関係にある必要があります。コンテンツをドキュメントやアイテムなどに分類するためにメタデータを使用する場合は、この分類をコンテンツ タイプに使用することを検討してください。コンテンツ タイプを使用すると、ワークフローやテンプレートに関連付けるだけでなく、コンテンツの種類に関連付けて列を定義できます。コンテンツ タイプに関連付けることができるテンプレートは 1 つのみであり、このテンプレートは、ドキュメント ライブラリの [新しいドキュメント] メニューを使用してコンテンツ タイプの新しいインスタンスを作成するときに使用します。
Microsoft Word、Microsoft PowerPoint、Excel などの製品では、ファイル形式の代わりにテンプレートを使用できます。ユーザーがコンテンツ タイプの新しいインスタンスを作成すると、そのテンプレートを使用してドキュメントの作成を始めるために特定のクライアント アプリケーションが使用されます。コンテンツをアップロードする際に使用可能なコンテンツ タイプを一覧から選択できます。コンテンツ タイプは、区別が明確に付き、固有の性質を持つものであると同時に、ユーザーが使用するコンテンツ タイプを選択するときに迷わない程度の数がリストごとに定義されている必要があります。
ユーザーがアイテムを作成またはアップロードするときに指定する必要があるメタデータの種類はコンテンツ タイプによって左右されるので、ビジネス要件を満たすために必要な列をよく検討し、コンテンツの送信を妨げる障壁を最小限に減らしてください。コンテンツを第 1 のレベルで分類するコンテンツ タイプを適切に準備すると、ナビゲーションも自ずと使いやすくなります。コンテンツ タイプはすべてのアイテムに割り当てられるので、これを基軸としてすべてのアイテムに適用できるフィルターを提供できます。
コンテンツ タイプに関する推奨事項の概要
コンテンツ タイプをコンテンツ編成の最も基本的な方法として使用する。
コンテンツ タイプを使用して、その種類のコンテンツに必要な特定の列を選択する。
1 リストあたりのコンテンツ タイプの数は 10 個を限度とし、ユーザーがどのコンテンツ タイプを使用すればよいかすぐにわかるように明確に区別が付くものとする。
コンテンツ タイプは、フィルター処理やメタデータ ナビゲーションに使用できる値を格納する組み込み列を各アイテムに提供する。
大きな共同作業リストとコンテンツ タイプの例: 製品仕様書ライブラリ
製品仕様書ライブラリは、製品開発チームが設計仕様書、テスト計画書、およびその他の製品開発項目を保管するために使用されます。この例では、以下の 6 種類のコンテンツ タイプを使用します。すべてのコンテンツ タイプには、プロジェクト開始日、プロジェクト終了日、予算、設計チームのメンバー、製品名、および製品タイプを収める列があります。
製品仕様書 – 製品の詳細設計が記載された Word 形式のファイル。追加のメタデータ: デザイナー、最終レビュー日。
テスト仕様書 – 製品のテスト計画が記載された Word 形式のファイル。追加のメタデータ: テスト担当者、テストの完了状況。
開発計画書 – 製品の開発計画が記載された Word 形式のファイル。
ストーリーボード – 設計のモックアップを示すために使用される PowerPoint 形式のプレゼンテーション。
コスト分析書 – 製品の開発コストと販売予測が記載された Excel 形式のスプレッドシート。
タイムライン – 詳細な製品開発スケジュールが記載された Excel 形式のスプレッドシート。
この例では、ユーザーがコンテンツ タイプに基づいてフィルター処理を行い、製品仕様書または製品ストーリーボードを見つけることができます。また、カスタム テンプレートは、ユーザーの操作を組織化するのに役立ちます。列とコンテンツ タイプの数は、ユーザーが業務に適したオプションを簡単に選択するには必要十分な数ですが、コンテンツを簡単にフィルター処理して見つけることができるようにメタデータを指定する必要があります。
列
列の数と必須の列
列を使用して、アイテムに割り当てられたメタデータの種類を指定できます。また、列を非表示、省略可能、または必須のいずれかに設定できます。非表示の列は、ワークフローなどのタスクの自動化に使用されるため、ユーザーが編集することはできません。必須の列は、必要不可欠な列である場合にのみ使用してください。たとえば、メタデータ プロパティは、アイテムを適切な場所に転送したり、ナビゲーションを提供したりするために必要な可能性があります。これらのケースでは、ユーザーが値を空のままにすることは望ましくありません。ナビゲーション フィルターとして使用される列にメタデータが設定されたアイテムの数が少ないほど、クエリで返されないアイテムが多くなるため、ナビゲーションの利便性が低下します。
メタデータ列の数が増えると、該当する列を特定して値を指定する作業が煩雑となることから、ユーザーがメタデータの設定を敬遠する可能性があります。多数の必須の列を使用する場合、コンテンツのアップロードに時間がかかるため、ユーザーがこの機能を積極的に利用することは期待できません。開かれた共同作業を行うシナリオでは、これは好ましくない状況です。しかし、コンテンツの価値が高まり、コンテンツを作成する活動が盛んになれば、ユーザーが時間を割いて適切なフィールドに値を設定する可能性は (特にこの操作が頻繁に行うものではない場合に) 大きくなると期待されます。
設計の段階では、必要な操作を実行したり、コンテンツを取得したりするためにどのようなメタデータが必要となるか、ユーザーがそれらのメタデータを設定するために費やす時間はどの程度になるか、ユーザーにどのような影響があるかを予測します。コンテンツを作成する作業のオーバーヘッドがあまりに大きいことが原因でユーザーがこのシステムを採用しない場合、後でシステムを再構築するのは困難な可能性があります。
フィールドの種類および単一値フィールドまたは複数値フィールド
列の選択に関して注意すべきことは、列の種類とその列に複数の値を許容するかどうかです。管理されたメタデータ フィールドに実行するクエリは、選択肢列に実行するクエリよりも効率的なので、選択肢列ではなく管理されたメタデータ フィールドを使用する方がよい可能性があります。管理されたメタデータや個人またはグループなどの列は、複数の値をサポートできます。複数値列に実行するクエリは、単一値列に実行するクエリと比べて効率が劣ります。
通常、列とコンテンツ タイプは、大きなリストに格納されたコンテンツの分類と取得に使用される中心的なコンポーネントです。一連の列とコンテンツ タイプは、計画の段階で既に準備されているはずです。リストに追加された列とコンテンツ タイプの数は、パフォーマンスに微妙に影響する可能性があります。単一のリストに特定の種類の列を数多く追加すると、行の折り返しが発生します。詳細については、この記事の「行の折り返し」を参照してください。
共同作業用の大きなリストおよび列の例: 製品仕様書ライブラリ
このセクションでは、この例で使用する以下の列について説明します。
SharePoint Server 2010 で自動的に管理される列: [ID]、[コンテンツ タイプ]、[更新日時]、[作成日時]、[更新者]、[作成者]、[ドキュメント ID]
カスタマイズによって管理される列:
[製品の種類] および [製品チーム] のフォルダー別のメタデータ既定値 (各 [製品タイプ] に 1 個のフォルダーがあり、各 [製品タイプ] フォルダーに複数の [製品チーム] フォルダーがある)
ワークフローの更新: [承認の状況]、[完了したプロジェクト]
ユーザーによって管理される列: [デザイナー]、[テスト担当者]、[最終レビュー日]
ナビゲーションに便利な列: [コンテンツ タイプ]、[製品タイプ]、[製品チーム]
状況の追跡に使用され、ナビゲーションにも便利な列: [最終レビュー日]、[承認の状況]、[完了したプロジェクト]
ナビゲーションに利用できる列: [デザイナー]、[テスト担当者]、[製品名]、[更新日時]、[更新者]
列に関する推奨事項の概要
値を設定できる列の数を最小限に抑える。
システム プロセスとナビゲーションに使用する列を十分に検討したうえで選択する。どのフィールドを必須とするかをよく検討し、必須フィールドの数を最小限に抑える。
必須フィールドは、コンテンツのクエリ Web パーツを特定のフィールドに使用するなど、ナビゲーションに必要な場合に使用する。 また、ユーザーが指定する必要がある保持処理を日付フィールドに指定するなどの管理操作にも使用する。
単一値列に実行するクエリは、複数値列に実行するクエリよりも速いので、複数値が必要な場合を除き、列を単一値で作成するように努める。
リストに特定の列が多数あると、行の折り返しが発生する可能性があります。行の折り返しはパフォーマンスを低下させます。可能であれば、大きなリストに格納する列の数を最小限に抑えて、行の折り返しを回避してください。
フォルダー
コンテンツをどのようにフォルダーに振り分けるかは慎重に検討する必要があります。フォルダーを使用する方法は、主に以下の 3 とおりです。
コンテンツをフォルダーに論理的に振り分けます。たとえば、署名された年または月に基づいて契約書をフォルダーにまとめたり、発行された日付に基づいて請求書をフォルダーにまとめます。この方法でフォルダーを編成すると、ユーザーは簡単にフォルダー構造内を移動したり、メタデータを使用してドキュメントを見つけることができます。また、ドキュメントを正しいフォルダーに自動的に転送することも容易です。コンテンツ オーガナイザーには、アイテムが一定の限度数を超えて追加されたときにサブフォルダーを作成することによって、1 つのフォルダー内のアイテム数を制限できる機能があります。
保持やアクセス許可などの管理機能に都合のよい方法で、コンテンツをフォルダーに振り分けます。たとえば、少数のユーザーのみにアクセスを許可する極秘文書を特定のフォルダーに格納したり、場所に基づいて保持するためにドキュメントを格納先フォルダーによって異なる保持スケジュールで処理することができます。この方法でフォルダーを編成すると、ユーザーのナビゲーションは難しくなります。ユーザーは、ドキュメントにアクセスさえできれば、そのドキュメントがどのフォルダーにあろうが意に介さない可能性があるからです。ドキュメントを見つけるために、フォルダー構造内を移動する方法よりもメタデータ ナビゲーションと検索が高い頻度で使用されます。
ユーザーのナビゲーションを支援するために、コンテンツをトピックやカテゴリ別にフォルダーに振り分けます。多くのユーザーは、コンテンツを探す際にフォルダー間を移動するのが習慣となっています。特定のアプリケーションでは、ユーザーが簡単に移動できるようなフォルダー構造を維持することが重要です。この方法でフォルダーを編成するシナリオでは、ユーザーはフォルダーの構造を全般的に把握し、ドキュメントを探す場所や配置する場所を知っています。必要に応じて、さらにメタデータ ナビゲーションや検索も利用できます。
SharePoint Server 2010 の機能強化により、フォルダーをより柔軟に使用できるようになり、パフォーマンスへの影響を以前ほど懸念する必要はなくなりました。管理されたメタデータやメタデータ ナビゲーションを利用することによって、フォルダーからフォルダーへ移動する方法ではなく、メタデータに基づいてコンテンツを簡単にフィルター処理できます。これにより、ユーザーのナビゲーションに限らず、アクセス許可やポリシーなどの管理目的でコンテンツを編成できます。たとえば、特定の社員のみがアクセスできる機密扱いの資料を収めるフォルダーや、すべての社員がアクセスできるフォルダーなどを作成できます。フォルダーに異なるアクセス許可を指定してから、コンテンツ オーガナイザーを使用してメタデータに基づいてコンテンツを適切なフォルダーに自動的に移動できます。必要に応じて、メタデータ ナビゲーションとフォルダー間のナビゲーションを併用することもできます。
コンテンツ オーガナイザー機能を使用すると、コンテンツをコンテンツ タイプやメタデータに基づいてフォルダーに自動的に移動できます。ユーザーがコンテンツの格納先を決める必要はありません。また、コンテンツ オーガナイザーは、フォルダーに格納されているアイテム数が上限に達したときに新しいフォルダーを自動的に作成することにも使用できます。大きなリストでアイテムがフォルダーに振り分けられていない場合、リスト ビューのしきい値を超える数のアイテムがいずれかのフォルダーのルートにあると、[エクスプローラーで開く] (WebDAV) は機能しません。
フォルダーベースのビューとメタデータベースのビューは、パフォーマンスに関しては大差ありません。論理的な観点とユーザー エクスペリエンスの観点から、フォルダーを使用してコンテンツを分割するのが合理的です。メタデータ ナビゲーションを使用すると、クエリが再帰的に実行され、すべてのアイテムがフォルダーの外部に返されます。これをコンテンツ取得の主な手段として使用するのであれば、フォルダーがどのような構造になっているかは重要ではありません。
以下のグラフは、さまざまな種類のビューを使用して同じ数のアイテムにアクセスすることによって実施されたテストの結果です。すべてのビューで、1,000 件の結果が返されました。このグラフは、リスト サイズの増加に伴う各ビューの 1 秒あたりの要求数を示しています。この結果からわかるのは、リスト サイズが小さいほどフォルダーのパフォーマンスが高いものの、リスト サイズの増加がフォルダーおよびインデックス付きビューのパフォーマンスに与える影響は比較的穏やかだということです。ほとんどの大きなリストの場合、フォルダーとインデックス付きビューを組み合わせて使用しても、データの取得にフォルダーまたはインデックスのどちらを使用するのがよいかを断定するほどのパフォーマンスの違いはありません。
.gif "フォルダーおよびインデックス付きビューのスループットを示す図")
フォルダーに関する推奨事項の概要
アイテムをフォルダーに振り分ける方法を計画する。アイテムは、適切なフォルダーに自動的に移動するか、手動で移動できる。
メタデータ ナビゲーションなどの機能の導入によって、フォルダー内のアイテムの量を制限する必要性は低下した。
メタデータ ナビゲーションをフォルダー ナビゲーションと併用する。したがって、フォルダーはコンテンツの取得のために編成するだけでなく、ポリシーや保持を管理するためにも使用できる。
フォルダー ナビゲーションによって最良のユーザー エクスペリエンスを提供できるのであれば、ナビゲーション方法が他にある場合でも、コンテンツをフォルダーに振り分けてナビゲーションの利便性を高めることを検討する。
コンテンツ オーガナイザーを使用してメタデータに基づいてドキュメントをフォルダーに自動的に移動する場合は、アイテム数が特定の限度値に達したときにサブフォルダーを作成してそこにアイテムを格納するオプションの提供を検討する。
[エクスプローラーで開く] (WebDAV) の使用を計画する場合は、いずれのフォルダーのルートにもリスト ビューのしきい値を超えるアイテム数が格納されないようにアイテムをフォルダーにまとめる。
コンテンツをリスト ビューに取得するときにフォルダーを使用しない場合は、メタデータ ナビゲーションとインデックスを使用する必要がある。
大きな共同作業リストおよびフォルダーの例: 製品仕様書ライブラリ
製品仕様書ライブラリでは、ナビゲーションの利便性を高め、コンテンツを論理的に配置するためにフォルダーを使用します。新しい製品仕様書を作成する場合にどのフォルダーを使用すればよいか、ユーザーはすぐに見分けることができます。製品タイプごとに 1 つのフォルダーがあり、各製品タイプには製品チームごとに複数のフォルダーがあります。各製品チームは設計中の製品のドキュメント セットを保持し、製品に固有のドキュメントがこのドキュメント セットに保存されます。これにより、以下のフォルダー構造が作成されます。
[Downhill Skis] – 製品タイプ (フォルダー)
[Racing Skis] – 製品チーム (フォルダー)
[Super Faster Downhill Racer X] – 製品 (ドキュメント セット)
各フォルダーについてメタデータの既定値を構成できます。ライブラリのユーザーは、フォルダーを使用する方法によってコンテンツを簡単に見つけることができます。
大規模なアーカイブとフォルダーの例: レコード センター
レコード センター サイトは、法令遵守のために保持する必要はあっても内容が頻繁に変更されることはないアイテムの長期的な保管に使用されます。このシナリオでは、アイテムは制限付きフォルダーと機密フォルダーに自動的にルーティングされます。制限付きフォルダーは少数のユーザーだけがアクセスできるようにアクセス許可が制限されており、ドキュメントの保存期間は 10 年です。機密フォルダーは制限付きフォルダーよりアクセスの制限が弱く、ドキュメントの保存期間は 7 年です。このようにすることで、アイテムは適切なフォルダーからアクセス許可を受け取るので、個別のアクセス許可の数が減り、アクセス許可の管理が簡単になります。レコード センター サイトに送られてくるすべてのアイテムは、メタデータに基づいて、ルート、機密、制限付きのいずれかのフォルダーにルーティングされます。
インデックス
リストごとに作成できるインデックスの数に対する制限は 20 で、この値は構成できません。これには、複合インデックスと、既定で列のインデックスを作成する SharePoint Server 2010 の機能が含まれます。インデックスを追加することによるパフォーマンスへの影響は最小限です。ただし、追加や更新などの一部の操作には影響があります。使われないインデックスはわずかですがパフォーマンスに悪影響を及ぼし、SharePoint Server 2010 の一部の機能は有効にするとインデックスを追加するので、必要以上のインデックスの使用は避ける必要があります。たとえば、有効期限機能と電子情報開示機能を使用した場合、SharePoint Server 2010 では少なくとも 3 つのインデックス スロットが必要になります。後で新しいインデックスを作成する必要がある場合、少なくとも 3 つのインデックス スロットを使用できるようにしておくことを考慮する必要があります。
SharePoint Server 2010 は、独自のインデックス作成メカニズムを使用して、データベース テーブルの構造を処理します。SharePoint Server でインデックスを作成するには、リストの設定を変更します。
インデックスの作成を計画するときは、次のことを考慮してください。
インデックスは、リスト ビューのしきい値より上でリストに対してフィルターを実行するために必要です。
インデックスの数は 20 に制限されているので、慎重に計画して単一インデックスおよび複合インデックスを作成してください。
電子情報開示や情報管理ポリシー保持など、列の作成が必要になる可能性のある SharePoint Server 2010 の機能用のインデックス スロットを確保してください。
単一のフィールドを使用してコンテンツのクエリ Web パーツでフィルター処理を行うとき、複数のフィルターを含むビューを使用するとき、およびメタデータ ナビゲーション階層と単一のフィルターとして使用されることが多い複数のフィルターを使用しているときは、単一のインデックスを作成します。
2 つの列を使用してフィルター処理を行い、リスト ビューのしきい値より多くのアイテムを個別に返すけれどもまとめて選択されることが一般的な複数のクエリの場合は、複合インデックスを作成します。
インデックスは、ドキュメントの追加やプロパティの編集などの一部の操作のパフォーマンスを低下させる場合があります。したがって、必要な場合にのみインデックスを作成してください。
慎重にインデックスを計画する
リストのインデックス数には 20 というハード制限があり、インデックスが作成された列は大きいリストにとって非常に重要です。したがって、単一インデックスおよび複合インデックスは慎重に選択する必要があります。複数の機能がインデックスを使用します。たとえば、メタデータ ナビゲーション機能は、構成されているナビゲーション階層とキー フィルターに対して自動的にインデックスを作成します。ナビゲーションおよび情報アーキテクチャでのフィルター処理にとって重要な列にインデックスを作成する必要があります。
自動的に作成されるインデックス
SharePoint Server の機能は、リスト インデックスの制限を考慮してインデックスを作成できます。次の表では、インデックスを作成された列を追加するドキュメント ライブラリで共通の SharePoint Server 2010 の機能を示します。
| 列 | 機能 | 用途 |
|---|---|---|
保留とレコードの状態 |
インプレース レコード管理または保留リストと電子情報開示 |
インプレース レコード管理サイト コレクション機能または保留リストと電子情報開示機能が有効になっていて、アイテムがレコードを宣言されるかまたはリストで保留されると、この列が追加されて、インデックスを作成されます。 |
有効期限、コンテンツ タイプ |
情報管理ポリシー |
リストに追加されるコンテンツ タイプで情報管理ポリシーに対して保持が有効になっていると、またはリストで場所ベースの保持が有効になっていると、これら 2 つの列が追加されて、インデックスを作成されます。 |
単一インデックスおよび複合インデックスを作成する場合
メタデータ ナビゲーション機能は、メタデータ ナビゲーション設定ページで選択されている階層列およびキー フィルター列に対して、適切なインデックスを自動的に作成します。すべての階層ツリー フィールドに対して、および一部のより選択的なキー フィルター型に対しては、それらが単独で使用されるときにインデックスを作成された結果および部分的な結果を返すことができるように、単一のインデックスが作成されます。階層とキー フィルターのサポートされるすべての組み合わせに対しては、ツリー フィルター値とキー フィルター値の両方が使用されるときの選択性を最大にするために、複合インデックスが作成されます。
フィルター処理を行う列が多数あるリストの場合は、インデックスの制限に達するのを防ぐため、手動によるインデックス管理が必要になる場合があります。ナビゲーション階層とキー フィルターの特定の組み合わせを使用することがない場合は、インデックスの数を減らすために、複合インデックスを作成しないことを検討します。これらのインデックスを作成するときは、リスト ビューにおいて唯一のフィルターとして、または他のフィルターを選択する前に適用される最初のフィルターとして単独で使用できる選択的な列で、単一インデックスを作成することが重要です。メタデータ ナビゲーションまたはカスタム クエリにおいて 2 つのフィルターが通常一緒に使用され、1 つのインデックスがそれ自体ではそれほど選択的ではない場合は、複合インデックスを使用する必要があります。リスト ビュー、Web パーツ、および他のデータ アクセス方法でのフィルター処理に使用される列に対してインデックスを作成します。
複数のインデックスが便利ではない場合があります。Division と Content Type という 2 つの列でフィルター処理を行う場合を考えます。これは AND 操作なので、Division と Content Type のフィルターが一致する共通部分のみが返されます。つまり、クエリが実行されると、Division フィルターに一致するすべてのアイテムが最初に返された後、これらのアイテムが Content Type によってフィルター処理されます。特定の Division に一致するアイテムが 10 個だけの場合は、データ セットが十分に小さいので、Content Type でのインデックスは関係ありません。数千個のアイテムが Division の値と一致する場合は、複合インデックスを使用する必要があります。
複合インデックスを使用すると 2 つの列に対して 1 つのインデックスを作成でき、クエリの効率が向上します。2 つの列に対して AND 操作を行うときは、複合インデックスを使用する必要があります。複合インデックスを使用する既定の SharePoint Server 機能はメタデータ ナビゲーションだけです。メタデータ ナビゲーション機能が有効になっていると、メタデータ ナビゲーション コントロールがリストに対して構成されていない場合であっても、再試行およびフォールバックのロジックが使用されます。ビューでは、メタデータ ナビゲーション クエリでない限り、複合インデックスは使用されません。
インデックス パフォーマンスの影響
1 つのコンテナー内にリスト ビューのしきい値より多くのアイテムがあるリストに対してクエリーを実行するにはインデックスが必要であり、インデックスを使用するとパフォーマンスが大きく向上します。大きいリストで効率的にクエリを実行するにはインデックスが必要であり、クエリのパフォーマンスを向上させることができますが、インデックスを維持する必要があるため、他の操作に対しては悪影響を及ぼす場合があります。アイテムを作成、更新、および削除するときは、アイテムが関係しているインデックスも更新する必要があります。10,000 アイテムのリストに対するアップロード、更新、および削除の操作でテストを実施した結果、0 ～ 20 インデックスの範囲での影響は 10 パーセント未満でした。
インデックスの作成
メタデータ ナビゲーション機能では、既定で、単一インデックスと複合インデックスが自動的に作成されます。メタデータ ナビゲーションの設定ページでは、このオプションを無効にできます。メタデータ ナビゲーション機能では自動的に、サポートされる列の各種類に対して単一インデックスが作成され、ナビゲーション階層とキー フィルターのサポートされる各組み合わせに対して複合インデックスが作成されます。2 つのキー フィルターの組み合わせに対する複合インデックスは自動的には作成されませんが、手動で作成できます。インデックスをサポートするほとんどの列の種類に対して、単一インデックスと複合インデックスが自動的に作成されます。値が少なく単独では選択性でないキー フィルターの種類に対しては、単一インデックスは自動的に作成されません。このようなキー フィルターとしては、はい/いいえ、単一値選択、コンテンツ タイプ列などがありますが、インデックスはサポートされており、手動で作成できます。
単一インデックスに対してサポートされる列
次の表では、メタデータ ナビゲーションによって自動的に作成されるインデックスについて説明します。メタデータ ナビゲーションでは、インデックスの作成をサポートするすべての列に対して単一値インデックスが作成されます。
| 列の種類 | インデックスの作成 |
|---|---|
ナビゲーション階層 |
|
単一値の管理されたメタデータ |
はい |
複数値の管理されたメタデータ |
いいえ (システム インデックスは複数値) |
コンテンツ タイプ ID |
はい |
単一値選択 |
はい |
フォルダー |
いいえ (システム インデックスはフォルダーによって作成) |
キー フィルター |
|
単一値の管理されたメタデータ |
はい |
複数値の管理されたメタデータ |
いいえ (システム インデックスは複数値) |
コンテンツ タイプ ID |
いいえ (手動で作成可) |
単一値選択 |
いいえ (手動で作成可) |
複数値選択 |
いいえ (インデックスとしては非サポート) |
数値 |
はい |
日付 |
はい |
はい/いいえ |
いいえ (手動で作成可) |
通貨 |
はい |
ユーザー (単一値) |
はい |
ユーザー (複数値)* |
いいえ (システム インデックスは複数値) |
すべてのタグ |
いいえ (システム インデックスは複数値。アイテム内のすべての管理されたメタデータ値に対する特別なフィルター) |
自動的に作成される複合インデックス
メタデータ ナビゲーション機能では、ユーザーはナビゲーション階層とキー フィルターを同時に選択できます。ナビゲーション階層とキー フィルターのすべてのサポートされる組み合わせに対して、複合インデックスが自動的に作成されます。次の表ではサポートされる組み合わせを示します。
| ナビゲーション階層 | 単一値の管理されたメタデータ | 複数値の管理されたメタデータ | コンテンツ タイプ ID | 単一選択 | フォルダー |
|---|---|---|---|---|---|
キー フィルター |
|||||
単一値の管理されたメタデータ |
はい |
いいえ |
はい |
いいえ |
いいえ |
複数値の管理されたメタデータ |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
コンテンツ タイプ ID |
はい |
いいえ |
いいえ |
いいえ |
いいえ |
単一値選択 |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
複数値選択 |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
数値 |
はい |
いいえ |
はい |
いいえ |
いいえ |
日付 |
はい |
いいえ |
はい |
いいえ |
いいえ |
ユーザー (単一) |
はい |
いいえ |
はい |
いいえ |
いいえ |
すべてのタグ |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
はい/いいえ |
はい |
いいえ |
はい |
いいえ |
いいえ |
通貨 |
はい |
いいえ |
はい |
いいえ |
いいえ |
ユーザー (複数値) |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
メタデータの選択度
メタデータの選択度は、リストのサイズが大きくなるほど重要性が増します。以下の推奨事項はすべてのサイズのリストに適用されますが、小さいリストに対してはそれほど重要ではない場合があります。
選択度とは、クエリの結果を返すために考慮する必要のあるアイテムの量です。これには、実際の選択度 (クエリの検索条件に一致する結果の総数) と、調整の選択度 (インデックスを作成された列に条件を適用した後で考慮する必要のある結果の数) という 2 つの面があります。実際の選択度は、ユーザー エクスペリエンスを検討するときの主要な考慮事項です。調整の選択度は、SQL Server のインスタンスに対する影響を検討するときの主要な考慮事項です。
メタデータ ナビゲーションおよび他のリスト フィルター処理メカニズムを効果的に使用するには、フィルター処理に使用されるメタデータが選択的である必要があります。既定では、ユーザーが結果をすばやくスキャンして差害しているものを見つけられるように、リスト ビューには 30 アイテムが表示されます。クエリから 30 より多くの結果が返る場合は、ユーザーはページ操作を使用して結果を探す必要があります。コンテンツのクエリ Web パーツを使用している場合は、結果の一般的な数は 10 ～ 15 です。これより多くの結果がある場合、超えた分の結果は表示されません。クエリの結果が何百にもなる場合、探しているものを見つけるのは難しくなります。選択度は、リスト ビューのしきい値を超える操作を避けるためにも重要です。リスト ビューのしきい値を超えると、メタデータ ナビゲーションの場合は、フォールバックが発生し、すべての結果が返されなくなります。
コンテンツ オーガナイザーと自動分散
コンテンツ オーガナイザーは、ドキュメント リポジトリ内のコンテンツを整理するための中心的なコンポーネントになる場合があります。コンテンツ オーガナイザーを使用するリポジトリは、ユーザーが最終状態になったドキュメントをアップロードする送信エクスペリエンスを備えています。コンテンツ オーガナイザーを使用できるシナリオの例を次に示します。
メタデータに基づくサイト間およびサイト内でのドキュメントの自動ルーティング
自動的なドキュメントのルーティングと新規フォルダーの作成 (日、月、年の単位でのフォルダーなど)
フォルダー間でのアイテム数の自動的な分散
データのアクセスと取得
ほとんどの大きなリストの主要な目的は、取得できるようにコンテンツを格納することです。ユーザーがコンテンツを取得する方法を計画することは、大きなリストのパフォーマンスおよび大きなリストの実装の成功に大きく影響するので、重要なことです。検索、メタデータ ナビゲーション、コンテンツのクエリ Web パーツ、ビューなどの複数の機能をすべて、ユーザーによるコンテンツの取得に役立てることができます。データをクエリするカスタム Web パーツなどのカスタム ソリューションも、一般に使用されます。Web サイトの編成方法を前もって計画します。ドキュメント センター サイトのホーム ページなどの一元的な先頭ページを使用してコンテンツを集約し、大きなリストへのエントリ ポイントを提供できます。また、発行ページを使用して、ページごとにさまざまなトピックがカバーされている Web サイトを作成した後、Web パーツを使用して大きなリストから関連のあるドキュメントやアイテムを収集できます。データのアクセスと取得に関する考慮事項は次のとおりです。
検索、コンテンツのクエリ Web パーツ、メタデータ ナビゲーション、リスト ビュー、カスタム Web パーツの任意の組み合わせを使用できます。
コンテンツの取得方法およびフィルターと並べ替えに使用する列を前もって計画します。
基本的なページ モデルを計画します。すべての作業をドキュメント ライブラリ内で実行するかどうか、先頭ページを用意するかどうか、または関連するコンテンツにリンクする複数ページ モデルを使用するかどうかを検討します。
データ アクセス方法
簡単な構成でリスト データのクエリとフィルターに使用できる SharePoint Server 2010 の主要な機能として、リスト ビューとメタデータ ナビゲーション、コンテンツのクエリ Web パーツ、検索の 3 つがあります。それ以外にもカスタム コードを使用してリストをクエリするためのオプションがありますが、この記事ではこれらのオプションについては説明しません。
ビューを使用すると、表示される列を構成できます。リスト データにはさまざまな表示方法があります。列に基づいて結果のフィルター処理と並べ替えを行うように、ビューを構成できます。
- メタデータ ナビゲーションは、SharePoint Server 2010 のリスト ビューに対するフィルター処理コントロールです。メタデータ ナビゲーションを構成するときに、メタデータ階層とキー フィルターを選択して、リスト ビューに表示される結果のフィルター処理を動的に行うことができます。
コンテンツのクエリ Web パーツには、SharePoint Server 2010 リストのデータが表示されます。1 つ以上のリストから結果を返すようにクエリを構成できます。既定では、コンテンツのクエリ Web パーツはキャッシュされます。ただし、キャッシュを無効にすることもできます。
検索ボックスまたは検索結果 Web パーツは、検索結果を返すために使用できます。検索メタデータ絞り込みコントロールを使用して、結果を特定のリストに絞り込んだり、ガイド付き検索を実行したりできます。
次の表ではクエリ方法とその使用方法を説明します。
| クエリ方法 | 用途 |
|---|---|
リスト ビューとメタデータ ナビゲーション |
リスト ビューは常に SQL Server のバックエンド データベースにアクセスするので、パフォーマンスに対する影響が最も大きいクエリであり、SQL Server に大きな負荷がかかります。ドキュメントを操作するための豊富なオプション (チェックイン、チェックアウト、プロパティの編集) およびデータへのリアルタイム アクセスを提供する場合は、リスト ビューを使用します。 |
コンテンツのクエリ Web パーツ |
コンテンツのクエリ Web パーツは、ポータル サイト マップ プロバイダーを使用してクエリをキャッシュします。また、表示される HTML の量が最も少ないので、クエリと表示に要する時間が最短です。動的なナビゲーションおよび 1 ページで複数のクエリを実行する場合は、コンテンツのクエリ Web パーツを使用します。 |
コンテンツのクエリ Web パーツのキャッシュなし |
データへのリアルタイム アクセスを提供するため、コンテンツのクエリ Web パーツはデータベースを直接クエリできます。クエリをキャッシュできない場合、リアルタイムの更新が必要な場合、および 1 時間のアクセス回数が 1 回未満であるためキャッシュに格納されないページの場合は、この構成を使用します。キャッシュされるコンテンツのクエリ Web パーツでは、最初の読み込みによって余分なオーバーヘッドが発生します。 |
検索 |
拡張が容易で読み取りパフォーマンスに最適化されているサーバー インフラストラクチャに読み取りをオフロードするには、検索クエリを使用します。静的なクエリを使用するように検索クエリを構成することも、ユーザーが検索クエリを指定できるようにすることもできます。 |
コンテンツのクエリ Web パーツ
コンテンツのクエリ Web パーツを使用した場合の利点と欠点を次の表にまとめます。
| 利点 | 欠点 |
|---|---|
|
|
コンテンツのクエリ Web パーツは、リストからコンテンツを取得するために使用されます。ページ、ドキュメント、およびリスト アイテムに対して使用できます。コンテンツのクエリ Web パーツは既定でキャッシュされるため、パフォーマンスに優れ、SQL Server リソースに対する影響が大きくありません。既定のキャッシュ設定は 30 分間です。したがって、データは十分に最新の状態が維持されます。ただし、このことは、コンテンツのクエリ Web パーツが検索クエリより多くの SQL Server リソースを使用することも意味します。コンテンツのクエリ Web パーツはレンダリングする HTML の量が少ないので、ページのレンダリングが速く、1 ページに複数のコンテンツのクエリ Web パーツを構成できます。キャッシュされるコンテンツのクエリ Web パーツを使用すると、リストのサイズが大きくなってもデータにすばやくアクセスできます。キャッシュされないコンテンツのクエリ Web パーツの遅延時間は、同様のリスト ビュー クエリーとほぼ同じです。
コンテンツのクエリ Web パーツをナビゲーション コンポーネントとして使用し、ページでコンテンツのロールアップを提供する必要があります。たとえば、ページを使用してドキュメント ライブラリ内に存在するコンテンツの概要を提供し、コンテンツのクエリ Web パーツを使用して関連するページとドキュメントを返します、他の例としては、現在のユーザーによって変更されたアイテム、最新のアイテム、最高レートのアイテムなどがあります。コンテンツのクエリ Web パーツは、ほとんどのユーザーがチェックイン、チェックアウト、バージョン管理などのリスト操作を実行する必要がない読み取り中心のシナリオで使用できます。次に示すのは、最高レートのドキュメントが表示されているコンテンツのクエリ Web パーツです。
.gif "最高レートのドキュメントのスクリーンショット")
コンテンツのクエリ Web パーツを使用すると、リスト ビューを入力せずにコンテンツにアクセスできます。ユーザーは、少ない量のコンテンツに頻繁にアクセスする場合や、アイテムを追跡する場合があります。ドキュメント センター サイト テンプレートでは、3 種類のコンテンツのクエリ Web パーツが既定で使用されています。ログインしているユーザーによって変更されたアイテムを返す Web パーツ、最高レートのドキュメント用の Web パーツ、そして最新のドキュメント用の Web パーツです。これら 3 つのコンテンツのクエリ Web パーツを組み合わせて提供される先頭ページでは、ユーザーが最も頻繁にアクセスするコンテンツや、最も関心を持っているコンテンツが表示されます。これにより、新しいコンテンツの発見や、頻繁に使用するドキュメントへのすばやいアクセスが促進されます。もう 1 つの例として、お気に入りリストを作成してユーザーが注目するコンテンツをマークできるようにしておき、コンテンツのクエリ Web パーツを使用してお気に入りリストを返し、ユーザーがリスト自体にアクセスすることなく頻繁に使用するコンテンツにすばやくアクセスできるようにすることができます。
大きなリストでコンテンツのクエリ Web パーツを使用するときは、正しい結果が返り、リスト ビューのしきい値によってブロックされないように、考慮する必要のある重要なことがいくつかあります。インデックス列を使用することにより、アイテムをフィルター処理して、リスト ビューのしきい値より少なくする必要があります。リストの 1 つが大きなリストの場合は、リスト間でのクエリを使用しないことをお勧めします。リスト間でのクエリにおいて考慮されるアイテムの総数が、監査者と管理者に対するリスト ビューのしきい値 (既定では 20,000) を超えると、操作がブロックされます。
コンテンツのクエリ Web パーツの推奨事項のまとめ
ユーザーが頻繁にアクセスするアイテム、注目しているアイテム、またはコンテンツの発見に役立つアイテムを返すには、コンテンツのクエリ Web パーツを使用します。
大きなリストに対してコンテンツのクエリ Web パーツを使用するときは、アイテムをフィルター処理し、クエリがリスト ビューのしきい値を超えないようにします。
フィルター処理にはインデックスのある列だけを使用する必要があります。
考慮されるアイテムの総数が監査者と管理者に対するリスト ビューのしきい値 (既定では 20,000) を超える場合は、コンテンツのクエリ Web パーツを使用して複数のリストをクエリしないでください。
読み取りの時間を短縮し、SQL Server の負荷を抑えるには、キャッシュを使用します。
検索 Web パーツ
検索 Web パーツの利点と欠点を次の表にまとめます。
| 利点 | 欠点 |
|---|---|
|
|
検索クエリの方が、SQL Server リソースの直接アクセスより拡張性が優れています。これは、検索が読み取り中心のシナリオ用に最適化されていて、複数の検索インデックス サーバーとクエリ サーバーにスケール アウトする方が、SQL Server インスタンスを拡張するより簡単なためです。あらかじめ構成されている検索 Web パーツ、検索ボックス、またはこれらの組み合わせを使用して、ユーザーによるコンテンツの取得を支援できます。検索クエリでは、クエリを検索インデックスにオフロードして SQL Server の負荷を軽減する手段が用意されています。また、検索クエリは、コンテンツのクエリ Web パーツまたはリスト ビュー クエリと比較して、リストのサイズによる影響が小さくなります。
任意のシナリオで検索を使用して、構成済みのクエリまたはユーザー指定のクエリからの結果を表示できます。検索は高い規模ポイントにおいて最高のパフォーマンスを提供します。検索の結果は最後のクロールの時点のものまでなので、リスト操作を実行する必要がある場合、またはデータをリアルタイムで表示する必要がある場合は、検索を使用できません。次の表では、使用できる 3 種類の検索 Web パーツを示します。
| 検索 Web パーツ | 説明 |
|---|---|
主要な検索結果 Web パーツ |
ページ操作のある完全な結果であり、最も多くの機能を備えた Web パーツです。システム クエリまたはユーザー指定のクエリを受け取ることができます。 |
フェデレーション検索結果 Web パーツ |
完全な結果にアクセスするためのオプションのリンクを備えた結果の小さいセットです。 |
検索ボックス Web パーツ |
クエリに対するユーザー入力を受け取るために使用される Web パーツです。 |
リスト ビュー
リスト ビューの利点と欠点を次の表にまとめます。
| 利点 | 欠点 |
|---|---|
|
|
リスト ビューとメタデータ ナビゲーションは、フォルダーとインデックスのどちらか一方または両方を使用する大きなドキュメント ライブラリでのコンテンツの取得をサポートできます。リスト ビューでのクエリはリアルタイムで実行され、SQL Server データベースを直接クエリします。これにより最新の結果が提供されます。ただし、パフォーマンスに対する影響も最大になります。リストのサイズが大きいと、全体的なスループットが低下し、操作の待機時間が増加します。また、リスト ビューでは読み込むページのほとんどの内容が表示されます。したがって、ページの表示時間が長くなることがよくあります。
アイテムに対してリスト ビュー操作を実行できる必要がある場合は、メタデータ ナビゲーションとリスト ビューを使用する必要があります。リスト ビューは、読み取りの少ないシナリオでリストを操作する場合に、主要な方法として使用できます。読み取り操作の多いシナリオでは、リスト データにアクセスするための主要な方法として、他のクエリ方法を検討する必要があります。
ビューの構成
ビューの構成に関する考慮事項のまとめ
ビューで使用する列を慎重に選択します。列の数が多いほど表示されるデータが増え、ページの読み込み時間が長くなります。ページの読み込み時間と最善のユーザー エクスペリエンスの間にはトレードオフがあります。
他のデータベース テーブルとの結合が発生し、データベースの読み込みが増えるため、ビューでの Managed Metadata やユーザーおよびグループなどの検索列の使用を最小限にします。
列の合計は使わないようにします。
インデックス列を使用してビューをフィルター処理しない場合は、フォルダーのアイテムを表示するためのオプションを選択して、個別のフォルダーにリスト ビューのしきい値を超えるアイテムが含まれないようにします。
ビューをインデックス列でフィルター処理し、表示されるアイテムの数を少なくして、リスト ビューのしきい値を超えないようにします (特に、サブフォルダーがない場合、またはフォルダーに含まれるアイテムがリスト ビューのしきい値より多い場合)。
メタデータ ナビゲーション機能を有効にし、クエリの最新の結果が返されるようにします。この機能を有効にしないとリスト ビューのしきい値によって禁止されます。この機能は、ほとんどすべてのサイトにおいて既定で有効になっています。
フィルター処理されたビューとメタデータ ナビゲーションを組み合わせて使用する場合は、場所ごとのビューを使用してメタデータ ナビゲーション ピボットに対するフィルター処理されないビューを作成し、すべての結果が返されるようにすることを検討します。
列と参照列の数
ビューは、リスト データへのアクセスに使用される最も一般的な方法です。ユーザーによるコンテンツの検索方法が最適になり、パフォーマンス要件が満たされるように、慎重にビューを選択する必要があります。大きいリストの場合は、ビューの構成方法に特に注意を払います。標準ビューとカスタム ビューだけを使用することをお勧めします。データシート ビュー、ガント ビュー、およびカレンダー ビューは、リスト ビューのしきい値によってブロックされる場合があるので、リスト ビューのしきい値を超えるリストでは使用しないことをお勧めします。ビューの列の数はできる限り少なくする必要がありますが、参照列 (Managed Metadata、ユーザーおよびグループ、検索の種類) の数には特に注意する必要があります。参照で他のテーブルとの結合が実行されて、パフォーマンスに影響があるためです。
列のフィルター処理と合計
SharePoint Server 2010 での新しいリスト ビューのしきい値は、大きいリストでビューを使用する方法に対する主要な変更点です。ビューがリスト ビューのしきい値より多い結果を返そうとすると、エラーが発生します。大きいリストで合計を使用すると、リスト ビューのしきい値によって常にブロックされます。したがって、使用しないでください。重要なのはスキャンする必要のあるアイテムの数であり、必ずしも返される行の数ではありません。ビューに column Color = “Red” というフィルターがあり、Color がインデックス列ではない場合、禁止される場合があります。このクエリに一致するアイテムが 100 個しかない場合であっても、リストに 10,000 個のアイテムがある場合は、クエリは 10,000 個のアイテムをスキャンする必要があります。この場合、ユーザーがビューにアクセスしようとするとエラーが発生します。この問題を解決するには、フォルダー、フィルターとインデックス、およびメタデータ ナビゲーションを使用できます。
フォルダー
リスト ビューのしきい値より多くのアイテムを含むフォルダーがないようにリストが編成されている場合は、フォルダーのアイテムを表示するオプションを選択できます。結果の数がリスト ビューのしきい値少なくなるようにフィルター処理を行うメカニズムを使用していない限り、フォルダーの外部にあるすべてのアイテムの表示は行わないようにする必要があります。
インデックス作成
前の例では、列 Color に対してクエリを実行すると、インデックスが作成されていないので失敗します。この問題を解決するには、Color 列のインデックスを作成します。その後でクエリを実行すると、値が十分に異なっていれば成功します。赤のアイテムが 100 個だけであれば、問題なく動作します。しかし、一致するアイテムの数がリスト ビューのしきい値より多いと、インデックスを作成してもブロックされます。既定では、ID フィールド、フォルダー構造、および複数値参照に対しては、システムでインデックスが作成されます。フィルター処理用に新しい列を作成して使用する場合は、手動でインデックスを作成する必要があります。
ビューの例
最近変更されたアイテム
最近変更されたアイテム ビューは、最近変更されたアイテムを表示するために使用されます。最近変更された複数のソースからのコンテンツにユーザーが頻繁にアクセスする場合、既定のビューとして使用できます。このビューは、すべてのアイテムに対して常に設定されるシステム メタデータを使用するので、簡単に構成できます。大きいリストの場合は、アイテムの制限をリスト ビューのしきい値より低く設定するか、またはリスト ビューのしきい値より少なくなるように結果をフィルター処理する必要があります。このビューを作成するには、Modified フィールドのインデックスを作成し、降順に並べ替える必要があります。Modified 列に対してフィルターを指定し、[Today-x] という式を使用します。x はデータを表示する日数です。"以上" オプションを選択します。式 [Today-x] は、リスト ビューのしきい値より少ない数のアイテムを返す必要があります。
個人用アイテム
個人用アイテム ビューは、ユーザーが自分のドキュメントに頻繁にアクセスするリポジトリで使用できます。このビューは、すべてのアイテムに対して常に設定されるシステム メタデータを使用するので、簡単に構成できます。このビューでは、Modified By 列と Created By 列のどちらか一方または両方でフィルター処理を行います。フィルターでこのビューを作成するには、Modified By 列を選択し、値を [ME] に設定します。次に、OR を指定して Created By 列に第 2 のフィルターを設定し、値をやはり [ME] に設定します。複数のユーザーが同じドキュメントを編集している場合、Modified By 列に加えて Created By 列を使用する必要があります。Modified By は複数ユーザー列ではありません。したがって、このビューでは、ユーザーが変更したすべてのドキュメントが表示されない場合があります。この例では、操作が OR 操作であるため、両方の列のインデックスを作成する必要があります。
まとめ
SharePoint Server 2010 では、大きいリストを使用するときのユーザー エクスペリエンスとパフォーマンスの向上につながる新機能および強化された機能が提供されています。スロットルと制限は、他のユーザーに対するファームのパフォーマンスを保護し、操作によって必要以上に多くの SQL Server リソースが使用されるのを防ぎます。メタデータの拡張とメタデータ ナビゲーションは、リスト データの取得に関して向上したエクスペリエンスを提供し、コンテンツのクエリ Web パーツ、検索、およびリスト ビューは、大きいリストで動作するように構成できます。それでも、要件に対して正しいソリューションを作成するには、慎重な計画が必要です。ただし、よいパフォーマンスで動作するように設計されている既定のソリューションを構成することで、大きいリストをすばやく開発できます。