リスト ビューのしきい値に関する FAQ

こんにちは SharePoint サポートの森　健吾 (kenmori) です。

今回の投稿では、リスト ビューのしきい値についてご説明します。
この制限に関する情報は多数公開されておりますが、本投稿では可能な限りわかりやすくご説明することを目標に進めております。

画面上で何が発生するのか、どのようなパターンで発生するのかを先に確認したい方もいらっしゃると思います。
しかし、リスト ビューのしきい値はデータ アクセス層のエラーですので、画面上で発生する現象は様々となります。そのため、最初に個別のシナリオを確認するとかえって混乱する結果となりますため、まずはリスト ビューのしきい値が何なのかを先に抑えることが重要です。
本投稿はリスト ビューのしきい値を理解するために作成しました。個別のシナリオについてはこちらをご確認ください。

タイトル : 多数のアイテムがあるリストとライブラリを管理する
アドレス : https://support.office.com/ja-jp/article/%e5%a4%9a%e6%95%b0%e3%81%ae%e3%82%a2%e3%82%a4%e3%83%86%e3%83%a0%e3%81%8c%e3%81%82%e3%82%8b%e3%83%aa%e3%82%b9%e3%83%88%e3%81%a8%e3%83%a9%e3%82%a4%e3%83%96%e3%83%a9%e3%83%aa%e3%82%92%e7%ae%a1%e7%90%86%e3%81%99%e3%82%8b-11ecc804-2284-4978-8273-4842471fafb7?ui=ja-JP&rs=ja-JP&ad=JP

 

Q1 : リスト ビューのしきい値とは何なのか？

リスト ビューのしきい値とは、ユーザー観点でいうと、同一階層で表示 (ビュー) できるアイテムの数です。
リストビューのしきい値の 5000 件を、ドキュメントライブラリやリストに登録できるアイテムの件数と混同されている場合があります。Office 365 や SharePoint オンプレミスにおける個人用ストレージである OneDrive for Business もドキュメント ライブラリであるため、同様の制限が適用されます。リストに登録できるアイテムの件数とは異なる点にはご留意ください。

リスト ビューのしきい値を超過した操作を実施しようとした際に下記のようなエラーが発生します。
特にデータ量が増えてきたときに、リスト ビュー表示時に下記のようなエラーが発生して気づく場合が多いでしょう。

エラーメッセージ

このビューは、管理者が設定したリスト ビューのしきい値 (アイテム 5000 個) を超えるため、表示できません。
アイテムを表示するには、別のビューを選択するか、新しいビューを作成してください。このリストのビューを作成できる適切な権限を持っていない場合は、システム管理者に依頼して、リスト ビューしきい値に準拠するようにビューを変更してください。

その他、エクスプローラでは同様のエラーを表現する術がないため、ドキュメント ライブラリをエクスプローラ ビューで表示すると空に見えたりします。この他にも表面に出てくる現象は様々ですが、すべて上げると逆に複雑になりますため、まずは上記のみ記載します。

Q2 : なぜ、リストビューのしきい値があるのか。

サーバーの安定稼働を守るためのひとつの方法として導入されました。

SharePoint は近年、ホスティングにおける利用なども拡大しております。このホスティングには SharePoint Online も含まれます。このような運用形態においては、サーバーの安定稼働を目的とするサーバー管理者と、コンテンツの利便性を追求するサイト コンテンツの管理者の役割が分担されている実情があります。

サーバー管理者は、複数の利用者が公平に問題なく利用できるよう管理する必要があります。そのため、例えば、ある特定の利用者の利用方法が他の利用者に悪影響を及ぼすことを防ぐ必要が生じます。
SharePoint は、これまでの稼働実績をもとにした経験から、サーバー安定稼働のための様々なリソース制限や、早期問題解決のための Health Analyzer などの機能が追加されてきている背景があります。

サーバーの管理者とコンテンツの管理者が同一人物である場合は、上記の説明は理解しにくいかもしれません。しかし、最終的には、システムの安定性は、利用者にとっても重要な点です。この目的を達成することがリスト ビューのしきい値が導入された主な要因となります。

 

Q3 : なぜ、5000 件なのか。少なくないか？

リスト ビューのしきい値は、正確に一言で言うとデータベースにアクセスする際に生じる行ロックの数をアプリケーション側で制限し、サービスの停止を阻止する積極的な仕組みとなります。
この設定で、行ロックの数が 5000 を超える際には処理をブロックします。この動作によって、ロックによるメモリ消費量を抑えることで、データベース サーバーのメモリ枯渇や性能低下などの緊急性の高い状況の発生を防ぐために実装されています。

SharePoint Server の実装やボトルネックとは一切関係ありません。5000 という値は、SQL Server のロックエスカレーションを根拠に指定されています。5000 という値は SharePoint に限らず、データベースを利用するアプリケーションにおいて一度のデータ操作で留意すべき目安の値ということになります。

( 大規模なデータ アクセスへの対処の構図)

 下記に詳細をご説明します。

1) SQL Server の対策

SQL Server にはロック エスカレーションという仕組みがあり、ロック オブジェクトによるメモリ消費を抑える仕組みがあります。

最初にロックについて説明します。SQL Server は、データの整合性を確保するために、ロックという仕組みがあります。例えば、先にトランザクションが開始されたセッション Aが読み取り中の行データを、別セッション Bが更新しようとしたとします。データの整合性を守るためには、セッションA のトランザクションが終了するまで、セッション B の更新内容は行われるべきではありません。そのため、後で実行されたセッション B は、セッション A の結果を待つ必要があります。このような動作を実現するために、SQL Server はデータの読み取る際に対象の行に共有ロックをかけ、更新処理などによる排他ロックが獲得されることを防ぐ実装になります。

上記の様に行ロックは一度に更新する範囲が大きくなるにつれ数が多くなり、そのためのメモリも多く使用する結果となります。しかし、ロックのためのメモリは大量に保持してもパフォーマンス上有効ではありません。むしろ、データベース サーバーが使用する利用可能なメモリサイズには制限があるため、ロックのために必要なメモリ容量が増えれば、メモリでキャッシュできるデータ容量が減ります。

データベース サーバーは使用頻度の高いデータをメモリ上にキャッシュすることで性能を高めています。メモリ上のデータへのキャッシュヒット率が低下すると、その分ディスクアクセスを実施して結果を返す動作となりますため、性能が悪化します。
さらに、そのままメモリが不足し続けると、最悪の状況としてはデータベース サーバーが応答を返せず、システムおよびサービスが停止する状況に至ります。稼働中のサービスがこのような状況に陥った場合、多額の損害が発生することは免れません。

SQL Server は、製品としてこの問題を防ぐため、ロック用のメモリを小さくするための対処を実装しています。ロックエスカレーションは、メモリがしきい値より少なくなるか、セッションごとに 5000 件以上の行ロックが割り当てられた際に、テーブル単位のロック 1 つに切り替えることで、ロックのためのメモリ消費を抑えます。

なお、特定の用途のために開発されたビジネス アプリケーションでは、開発者がテーブル構造やクエリ、インデックスなどをチューニングしているため、必要な最小限のリソースにアクセスするようになっています。チューニングされていることが前提であれば、SQL Server は 5000 という値を現実的に適切と判断し、絶対値としてこの数以上のデータを参照した際にロックエスカレーションするようになっています。

( 補足)

ロック エスカレーションは、ロックによるメモリ消費問題への緩やかな対処であり、完全な対処策ではありません。ロックの対象範囲がテーブル ロックに拡大すると、同じテーブルに対するロック解放待ちのため複数ユーザーによる並列アクセスが直列化し (ブロッキング) 、順次処理される動作となります。さらに大量のアクセスと重なると遅延が拡大していきます。
ロック エスカレーションが発生すると、ただちに何か問題が発生するわけではありませんが、ロックエスカレーションとアクセス多重が重なるとメモリを消費する状況を防げても、パフォーマンスの低下が生じる問題が残ります。そのため、根本対策のためにはデータベースのチューニングやサイジング、サーバーの負荷分散が不可欠となります。

2) SharePoint の対処策

SharePoint では、リスト ビューのしきい値によって処理をブロックすることで、ロックによるメモリ消費の増大、その先にあるサービスの停止を阻止するために、積極的なアクションを実施しています。

SharePoint Server 2013 では、コンテンツ データベース内のテーブルの定義にてロック エスカレーションの発生を無効化しました。データベース サーバーの設計に頼らず、アプリケーション側でより積極的な対処を実施することを選択しています。ただし、SQL Server におけるロック エスカレーションのしきい値である 5000 は、行ロックによるリソース消費を抑えるという目的を共有して、SharePoint においてもリスト ビューのしきい値を定める根拠として使用されています。

SharePoint は製品として、ユーザーが自由にリストのデータの型を決めることができ、フィルター、並び替え、グループ化など、様々なビューの表示形式のカスタマイズが可能です。アプリケーション開発者が、データベース設計をしたり、チューニングをしたり、処理フローを開発することなしに、使用を始められる製品となっております。その反面、無計画に大きなリストを使用するとシステムがパフォーマンスの問題に直面します。この状況を防ぐためには、利用者側が適切な運用方法を理解する必要があります。

ユーザーごとに様々な利用方法があるため、SharePoint は特定の用途に対してのみチューニングすることはできませんが、利用者側でもチューニングができるよういくつかの方法 (列のインデックスやフォルダー階層) を設けています。その方法を守ると、しきい値の現象を緩和することができます。その方法は Q5 にて後述します。

上記説明の通り、SharePoint のように自由にデータ型が定義できるアプリケーションにおいては、パフォーマンスへの影響は利用者が必ず考慮すべき項目となります。同じように自由なデータを定義できるアプリケーションでは、一度に 5000 以上のデータにアクセスする処理が重なると、ロックメモリによるメモリ枯渇や、ロックエスカレーション (SharePoint では無効化済み) による大規模なブロッキングを生じさせます。この影響は、もちろん他社製品も例外ではありません。

SharePoint はアプリケーションの性質上、直面する可能性のある問題を事前にユーザーに伝え、運用段階において多大な影響が発生する前に、あらかじめユーザーがサイジングを意識でき、事前にチューニング等の対処を打てるよう周知させる設計を選択しています。

Q4 : 5000 件以上登録できないのか？リストには何件のアイテムが登録できるのか？

リストには、公開資料に記載の通り、合計 3 千万件から 5 千万件程度のデータが格納できます。この値は、ほとんどの利用シナリオを考慮しても十分な数値であると言えるでしょう。
5000 件以上のデータを一度に登録するとリスト ビューのしきい値に該当しますが、一度に登録・更新さえしなければ 5000 件以上のアイテムを登録することは可能です。

例)

上記に記載の通り 5016 個のアイテムが登録されています。ただし正常に登録された後で、データを表示する際にリスト ビューのしきい値に該当したデータアクセスが発生した場合、ビューがエラー表示になります。

Q5 : リスト ビューのしきい値を考慮して、どのように運用したらいいのか。

インデックス付の列とフォルダー分割を理解し、適切に実施する必要があります。この質問への回答は、別途詳細な記事で紹介しますが、ここではポイントとなるインデックス付きの列とフォルダー分けについて紹介します。

インデックス付きの列

SharePoint のインデックス付き列は、SQL Server のインデックス同様、列へのデータアクセスを最適化します。リストの設定画面の下記の箇所で設定が可能です。

 インデックス付の列を使用すると、インデックスを使用して実データに効率的にアクセスが可能となります。インデックスがない場合は、すべてのデータを確認した上で必要なデータにアクセスする必要が生じます。

インデックス付きの列を絞り込み項目や並べ替え項目として指定すると、リストやライブラリのアイテム総数がしきい値を超えていたとしても、一度に取得する結果アイテム数がリスト ビューのしきい値の範囲内であれば、データを抽出することが可能になるよう設計されています。
上記の通りインデックス付きの列は、データの分布をインデックス側が管理しているため、実データにアクセスせずに必要な絞り込みを行える点に起因します。

既定で並び替えのキーとなっているドキュメント ライブラリの名前 (フォームで使用) 列やリストの ID 列は、暗黙的なインデックス付きの列です。そのため、この列で並べて最初の 30 件を取得する標準のビューでは、アイテム数 5000 件を超えてもエラーになりません。

また、エクスプローラ ビューでは、インデックス付の列を使用したビューの表示制御はできませんので、下記のフォルダー分割を実施する必要があります。

 

フォルダー分割

データをフォルダー分けすることでも、データ構造上効率的にデータアクセスが可能となります。
フォルダー分割を用いることでも同様、リストやライブラリのアイテムがしきい値を超えていたとしても、一度に取得する結果アイテム数がリスト ビューのしきい値の範囲内であれば、データを抽出することが可能です。

 

ただし、フォルダー分割は、例外的に以下のようないくつかのシナリオがカバーできていない状況があります。大規模のリストを作成する際には、この点を別途考慮する必要があります。

・配下に 5000 件以上のアイテムを持つフォルダーを名前変更、移動する。
・配下に 5000 件以上のアイテムを持つリスト・フォルダーの権限を継承・切断する。
・リストに集計列を追加する。

この例外のシナリオを含めたより詳細については、下記サイトに紹介していますので、併せてご確認ください。

タイトル : リスト ビューのしきい値によって発生する現象と対処策
アドレス : https://blogs.technet.com/b/sharepoint_support/archive/2015/05/16/sharepoint-list-view-threshold-story.aspx

今回の投稿は以上になります。