Разработка крупных списков с обеспечением максимальной производительности списка (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

• Методика измерения и тестирования производительности

• Настройки и ограничения

• Прочие ограничения

• Различия между большими и обычными списками

• Проектирование и реализация больших списков

• Заключение

Общие сведения о методах запросов

Существуют три основных метода доступа к данным списков: представления списка с навигацией для метаданных, веб-часть "Запрос контента" и поиск. Каждый метод имеет свои преимущества, недостатки и предпочтительные области применения.

Представление списка и навигация для метаданных

Представления списка всегда обращаются к базе данных Microsoft SQL Server. Это приводит к более медленному выполнению запросов и более высокой нагрузке на ресурсы SQL Server по сравнению с другими методами. Представления списка также обрабатывают большую часть HTML-кода, что приводит к более медленной загрузке страниц по сравнению с другими методами. Однако представления списка предоставляют пользователям наиболее удобные возможности по настройке представлений, динамической фильтрации данных и выполнению действий с документами, например управлению версиями и изменению свойств. С помощью навигации для метаданных можно фильтровать результаты представления списка. Представления списка следует использовать в том случае, если в столбцах используются данные расширенных типов или если необходим доступ к действиям с элементами списка. В сценариях с высокой интенсивностью запросов и операций чтения следует обратить внимание на другие методы запросов.

Веб-часть "Запрос контента"

Веб-часть "Запрос контента" служит для отображения статически настроенного представления данных, кэшируемого с помощью поставщика карты сайта портала с целью повышения производительности. Веб-часть "Запрос контента" обрабатывает минимальный объем HTML-кода и использует кэширование. Результатом этого является более быстрая загрузка страниц и удобство использования нескольких запросов на одной странице. Веб-часть "Запрос контента" следует использовать для отображения ссылок на связанные элементы списка, документы или страницы. Хотя для веб-части "Запрос контента" можно отключить кэширование, это следует делать только на страницах с невысокими требованиями к пропускной способности или на страницах, для которых использование кэша бесполезно, например если запросы изменяются в зависимости от пользователя, обращающегося к странице.

Поиск

Веб-части поиска могут использоваться для перенаправления запросов в систему, оптимизированную для поиска контента (а не для изменения свойств и просмотра обновлений в режиме реального времени). Веб-части поиска можно настроить на использование статических или задаваемых пользователем запросов. Такие веб-части обеспечивают высокую производительность. Однако актуальность данных зависит от времени последнего обхода контента. Это означает, что предоставляются более старые результаты, чем при использовании представлений списка или веб-частей "Запрос контента".

Примеры сценариев использования больших списков

Имеется несколько стандартных сценариев использования больших списков, и в зависимости от сценария будут приниматься разные проектные решения. Например, в случае совместного использования большого списка пользователи часто добавляют контент и изменяют свойства. В такой ситуации нежелательно, чтобы размер списка увеличивался до многих миллионов элементов, поскольку это затруднит фильтрацию контента и поскольку контент часто обновляется и изменяется. Если вы работаете с неструктурированными библиотеками документов, эта статья поможет разобраться с настройками и ограничениями, обеспечивающими производительность SQL Server. В следующей таблице показаны основные моменты, которые следует учитывать в сценариях использования больших списков.

Сценарий	Размер списка	Управление	Соотношение операций чтения, изменения и добавления	Новый контент	Пользователи
Неструктурированная библиотека документов	Сотни	Менеджер отсутствует	Высокая частота операций чтения, сбалансированная частота операций добавления и изменения	Отправка вручную	Десятки
Библиотека или большой список для совместной работы	Тысячи	Неофициальные владельцы по темам	Высокая частота операций чтения, частота изменений превышает частоту добавления	Отправка вручную	Сотни
Структурированный большой репозиторий	Десятки тысяч	Назначенный управляющий контентом	Очень высокая частота операций чтения, более низкая — добавлений, значительно более низкая — изменений	Передача и отправка	Десятки тысяч
Крупномасштабный архив	Миллионы	Группа управляющих контентом	Низкая частота операций чтения и изменения, высокая — добавления	Передача	Десятки тысяч

Неструктурированная библиотека документов

Неструктурированная библиотека документов часто используется для рабочей группы и как правило содержит от десятков до сотен документов. Без надлежащего планирования такие библиотеки могут разрастаться сверх порогового значения представления списка, что может повлиять на выполнение операций, например добавление столбцов. Одной из возможных проблем является то, что пользователи начнут получать исключения, если число элементов в представлениях списка будет превышать пороговое значение, равное 5000. Этого можно избежать путем наблюдения за библиотеками, число элементов в которых приближается к пороговому значению представления списка. (Соответствующий индикатор отображается на странице параметров библиотеки документов.)

Такой сценарий, как правило, предполагает десятки или даже сотни пользователей, однако число одновременных пользователей невелико. Поэтому нагрузка внутри отдельной библиотеки редко создает проблемы. Однако таких библиотек может быть множество. Более важно уделять внимание планированию не поддержки отдельных экземпляров, а поддержки масштабирования таких библиотек.

Библиотека или большой список для совместной работы

Большой список для совместной работы может включать от сотен до тысяч элементов и служит в качестве хранилища для большого объема активного контента. Большие списки для совместной работы, как правило, включают решения для управления сведениями, технические библиотеки, а также репозитории вспомогательных материалов для продаж и маркетинга. Пользователи активно добавляют и изменяют контент (большое число операций чтения и записи). Для поддержания библиотеки в упорядоченном состоянии можно определить структуру и процедуры управления. Однако поскольку большая часть работы выполняется пользователями, могут происходить события, которые будут вне контроля администраторов. Поэтому высока вероятность того, что список будет расти быстрее, чем ожидалось, а его размер может превысить запланированные ограничения. Репозиторий такого типа может иметь сотни или тысячи пользователей, а число одновременных пользователей может составлять десятки или даже сотни.

По сравнению со структурированным репозиторием или архивом большой список для совместной работы более подвержен административным изменениям, таким как добавление и удаление папок, добавление типов контента и столбцов или реорганизация контента. Выполнение этих действий может оказаться невозможным в случае превышения порогового значения представления списка из-за размера списка.

Структурированный большой репозиторий

Структурированный большой репозиторий содержит от тысяч до сотен тысяч элементов. Контент, как правило, не подлежит изменению и отправляется пользователями или системными процессами, например рабочими процессами. Структурированные большие репозитории обычно используются в качестве архива учетных документов отделов, хранилища важных документов, а также окончательных документов, отображаемых на веб-страницах. Контент обычно структурирован и строго контролируется, что упрощает управление его размером. Число одновременных пользователей в этом сценарии может составлять десятки или сотни, а общий контингент пользователей достигать тысяч человек. Доля операций чтения значительно превышает долю операций записи. Однако в контент все же могут вноситься изменения, и он может часто добавляться и удаляться. Примером структурированного большого репозитория может служить репозиторий управления знаниями для подразделения или организации.

В данном сценарии необходимо хорошо понимать потребности пользователей и провести тщательное тестирование перед вводом решения в эксплуатацию. Поэтому перед наполнением решения большим объемом контента оно должно быть практически готово. Например, чтобы обеспечить должный уровень удобства при просмотре контента, необходимо настроить соответствующие иерархии и фильтры навигации для метаданных.

Крупномасштабный архив

Крупномасштабный архив содержит от тысяч до миллионов элементов, включенных в один список, распределенных по нескольким спискам или, в самых масштабных случаях, по нескольким семействам веб-сайтов. Для этого сценария характерно малое число операций чтения и изменения. Обычно он применяется только для долгосрочного хранения документов с целью соблюдения нормативных требований или в других целях (например, документов, которые должны храниться в течение семи лет в соответствии с законодательными требованиями). Для данного сценария требуется высокая скорость передачи и удаления документов. Поиск является основным способом извлечения контента.

Большие списки в SharePoint Server 2010

Возможности, облегчавшие работу с большими списками в Office SharePoint Server 2007, по-прежнему доступны в SharePoint Server 2010, а многие из них были улучшены с целью повышения производительности в масштабных сценариях. В SharePoint Server 2010 также появилось много новых возможностей, повышающих производительность больших списков и позволяющих пользователям эффективно работать с ними. В этом разделе приводятся сводные сведения о новых и улучшенных возможностях SharePoint Server 2010.

Улучшенные возможности

В следующих разделах рассматриваются возможности Microsoft Office SharePoint Server 2007, которые были улучшены в SharePoint Server 2010.

Веб-части "Запрос контента"

Веб-часть "Запрос контента" можно настроить на вывод результатов, отфильтрованных по спискам, типам контента и столбцам. Она допускает сортировку результатов и выбор отображаемых столбцов. Все это делает веб-часть "Запрос контента" идеальным средством для отображения контента большого списка на веб-страницах. Веб-части "Запрос контента" обычно кэшируются. Это обеспечивает более быструю загрузку страниц и снижение нагрузки на базу данных. Одним из вариантов применения веб-частей "Запрос контента" в сценариях управления знаниями является их использование на страницах публикации для отображения ссылок на документы, связанные с контентом веб-страницы.

SharePoint Server 2010 обеспечивает улучшения производительности в следующих основных сценариях:

• оптимизация запросов к отдельному списку для более эффективного использования индексов;

• улучшение алгоритмов недействительности и обновления, а также параметров по умолчанию с целью оптимизации использования кэша при выполнении пользователями операций записи.

Поиск

В SharePoint Server 2010 представлены новые возможности поиска, включая панель уточнения условий поиска и улучшенную масштабируемость, обеспечивающую величину задержки на уровне долей секунды при поиске по более чем 100 миллионам документов. Также можно использовать сервер Microsoft FAST Search Server 2010 for SharePoint, который обеспечивает более высокий уровень масштабирования по сравнению с системой поиска SharePoint Server 2010.

К некоторым из улучшений поиска, облегчающих поиск контента в больших списках, относятся поддержка логических операторов в произвольных текстовых запросах, улучшенная поддержка операторов, включая операторы "равно", "меньше" и "больше", уточнения диапазона и сопоставление префиксов в ключевых словах и свойствах. Например, запрос “share*” вернет в том числе результат “SharePoint”. Кроме того, при использовании поиска выводятся предложения запроса в зависимости от вводимого пользователем запроса. Пользовательский интерфейс поиска также улучшен: добавлены панели для связанных запросов поиска, лучших результатов поиска, связанных пользователей и уточнения ключевых слов.

В системе поиска SharePoint Server 2010 также улучшены возможности, связанные с масштабированием. Поиск в SharePoint Server 2010 поддерживает горизонтальное масштабирование серверов индекса, обхода контента и запросов. К другим улучшениям относятся новые индексы, повышенная отказоустойчивость и доступность. FAST Search Server 2010 для SharePoint включает все возможности поиска SharePoint Server 2010, к которым добавлены возможности экстремального масштабирования, извлечения сущностей, настраиваемого ранжирования по релевантности, отображения наиболее подходящих элементов, эскизов и представлений предварительного просмотра.

Шаблоны сайтов "Центр документов" и "Центр записей"

"Центр документов" и "Центр записей" — это шаблоны сайтов SharePoint Server 2010, с помощью которых можно создавать структурированные репозитории. Шаблон сайта "Центр документов" включает такие компоненты, как предварительно настроенные веб-части "Запрос контента", которые возвращают нужные результаты в зависимости от текущего вошедшего пользователя, и библиотека документов с настроенной навигацией для метаданных.

Шаблон сайта "Центр записей" похож на шаблон "Центр документов", однако в нем включен организатор контента для маршрутизации документов, и имеется библиотека записей. Добавляемые в нее элементы автоматически объявляются записями и не могут быть удалены. Шаблон сайта "Центр записей" — это единственный встроенный шаблон сайта, в котором не включено средство синтаксического анализа документов, что позволяет сохранять контент в точности в том виде, в котором он был отправлен. Отключение средства синтаксического анализа документов влияет на производительность некоторых операций, что делает данный шаблон сайта более подходящим для крупномасштабного хранилища документов (десятки миллионов элементов), чем другие.

Новые возможности

В этом разделе описываются новые возможности SharePoint Server 2010, облегчающие управление большими списками и повышающие их производительность.

Организатор контента

Организатор контента может использоваться на любом сайте для маршрутизации контента в определенные библиотеки документов, папки или даже на другие сайты. Организатор контента можно использовать для автоматического создания папок для контента в соответствии в соответствии со свойствами метаданных. Пользователи могут отправлять контент в организатор контента с других сайтов, не заботясь о соблюдении плана хранения документов. Организатор контента может служить для распределения контента по различным папкам с целью автоматического поддержания их размера ниже максимального значения. При достижении заданного максимального размера создается вложенная папка, в которую помещаются дополнительные элементы.

Навигация для метаданных

Навигация для метаданных — это новая функция SharePoint Server 2010, позволяющая пользователям динамически фильтровать списки, чтобы находить нужный контент. Навигация для метаданных дает пользователям возможность выбирать параметры фильтрации и обрабатывает запрос наиболее эффективным образом. Она состоит из двух компонентов. Первый компонент — это набор элементов навигации, позволяющих пользователю фильтровать список с иерархиями навигации и ключевыми фильтрами. Второй компонент — это механизм переупорядочения и повторного выполнения запросов.

В навигации для метаданных реализована логика повторных и резервных запросов, предназначенная для эффективного выполнения запросов с помощью индексов. Если число результатов запроса слишком велико, выполняется резервный запрос, возвращающий подмножество результатов с целью повышения производительности. Если невозможно выполнить нужный запрос, выполняется резервный запрос, при котором фильтры применяются к ограниченному набору результатов. Функция навигации для метаданных автоматически создает индексы. Повторные запросы, резервные запросы и управление индексами делают навигацию для метаданных очень значимой для эффективной работы с большими списками. Существует два механизма фильтрации: иерархии навигации и ключевые фильтры.

В иерархиях навигации используется элемент управления деревом для навигации по иерархиям папок, типов контента, полей выбора или наборов терминов управляемых метаданных. Это позволяет использовать элемент управления деревом для работы с иерархией метаданных аналогично навигации по папкам. Когда пользователи выбирают элемент иерархии для столбца управляемых данных, отображаются все элементы, соответствующие указанному термину или его потомкам. Это называется включением потомков. Оно может использоваться в полях, связанных с набором терминов управляемых метаданных. Пользователи могут повторно выбрать элемент для фильтрации по конкретному термину без учета его потомков. Все запросы навигации для метаданных являются рекурсивными и выводят результаты для всех папок в списке.

Ключевые фильтры служат для дополнительной фильтрации результатов в иерархии. Например, можно добавить в качестве ключевого фильтра столбец "Кем изменено", после чего ввести имя пользователя, чтобы получить результаты, для которых значение столбца "Кем изменено" соответствует введенному пользователю. Дополнительные сведения см. в статье Навигация по метаданным и их фильтрация (https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x419). На следующем рисунке показан пример иерархий навигации для метаданных и ключевых фильтров.

Управляемые метаданные

Управляемые метаданные — это новый набор функций, расширяющий возможности SharePoint Server, связанные с архитектурой данных. Возможности управляемых метаданных включают общую службу, называемую службой управляемых метаданных. Служба управляемых метаданных может использоваться для хранения наборов терминов, которые могут повторно использоваться в рамках всего развертывания SharePoint Server 2010. К некоторым из возможностей управляемых метаданных относятся следующие:

• наборы терминов, поддерживающие плоские и глубокие иерархии;

• тип столбца управляемых метаданных, в котором наборы терминов используются в качестве доступных свойств;

• наборы терминов, которые можно открыть для добавления в них новых терминов любыми пользователями или ограничить так, чтобы только определенные пользователи могли управлять набором терминов.

Применение столбцов управляемых метаданных и наборов данных для упорядочения контента позволяет использовать такие возможности, как веб-части "Запрос контента" и навигация для метаданных, для поиска контента пользователями. Управляемые метаданные также упрощают выполнение обычных поисковых запросов благодаря добавлению ключевых слов, которые могут использоваться для классификации документов. Управляемые метаданные могут использоваться на панели уточнения поиска. На следующем рисунке показан пример навигации по управляемым метаданным.

Регулирование и пределы

В SharePoint Server 2010 введено несколько настраиваемых ограничений для поддержания производительности фермы. На уровне веб-приложения теперь имеются настраиваемые регуляторы и ограничения. Они были добавлены для того, чтобы операции, выполняемые отдельными пользователями или процессами, не оказывали негативного влияния на производительность фермы. Например, пороговое значение представления списка — это ограничение, которое препятствует выполнению запросов, затрагивающих число элементов списка, превышающее заданное.

Составные индексы

Индексы важны для работы с большими списками. В SharePoint Server 2010 теперь можно создавать составные индексы. Составные индексы полезны в том случае, если запросы часто выполняются к двум столбцам по той причине, что запрос к одному столбцу может быть слишком обобщенным. Составные индексы не используются представлениями. Однако они используются навигацией по метаданным. При превышении ограничения логика навигации по метаданным может повторить попытку, используя применимые составные и одиночные индексы для выбранных условий фильтрации, чтобы найти полный или частичный набор результатов, удовлетворяющих запросу.

Панель разработчика

На панели разработчика отображаются подробные диагностические данные о загрузке каждой страницы. По умолчанию панель отключена. Однако ее можно включить вручную или настроить так, чтобы она оставалась включена постоянно. Когда панель разработчика включена, ее можно использовать для получения сведений о запросах к базе данных, времени загрузки и ошибках. Она упрощает быстрый анализ и диагностику проблем с производительностью. На следующем рисунке показана панель разработчика. Функция навигации по метаданным отображается на панели разработчика в случае больших списков и превышения ограничений. При этом список индексов, используемый для повторных запросов и вывода частичных результатов, отображается в дереве операций слева, а различные индексированные запросы SQL Server — в списке справа.

Панель разработчика также полезна для отладки настраиваемых веб-частей и запросов. Дополнительные сведения о включении панели разработчика см. в записи блога, посвященной включению панели разработчика с помощью объектной модели или Powershell (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x419).

Итератор контента

Интерфейс API разработчика "Итератор контента" упрощает написание кода для работы с большими списками и особенно полезен при использовании нового порогового значения представления списка. Итератор контента — это метод извлечения контента небольшими наборами для выполнения над ними операций вместо выполнения операций над всем набором данных. Это позволяет предотвратить превышение порогового значения представления списка при выполнении операций.

Удаленное хранилище больших двоичных объектов

По умолчанию SharePoint Server 2010 сохраняет данные файлов (больших двоичных объектов) в базах данных SQL Server. Значительный объем данных в базе данных контента обычно составляют данные больших двоичных объектов. Удаленное хранилище больших двоичных объектов (RBS) позволяет хранить такие данные вне SQL Server, сокращая тем самым стоимость решения хранения и размер базы данных контента. Удаленное хранилище больших двоичных объектов представляет собой набор API библиотеки, встроенный в качестве пакета дополнительных компонентов для SQL Server 2008. Для использования API удаленного хранилища больших двоичных объектов необходим сторонний поставщик удаленного хранилища больших двоичных объектов.

Методика измерения и тестирования производительности

В этом разделе описывается методика тестирования, использовавшаяся при проведении тестов, рассматриваемых в этой статье. Отклонения от этой методики указываются при представлении данных.

Конфигурация оборудования и фермы

Тестовая конфигурация фермы описывается на следующих рисунках и в таблицах. Следующие два аспекта тестовой конфигурации значительно отличаются от большинства реальных развертываний.

• Чтобы контроллер домена не являлся узким местом, использовалась проверка подлинности NTLM. Это привело к небольшому повышению производительности.

• На сервере приложений был размещен экземпляр SQL Server, использовавшийся в качестве базы данных журналов. Это было сделано с целью уменьшения нагрузки на основной экземпляр SQL Server, поскольку уровень ведения журнала был значительно выше, чем в реальных развертываниях.

Имя компьютера	Два веб-сервера	Один сервер приложений	Один сервер базы данных
Роль	Интерфейсный веб-сервер	Сервер приложений	Экземпляр SQL Server
Процессоры	2 четырехъядерный процессора с тактовой частотой 2,33 ГГц	2 четырехъядерных процессора с тактовой частотой 2,33 ГГц	4 двухъядерных процессора с тактовой частотой 3,19 ГГц
ОЗУ	8 ГБ	8 ГБ	32 ГБ
Операционная система	64-разрядная версия Windows Server 2008 R2	64-разрядная версия Windows Server 2008 R2	64-разрядная версия Windows Server 2008 R2
Хранилище и его геометрия (включая конфигурацию дисков SQL Server)	50 + 18 + 205 ГБ	50 + 18 + 300 ГБ	Дисковый массив: 15 дисков по 450 ГБ со скоростью вращения шпинделя 15 000 об/мин
Количество сетевых адаптеров	2	2	2
Скорость передачи данных сетевого адаптера	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-й процентиль задержки меньше одной секунды;

• загрузка ЦП на интерфейсном веб-сервере менее 50 %;

• загрузка ЦП на сервере SQL Server меньше 50 %;

• загрузка ЦП на сервере приложений меньше 50 %;

• процент сбоев меньше 0,01 %.

Определения тестов

В следующей таблице описывается сценарий тестирования и приводится обзор процедуры, использовавшейся для каждого теста.

Название теста	Описание теста
Отправка документа	Отправка документа. Изменение и обновление свойств документа.
Отправка и маршрутизация документа	Отправка документа. Изменение и обновление свойств документа. Маршрутизация документа в соответствии с правилом маршрутизации.
Загрузка документа	Загрузка документа.
Доступ к библиотеке документов	Доступ к странице с представлением списка библиотеки документов.
Доступ к домашней странице с веб-частями "Запрос контента"	Доступ к домашней странице сайта "Центр документов" с тремя веб-частями "Запрос контента". Кэшируемая веб-часть "Запрос контента" возвращает 15 документов с наиболее высоким рейтингом. Кэшируемая веб-часть "Запрос контента" возвращает 15 самых последних документов. Некэшированная веб-часть "Запрос контента" возвращает 15 последних элементов, измененных текущим пользователем.
Резервный запрос управляемых метаданных	Запрос представления списка, возвращающий более 5000 результатов и выполняющий фильтрацию по столбцу управляемых метаданных с одним значением.
Выборочный запрос управляемых метаданных	Запрос представления списка, возвращающий 1000 результатов и выполняющий фильтрацию по столбцу управляемых метаданных с одним значением.
Резервный запрос типа контента	Запрос представления списка, возвращающий более 5000 результатов и выполняющий фильтрацию по типу контента.
Выборочный запрос типа контента	Запрос представления списка, возвращающий 1000 результатов и выполняющий фильтрацию по типу контента.

Тестовый набор

Состав каждого тестового набора был особым. Тесты выполнялись с помощью Visual Studio Test System. Заполнялись определенные точки данных для каждого теста, после чего осуществлялся прогрев тестового набора в течение 2 минут и сбор данных в течение 10 минут. В данной статье приводятся усредненные результаты за 10 минут. В следующей таблице показана доля каждого решения в одном тестовом наборе.

Имя решения	Доля в наборе (%)
Отправка документа (включая изменение свойств документа)	20
Загрузка документа	20
Доступ к библиотеке документов	20
Доступ к домашней странице с веб-частями "Запрос контента"	10
Резервный запрос управляемых метаданных (более 5000 результатов)	5
Выборочный запрос управляемых метаданных (100 результатов)	10
Резервный запрос типа контента (более 5000 результатов)	5
Выборочный запрос управляемых метаданных (100 результатов)	10

Регулирование и пределы

Ограничения препятствуют выполнению операций, негативно сказывающихся на производительности фермы. Их значения по умолчанию были выбраны в результате тщательного тестирования. Настоятельно рекомендуется не изменять значения некоторых ограничений, например порогового значения представления списка. Тщательно оцените последствия изменения ограничений. Если ограничение блокирует выполнение операции, сначала попытайтесь повысить эффективность ее выполнения с помощью индексов вместо того, чтобы изменять ограничение для низкопроизводительной операции. Большинство регуляторов и ограничений, рассматриваемых в этом разделе, можно настроить в центре администрирования. Для этого необходимо перейти на страницу Управление веб-приложениями и выбрать на ленте элемент Общие параметры – Регулирование ресурсов для соответствующего веб-приложения.

Пороговое значение представления списка

SharePoint Server 2010 поддерживает списки и библиотеки документов, содержащие десятки миллионов элементов. Можно создавать очень большие библиотеки документов с помощью папок, стандартных представлений, иерархий сайтов и навигации по метаданным. Для извлечения данных из больших списков с помощью представлений списка или запросов CAML данные должны быть секционированы с использованием папок, индексов или обоих этих средств. В противном случае единственным эффективным механизмом доступа к данным является поиск. Максимальное число элементов, поддерживаемых одной библиотекой документов, может различаться в зависимости от способа упорядочения документов и папок, размера и типа хранимых документов, способа использования библиотеки документов и числа столбцов в ней.

Совет

В связи с появлением порогового значения представления списка может возникнуть вопрос, как оно связано с рекомендованным в Office SharePoint Server 2007 числом элементов в папке, равным 2000. Может показаться, что старое ограничение, равное 2000, заменено новым, равным 5000. Однако если для просмотра контента пользователи в первую очередь используют папки, то старое ограничение сохраняется. В то же время с появлением повторных и резервных запросов навигации по метаданным большие запросы могут возвращать подмножество результатов с целью оптимизации производительности. Это означает, что в папках можно размещать тысячи элементов и при этом производительность не будет падать, если запросы возвращают слишком много результатов.

По умолчанию пороговое значение представления списка блокирует выполнение операций, затрагивающих более 5000 элементов, например запросов, возвращающих более 5000 элементов, или операций добавления столбцов в список, содержащий более 5000 элементов. Хотя это ограничение можно изменить, настоятельно рекомендуется оставить значение по умолчанию. Если низкопроизводительные запросы применяются к спискам с более чем 5000 элементами, то при увеличении этого порогового значения общая пропускная способность может значительно снизиться.

Время и ресурсы, затрачиваемые на выполнение некоторых операций, таких как неиндексированные запросы или добавление столбца в список, пропорциональны числу элементов в списке. Для небольших списков это не имеет значения, поскольку элементов так мало, что операция выполняется быстро. Однако по мере увеличения размера списка эти операции выполняются все дольше и требуют все больше ресурсов. Для ограничения таких операций и используется пороговое значение представления ресурсов. Его можно уподобить ограждению вдоль шоссе. Оно позволяет определить, когда следует изменить запрос или способ доступа к данным либо перенести выполнение операции на периоды низкого использования фермы.

Пороговое значение представления списка — это максимальное число элементов списка или библиотеки, которое может обрабатываться операцией базы данных, например запросом, за один раз. По умолчанию оно равно 5000 элементов. Это ограничение непосредственно связано с большими списками, поскольку в соответствии с определением порогового значения большим списком является список, число элементов в котором превышает данное ограничение. Операции, которые превышают это ограничение, блокируются. Такие операции, как, например, создание индекса для списка, число элементов в котором превышает данное ограничение, блокируются, поскольку операция затрагивает более 5000 элементов. Это ограничение запрещает выполнение запросов с селективностью (числом элементов, которые могут быть успешно отфильтрованы с помощью критериев фильтрации) свыше 5000 элементов. Это ограничение также блокирует запросы, выполняющие фильтрацию по неиндексированным столбцам. Это связано с тем, что запрос, осуществляющий фильтрацию (а в некоторых случаях и сортировку) по неиндексированному столбцу, должен применить фильтр ко всем элементам списка, чтобы получить правильный набор данных. То есть действие будет выполняться с большим числом элементов, чем допускается в соответствии с пороговым значением представления списка. Значение по умолчанию для этого ограничения основано на производительности ферм и списков, а также способе управления блокировками в SQL Server. Изменять это значение не рекомендуется.

Чтобы свести к минимуму конфликты доступа к базе данных, в SQL Server используется блокировка на уровне строк с целью обеспечения правильного выполнения обновлений, в то время как пользователи могут без помех обращаться к другим строкам. Однако если операция чтения из базы данных или записи в нее, например запрос, приводит к одновременной блокировке 5000 строк, то более эффективным решением для SQL Server будет укрупнение блокировки и ее распространение на всю таблицу до тех пор, пока операция с базой данных не будет завершена. Если происходит укрупнение блокировки, другие пользователи утрачивают доступ к таблице. Дополнительные сведения о блокировках см. в статье Укрупнение блокировки (компонент Database Engine) (https://go.microsoft.com/fwlink/?linkid=219156&clcid=0x419).

На следующей диаграмме показана зависимость скорости выполнения набора запросов к большому списку от порогового значения представления списка. Данный набор запросов содержит запросы, возвращающие все элементы списка, поэтому по мере повышения порогового значения представления списка возвращается больше элементов. Даже изменение ограничения с 5000 (по умолчанию) до 10 000 ощутимо сказывается на производительности. Чтобы повысить производительность, рекомендуется не изменять пороговое значение представления списка по умолчанию, а уделить внимание оптимизации запросов.

Исключения порогового значения представления списка происходят из-за низкой производительности операций. Операции следует перенастроить. Вместо того чтобы повышать ограничение, следует попытаться установить причину неэффективности операций и устранить ее. В наихудшем сценарии можно временно изменить значение параметра EnableThrottling на false для определенного списка, чтобы пороговое значение представления списка игнорировалось. Это можно сделать только на уровне списка, но не уровне сайта. Отключать пороговое значение следует только до тех пор, пока не будут внесены изменения в блокируемые им низкопроизводительные операции. Необходимо как можно скорее изменить значение параметра EnableThrottling обратно на true.

Важно!

Исключения порогового значения представления списка могут происходить часто, особенно сразу после обновления. Изменение порогового значения представления списка может представляться наиболее простым способом устранения этих неполадок. Настоятельно рекомендуется не изменять это значение.

Пороговое значение представления списка не блокирует доступ для администраторов фермы и администраторов локального компьютера на интерфейсном веб-сервере, на котором был создан запрос. Эти пользователи должны соблюдать осторожность при работе с неправильно настроенными большими списками, а также при выполнении тестов. Может казаться, что все работает правильно, однако данные, возвращаемые пользователям, могут значительно отличаться. Список операций, блокируемых с помощью порогового значения представления списка, см. в разделе Операции, блокируемые с помощью порогового значения представления списка далее в этой статье.

Аналогичным образом, для запуска служб времени может использоваться учетная запись, на которую не распространяется пороговое значение представления списка. Хотя это обеспечивает ряд возможностей, например отложенное создание индекса для большого списка, в общем случае следует тщательно избегать выполнения операций с большими списками в коде.

Пороговое значение представления списка

По умолчанию: 5000	Существовало в версии 2007: нет	Возможность настройки: да
Место настройки: центр администрирования, для каждого веб-приложения

Пороговое значение представления списка для аудиторов и администраторов

По умолчанию: 20 000	Существовало в версии 2007: нет	Возможность настройки: да
Место настройки: центр администрирования, для каждого веб-приложения

Пороговое значение представления списка для аудиторов и администраторов — это пороговое значение, используемое для некоторых учетных записей служб, таких как учетная запись службы поисковых запросов или учетные записи суперпользователя и суперчитателя кэша объектов. Например, веб-часть "Запрос контента" автоматически использует это ограничение для кэширования результатов большого запроса, экономя таким образом ресурсы сервера. При использовании учетной записи суперчитателя или суперпользователя в соответствии с политикой безопасности веб-приложения можно запросить повышение порогового значения с помощью настраиваемого кода.

Разрешить переопределение объектной модели

По умолчанию: да	Существовало в версии 2007: нет	Возможность настройки: да
Место настройки: центр администрирования, для каждого веб-приложения

Если разрешить переопределение объектной модели, учетные записи служб смогут использовать пороговое значение представления списка для аудиторов и администраторов. Администратор фермы должен включить переопределение объектной модели и программным путем указать, что список является исключением. После этого программисты с соответствующим разрешением могут программно запросить использование для запроса или списка более высокого порогового значения представления списка для аудиторов и администраторов. Если изменить значение на "Нет", к настраиваемому коду, выполняемому аудиторами или администраторами, будет применяться стандартное пороговое значение представления списка, а не пороговое значение для аудиторов и администраторов, даже если в коде запрашивается переопределение. Рекомендуется оставлять для этого параметра значение по умолчанию и при необходимости настраивать только пороговое значение представления списка для аудиторов и администраторов.

Ежедневный временной интервал

По умолчанию: выключено	Существовало в версии 2007: нет	Возможность настройки: да
Место настройки: центр администрирования, для каждого веб-приложения

Можно задать ежедневный временной интервал, в течение которого пороговое значение представления списка не будет применяться к выполняемым операциям. Можно настроить интервал длительностью до 24 часов с шагом в 15 минут. Операция базы данных или запрос, запущенный в течение ежедневного временного интервала, будет выполняться вплоть до завершения, даже если заданный интервал истек. По умолчанию ежедневный временной интервал не настроен, поскольку период пониженной нагрузки может значительно различаться в разных развертываниях. Поэтому он задается администратором. Ежедневный временной интервал рекомендуется настраивать только в том случае, если имеется достаточно длительный период пониженной нагрузки, в течение которого веб-приложение используется малым числом пользователей. Он позволяет пользователям выполнять административные операции с большими списками, например создавать индексы, в те периоды, когда интенсивность использования фермы значительно ниже.

Уникальные разрешения

По мере увеличения числа уникальных разрешений в списке производительность снижается. Следует пересмотреть проектные решения, если большая часть контента в большом списке или весь такой контент требует уникальной защиты. Разница в пропускной способности для операций со списком без уникальных разрешений и со списком с 1000 уникальных разрешений составляет приблизительно 20 %. По умолчанию максимальное число уникальных разрешений на список составляет 50 000, однако это ограничение является настраиваемым. Рекомендуется снизить его до 5000 уникальных разрешений, а для больших списков следует использовать как можно меньше уникальных разрешений. Это позволит повысить не только производительность, но и управляемость.

Рекомендуется выполнить следующие действия.

• Сведите к минимуму использование уникальных разрешений для отдельных элементов и упростите структуру списков, в которых для большинства элементов требуются уникальные разрешения.

• Если уникальные разрешения необходимы, пытайтесь задавать их только на уровне списка или папок, сведя к минимуму число отдельных элементов, требующих уникальных разрешений.

• Пересмотрите структуру списка, если каждый элемент требует отдельного разрешения. Рассмотрите возможность разделения элементов на несколько списков или их упорядочения по папкам и группам, чтобы предоставлять права доступа, не задавая уникальные разрешения для каждого элемента.

Детальная настройка разрешений может сказываться на производительности. Кроме того, она создает трудности с управлением, если для множества отдельных элементов разрешения настраиваются по-разному. Задание детальных разрешений для списков или папок, число элементов в которых превышает пороговое значение представления списка, блокируется, поскольку требует обновления слишком большого числа элементов. Однако настройка детальных разрешений также влияет на производительность и иными путями. Поэтому существует настраиваемое ограничение, которое по умолчанию составляет 50 000 уникальных разрешений на список. Попытки объявить уникальные разрешения после достижения этого предела блокируются. В отличие от порогового значения представления списка данное ограничение применяется при создании уникальных разрешений для элемента, а не при выполнении запроса.

При отмене наследования разрешений для элементов, например папок, их разрешения учитываются как уникальные. При каждой отмене наследования разрешений создается идентификатор области. Каждый раз при запросе к представлению выполняется подключение к таблице областей. Затем в процессе выполнения запроса каждый уникальный список управления доступом (ACL) должен быть проанализирован и обработан. Использование большого числа уникальных разрешений в списке негативно скажется на производительности и не рекомендуется. По мере увеличения числа уникальных разрешений в списке производительность запросов снижается. Хотя по умолчанию ограничение установлено на уровне 50 000 уникальных разрешений, возможно, его следует снизить до 5000 разрешений.

Уникальные разрешения

По умолчанию: 50 000	Существовало в версии 2007: нет	Возможность настройки: да
Место настройки: центр администрирования, для каждого веб-приложения

Перенос по строкам

При добавлении столбцов в список они сопоставляются со столбцами в таблице базы данных SQL Server. Каждая строка в таблице базы данных поддерживает фиксированное количество столбцов каждого из нескольких различных типов. Например, отдельная строка таблицы базы данных поддерживает восемь столбцов даты и времени и двенадцать числовых столбцов. Если число столбцов даты и времени превышает восемь, для каждого элемента списка будут использоваться две строки таблицы базы данных.

В случае с небольшими списками влиянием переноса по строкам на производительность можно пренебречь. Однако в случае с большими списками это влияние может быть значительным. Перенос по строкам производится при превышении допустимого числа столбцов хотя бы для одного типа столбцов.

В следующей таблице показано максимальное число столбцов для определенных типов данных, при превышении которого производится перенос по строкам.

Тип столбца	Число столбцов в строке таблицы
Однострочный текст либо Выбор или многострочный текст	64 32
Дата и время	8
Да или нет	16
Числовой или денежный	12
Вычисляемый	8
Целочисленный, подстановка с одним значением, пользователь и группа, управляемые метаданные	16
Уникальный идентификатор	1

Для большинства операций перенос по строкам приводит к снижению пропускной способности приблизительно на 35 % за каждую дополнительную строку. Чтобы проверить, сколько строк используется в списке, необходимо проанализировать схему списка и изучить типы столбцов.

На следующей диаграмме показана зависимость производительности запросов чтения от числа строк в базе данных SQL Server, увеличивающегося при добавлении столбцов управляемых метаданных. Для переноса на вторую строку в список было добавлено 15 столбцов управляемых метаданных, а для переноса на третью строку — 31 столбец. При тестировании использовались только запросы, выполняющие фильтрацию по элементам списка. При добавлении каждой строки пропускная способность снижается на 35 %.

Ограничение на размер строки

По умолчанию: 6	Существовало в версии 2007: нет	Возможность настройки: да
Место настройки: только объектная модель, SPWebApplication.MaxListItemRowStorage

Ограничение на размер строки определяет максимальное число внутренних строк таблицы в базе данных, которые могут использоваться для каждого элемента списка. При работе с большими списками, содержащими множество столбцов, каждый элемент разбивается на несколько внутренних строк таблицы (до шести строк). Например, если список содержит сотни столбцов типа "Да/Нет", данное ограничение может быть достигнуто. В таком случае добавить столбцы типа "Да/Нет" в список будет невозможно. Однако в него можно добавлять столбцы других типов. Поскольку каждая дополнительная строка создает накладные расходы, в больших списках следует сводить к минимуму число столбцов одного типа во избежание переноса по строкам.

Столбцы подстановки и представления списка

Каждый столбец подстановки в представлении списка приводит к созданию соединения с другой таблицей. Каждый дополнительный столбец подстановки в представлении повышает сложность навигации по метаданным и запросов представления списка. Наряду со стандартными столбцами подстановки, за столбцы подстановки принимаются столбцы управляемых метаданных с одним значением, столбцы управляемых метаданных с несколькими значениями, столбцы пользователей и групп с одним значением и столбцы пользователей и групп с несколькими значениями. По мере добавления столбцов подстановки в представление производительность падает не постепенно (линейно). Она остается достаточно стабильной при добавлении первых восьми столбцов, после чего начинает резко снижаться.

На следующей диаграмме показано, как изменяется пропускная способность при увеличении числа столбцов подстановки в представлении. Как можно видеть, изменения производительности в диапазоне от 0 до 8 столбцов почти не происходит, но при 10 столбцах подстановки пропускная способность значительно снижается. При проведении этого теста использовалась только одна строка списка. Если в списке используется перенос по строкам, производительность падает быстрее.

На следующей диаграмме показано, как изменяется загрузка ЦП на сервере SQL Server при увеличении числа столбцов подстановки в представлении. Как можно видеть, ощутимое изменение происходит при увеличении числа столбцов подстановки до 10. Для списка с большим числом запросов использование представлений, содержащих более восьми столбцов подстановки, приводит к потреблению несоразмерно большого количества ресурсов SQL Server. Рекомендуется не повышать данное ограничение сверх восьми столбцов.

Хотя это снижение производительности связано не с общим числом столбцов подстановки в списке, а только с их числом в представлении или запросе, SharePoint Workspace не может синхронизировать списки, содержащие более восьми столбцов подстановки. Это не зависит от того, используются ли эти столбцы в представлении или нет.

Пороговое значение подстановки представления списка

По умолчанию: 8	Существовало в версии 2007: нет	Возможность настройки: да
Место настройки: центр администрирования, для каждого веб-приложения

Прочие ограничения

В этом разделе описываются ограничения, которые не рассматриваются в других разделах данной статьи.

Число индексов в списке

По умолчанию: 20

Существовало в версии 2007: да, ограничение было равно 10

Возможность настройки: нет

В таблице выше указано максимальное число индексов, которые могут быть созданы для списка, включая составные индексы и индексы, создаваемые SharePoint Server 2010. Изменить это ограничение невозможно.

Таблица данных и экспорт в Excel

По умолчанию: 50 000

Существовало в версии 2007: нет

Возможность настройки: нет

В таблице выше указано максимальное число элементов, которые могут быть экспортированы в Microsoft Excel и таблицу данных. Однако таблица данных будет блокироваться при превышении порогового значения представления списка. Поэтому, если пороговое значение представления списка равно 5000 элементам, а в представлении списка имеется от 5000 до 50 000 элементов, то при попытке использования таблицы данных появится сообщение об исключении представления списка несмотря на то, что ограничение таблицы данных не превышено.

SharePoint Workspace

По умолчанию: 30 000 элементов на список

Существовало в версии 2007: нет

Возможность настройки: нет

В Microsoft SharePoint Workspace имеется ненастраиваемое ограничение, блокирующее синхронизацию списков, содержащих более 30 000 элементов. Если список содержит 30 000 элементов, пользователи не могут синхронизировать его с помощью SharePoint Workspace или синхронизировать элементы выборочно.

Различия между большими и обычными списками

Если число элементов в списке превышает пороговое значение представления списка, некоторые операции, которые ранее могли выполняться нормально, блокируются. Особое внимание следует обратить на представление списка по умолчанию, поскольку именно его чаще всего используют пользователи для доступа к списку. Чтобы представления списка правильно работали для большого списка, их необходимо настроить. Например, при доступе к списку, корень которого содержит число элементов, превышающее пороговое значение представления списка, происходит ошибка. Если включена функция навигации по метаданным, вместо ошибки выводится подмножество результатов.

Пороговое значение представления списка блокирует любые операции в базе данных, которые затрагивают число элементов, превышающее заданное ограничение, а не только операции, возвращающие или изменяющие такое число элементов. Например, если имеется фильтр, применяемый к неиндексированному столбцу, который возвращает 100 результатов, а список содержит 10 000 элементов, выполнить запрос не удастся, поскольку он должен просканировать все 10 000 элементов. Если добавить индекс для этого столбца, операция будет ограничена только 100 элементами и будет выполнена успешно.

Операции с большими списками можно разделить на следующие две группы.

• Размер списка превышает пороговое значение представления списка.   Некоторые операции блокируются, если размер всего списка превышает пороговое значение представления списка, даже если элементы разбиты на папки. К таким операциям относятся рекурсивные запросы, например запросы управления извлеченными версиями, которые применяются ко всем элементам вне зависимости от того, в какой папке они находятся. Представления, возвращающие все элементы без папок, также блокируются. Кроме того, блокируются операции, затрагивающие весь список, такие как добавление столбца или создание и удаление индексов.

• Размер контейнера превышает пороговое значение представления списка.   Некоторые операции блокируются, если папка или корень списка содержат число элементов, превышающее пороговое значение представления списка. Например, если список содержит 10 000 элементов, а папка — 3000 элементов, папку можно переименовать или удалить. Однако если папка содержит 6000 элементов (пороговое значение представления списка превышено), удалить папку нельзя.

Если число элементов в списке превышает пороговое значение представления списка, необходимо правильно настроить представления и другие параметры навигации. В идеале их следует настраивать заранее, однако часто списки разрастаются сверх порогового значения представления списка позднее, что требует принятия мер. Некоторые операции, например создание или индексация столбца в списке с большим числом элементов, занимают много времени. Такие операции блокируются с помощью порогового значения представления списка. Однако они все же могут выполняться администраторами фермы или компьютера или в течение ежедневного временного интервала. Перед выполнением таких операций их необходимо спланировать. Если список уже слишком велик, запланируйте их выполнение в течение ежедневного временного интервала или используйте учетные данные администратора.

Совет

Пороговое значение представления списка блокирует некоторые административные действия со списками, которые обычно выполняются при их настройке. По возможности следует настраивать все типы данных, столбцы и индексы для списка до того, как его размер превысит пороговое значение представления списка.

Список может стать настолько большим, что при выполнении некоторых операций с помощью веб-браузера может истекать время ожидания. Например, если список содержит миллионы документов, на добавление столбца может потребоваться слишком много времени. Для выполнения таких операций необходимо использовать Windows PowerShell. Делать это следует в периоды пониженной нагрузки, поскольку операции других пользователей будут заблокированы.

Операции, блокируемые с помощью порогового значения представления списка

В следующих таблицах перечислены операции, блокируемые при превышении порогового значения представления списка.

Операции, блокируемые при превышении списком порогового значения представления списка

Операция	Описание
Добавление, удаление или изменение столбца списка	Все столбцы, включая столбцы подстановки и вычисляемые столбцы, а также многие типы операций изменения, такие как изменение типа или уникальности. Некоторые изменения, например изменение имени, не блокируются, поскольку они не затрагивают все элементы списка.
Добавление, удаление или изменение типа контента в списке	Применяется ко всем элементам списка; поэтому для списков, число элементов которых превышает пороговое значение представления списка, эта операция блокируется.
Создание или удаление индекса	Применяется ко всем элементам списка; поэтому для списков, число элементов которых превышает пороговое значение представления списка, эта операция блокируется.
Управление файлами, не имеющими возвращенной версии	Неиндексированный рекурсивный запрос, который завершается сбоем для любого списка, число элементов в котором превышает пороговое значение представления списка.
Неиндексированные рекурсивные запросы	Включают фильтры и некоторые операции сортировки. Эта операция завершается сбоем, если размер списка превышает пороговое значение представления списка. Поскольку индекс отсутствует, производится полное сканирование всего списка. Эта операция возвращает все элементы и игнорирует папки.
Запрос к спискам	Включает запросы от веб-части "Запрос контента". Применяется пороговое значение представления списка для аудиторов и администраторов, по умолчанию равное 20 000 элементам. Если операция затрагивает более 20 000 элементов, выполнить запрос не удается.
Столбцы подстановки, обеспечивающие поведение отношения	Нельзя создавать столбцы подстановки, обеспечивающие поведение отношения, если указанный список содержит число элементов, превышающее пороговое значение представления списка.
Удаление списка	Применяется ко всем элементам списка; поэтому для списков, число элементов которых превышает пороговое значение представления списка, эта операция блокируется.
Удаление сайта	Если сумма всех элементов на сайте превышает пороговое значение представления списка, удаление сайта запрещено, поскольку оно затрагивает слишком много элементов.
Сохранение списка как шаблона с данными	Применяется ко всем элементам списка; поэтому для списков, число элементов которых превышает пороговое значение представления списка, эта операция блокируется.
Отображение итогов в представлениях списка	Запрос выполняется ко всем элементам списка; поэтому для списков, число элементов которых превышает пороговое значение представления списка, эта операция блокируется.
Включение и отключение вложений в списке	Применяется ко всем элементам списка; поэтому для списков, число элементов которых превышает пороговое значение представления списка, эта операция блокируется.

Операции, блокируемые при превышении контейнером порогового значения представления списка

Операция	Описание
Удаление, копирование или переименование папки	Завершается сбоем, если число элементов в папке превышает пороговое значение представления списка, поскольку затрагивается слишком много строк.
Запросы, выполняющие фильтрацию по неиндексированным столбцам	Завершается сбоем, если число элементов в контейнере (папке или списке) превышает пороговое значение представления списка. Операция выполняет полное сканирование всей папки, поскольку индекс отсутствует.
Настройка детальных разрешений безопасности	Завершается сбоем, если число элементов в списке или папке, для которой задаются детальные разрешения, превышает пороговое значение представления списка, поскольку затрагивается слишком много строк. Хотя задать разрешения для таких списков или папок нельзя, можно задать детальные разрешения для дочерних элементов большого списка, например документов.
Открыть в проводнике	Если число элементов в контейнере (исключая элементы во вложенных папках) превышает пороговое значение представления списка, элементы не отображаются. Если папка содержит 8000 элементов, из которых 4000 находятся во вложенной папке и только 4000 — в корневой, функция "Открыть в проводнике" будет работать. Если число элементов в корневой папке списка превышает пороговое значение представления списка, то при использовании функции "Открыть в проводнике" ничего не отобразится. Для использования функции "Открыть в проводнике" элементы списка должны быть упорядочены по папкам так, чтобы число элементов в корне любого контейнера не превышало пороговое значение представления списка.

Доступные функции, которые могут работать неправильно

Этот раздел содержит сведения о функциях, которые могут работать неправильно применительно к большим спискам.

Таблица данных

Кнопка "Таблица данных", доступная на вкладке ленты "Библиотека" для библиотеки документов, не отключается, если размер списка превышает пороговое значение представления списка. В этом случае в представление загружаются некоторые элементы, однако выводится следующее сообщение: “У вас нет разрешений на просмотр полного списка, поскольку его размер превышает пороговое значение представления списка, принудительно установленное администратором”. Отключить кнопку "Таблица данных" на ленте можно в параметрах списка. Существует также жесткое ограничение в 50 000 элементов, поэтому это представление блокируется, даже если пороговое значение представления списка превышает 50 000 элементов.

Проектирование и реализация больших списков

Перед реализацией большого списка необходимо изучить бизнес-задачу и требования. Следует учесть такие требования, как соглашение об уровне обслуживания, время, необходимое для резервного копирования и восстановления, размер контента, его объем (число элементов) и время доступа. Исходя из размера приложения и его востребованности, необходимо принять важные решения касательно оборудования, хранилища контента и архитектуры данных SharePoint Server 2010. Крупное приложение с миллионами элементов и сотнями одновременных пользователей может потребовать отдельного оборудования для определенного проекта, в то время как репозиторий документов с десятками одновременных пользователей и десятками тысяч документов может отлично работать на существующем совместно используемом оборудовании с единственной библиотекой документов на существующем сайте.

В результате планирования должен быть выработан список типов столбцов (с именами, типами данных и назначением) и индексов, определена структура папок, интенсивность использования страниц и ссылок для навигации, структура разрешений, приблизительное число элементов и общий размер данных. Также необходимо включить сведения о типах запросов, которые будут выполняться, а также способах доступа к данным в списке, их создания и изменения.

Спланировав структуру и реализацию большого списка, необходимо спроектировать и построить прототип. На этом этапе планирования осуществляется проектирование большого списка и его экспериментальная реализация для проверки работоспособности. На этом этапе может быть полезным наполнить тестовую среду большим объемом контента, чтобы проверить допущения в отношении доступа к данным и производительности. В результате процесса проектирования должна быть выполнена экспериментальная реализация требуемого списка, а также задокументированы столбцы, типы контента, структура папок, представления, индексы, столбцы, используемые для навигации по метаданным и другие методы извлечения данных, используемые таксономии, способы использования различных веб-частей, а также других возможностей, например организатора контента.

Оценка размера контента

Для принятия решений в процессе планирования емкости и проектирования больших списков необходимо оценить различные показатели. Существует ряд важных для планирования показателей, включая следующие:

• общий размер базы данных контента;

• средний и максимальный размеры файлов;

• число версий;

• объем контента, то есть общее число элементов в списке.

Размер базы данных контента

Общий размер базы данных контента важен для планирования требуемого дискового пространства и оборудования, а также выяснения возможностей поддержки резервного копирования, восстановления и соглашения об уровне обслуживания. Общий размер базы данных контента является наиболее важным фактором при расчете времени простоя, необходимого для резервного копирования и восстановления.

Размер базы данных можно оценить, умножив средний размер документа на среднее число версий каждого документа и на планируемое число документов. После этого следует добавить еще 20 процентов, чтобы учесть дополнительные данные в базе данных контента помимо данных файлов. Это значение достаточно высоко, поскольку со временем размер версий обычно увеличивается, поэтому средний размер файлов возвращенных документов как правило превышает средний размер файлов всех версий. Также следует зарезервировать буфер достаточного объема на тот случай, если размер списка превысит ожидаемый. Однако если реализованы эффективные механизмы для контроля объема контента, делать это не нужно.

Средний и максимальный размеры файлов

Максимальный размер файла необходим для того, чтобы правильно настроить параметр веб-приложения, определяющий максимальный размер отправляемых файлов (значение по умолчанию равно 50 МБ; максимальное возможное значение — 2 ГБ). Средний размер файлов позволяет оценить общий размер контента и скорость, с которой он может расти. Средний размер файлов можно оценить на основе файлов в системах, которые в настоящее время выполняют роль планируемой системы.

Совет

Необходимо учитывать, что размер базы данных контента увеличится на 10–20 процентов за счет данных помимо данных файлов и что индекс поиска будет составлять приблизительно 75 % размера базы данных контента.

Среднее число версий

Необходимо продумать управление версиями, поскольку оно может значительно увеличить размер контента. Существуют методы для ограничения числа версий. Например, используя политики хранения управления сведениями, можно удалять все предыдущие версии после определенного периода времени или ограничить число сохраняемых версий. На число версий влияют и другие факторы. Например, если весь контент передается в репозиторий с помощью организатора контента, версии могут отсутствовать, поскольку организатор контента копирует только последнюю возвращенную версию. Если пользователи активно редактируют документы в репозитории, возможно, следует использовать совместное редактирование. Каждый сеанс совместного редактирования автоматически создает версию. Продумайте использование репозитория и проанализируйте существующие решения, чтобы оценить среднее число версий, создаваемых для документа.

Объем контента

Объем контента — это общее число элементов в списке. Чтобы оценить объем контента, следует проанализировать текущие источники контента и определить, какие из них будут перенесены в новую систему, либо определить число пользователей системы и ее назначение. Имеются и другие связанные показатели, включая число элементов на каждый контейнер и число элементов на сводку метаданных или фильтр индекса. Эти показатели также важны при планировании представлений и навигации по метаданным.

Удаленное хранилище больших двоичных объектов

Если списки предъявляют значительные требования к хранилищу, необходимо принять фундаментальное решение относительно способа хранения документов. По умолчанию SharePoint Server 2010 сохраняет все документы в виде больших двоичных объектов в базе данных SQL Server. SharePoint Server 2010 и SQL Server 2008 предоставляют интерфейс API удаленного хранилища больших двоичных объектов, который позволяет хранить документы вне базы данных SQL Server, что сокращает ее размер. Решение об использовании удаленного хранилища больших двоичных объектов обуславливается в первую очередь экономичностью такого решения.

Тестирование, проведенное корпорацией Майкрософт, показало, что удаленное хранилище больших двоичных объектов приводит к снижению пропускной способности на 5–10 %. Увеличения времени задержки в случае с большими файлами выявлено не было. Однако производительность может различаться в зависимости от используемого поставщика удаленного хранилища больших двоичных объектов. При использовании удаленного хранилища больших двоичных объектов сокращается размер базы данных контента. Однако это не обязательно означает, что в ней можно хранить больше объектов. На производительность влияет число элементов в списках в базе данных SQL Server; хотя большие двоичные объекты переносятся из базы данных, размер списка не изменяется. Существует ряд сценариев, в которых экономия затрат может легко перевесить проблемы с производительностью:

• архивные данные, не предназначенные для совместного использования;

• хранение очень больших двоичных объектов, например видео и изображений, которые редко обновляются.

Использование удаленного хранилища больших двоичных объектов может увеличить число серверов и технологий в ферме и требует добавления поставщика удаленного хранилища больших двоичных объектов. Поставщик удаленного хранилища больших двоичных объектов может обеспечить хранение больших двоичных объектов в более экономичном хранилище вне базы данных SQL Server. Для использования API удаленного хранилища больших двоичных объектов требуется SQL Server Enterprise.

Порог, при достижении которого использование удаленного хранилища больших двоичных объектов становится экономически оправданным, может находиться в диапазоне терабайтов данных. Однако это не означает, что если размер баз данных контента исчисляется терабайтами, использование удаленного хранилища больших двоичных объектов является обязательным. Необходимо тщательно проанализировать процедуры резервного копирования и восстановления, а также соглашения об уровне обслуживания. Удаленное хранилище больших двоичных объектов усложняет аварийное восстановление, поскольку требует синхронизации двух технологий. Ключевой проблемой является время, требуемое для восстановления системы после аварийного сбоя и для выполнения резервного копирования и восстановления больших двоичных объектов. Дополнительные сведения см. в статье Overview of RBS (SharePoint Server 2010).

Архитектура списка

Правильный выбор архитектуры для большого списка очень важен, поскольку изменение проектных решений после их реализации может представлять сложность. Заблаговременно спланируйте размер и объем контента, использование репозитория, способы добавления и изменения контента, а также доступа к нему. Все эти факторы могут повлиять на организацию контента (один список, несколько списков или даже несколько семейств веб-сайтов), используемые метаданные и способы извлечения контента. Данные решения особенно важны в случае с большим списком, поскольку при большом объеме контента становится значительно труднее перепроектировать систему.

Один список, несколько списков или несколько семейств веб-сайтов

При проектировании большого списка необходимо решить, является ли приемлемой архитектура с одним списком. Решение разместить контент в одном списке должно быть согласовано с бизнес-требованиями, такими как удобство работы и поиска контента. Во многих случаях более целесообразным может оказаться использование нескольких списков. Главным приоритетом должно быть создание успешной реализации, обеспечивающей удобство работы пользователей, а также предоставляющей необходимые возможности SharePoint Server 2010 и доступные ресурсы.

Использование одного списка облегчает пользователям поиск контента и работу с ним, поскольку им не приходится решать, куда следует поместить контент или в каком списке нужно искать требуемый контент. Однако по мере увеличения объема контента поиск контента может усложняться, особенно при использовании таких методов, как фильтрация представлений или навигация по папкам. Когда размер списка начинает достигать сотен тысяч элементов, использование навигации по метаданным может стать сложным. Запросы могут возвращать сотни тысяч результатов, если они недостаточно конкретизированы.

Например, если в домене индекса имеется 5000 терминов и каждый термин имеет одинаковое число элементов, соответствующих фильтру, фильтрация по одному термину даст 20 результатов со списком из 100 000 элементов и 200 результатов со списком из 1 000 000 элементов. Если размер списка слишком велик, при выборе многих фильтров пользователи будут получать наборы результатов, в которых найти нужный контент будет невозможно. Если проект предусматривает несколько типов контента, которые явно различаются для пользователей, следует рассмотреть возможность использования нескольких списков.

При очень высоком уровне масштабирования, например в случае с крупномасштабными архивами, может быть целесообразным использовать архитектуру с несколькими семействами сайтов. В SharePoint Server 2010 появилась новая возможность, позволяющая группировать несколько семейств веб-сайтов с целью балансировки нагрузки, связанной с документами. Организатор контента служит для маршрутизации документов между несколькими семействами веб-сайтов. Для извлечения документов необходимо использовать функцию поиска. Это оптимальный вариант для долгосрочного хранения, поскольку он обеспечивает распределение контента между несколькими семействами веб-сайтов и допускает хранение гораздо большего числа документов, чем один список.

Сводка рекомендаций по использованию списков

• Используйте отдельные списки для хранения большого числа элементов в следующих случаях.

  • Размещение элементов в нескольких списках является нецелесообразным.

  • Это обеспечит максимальное удобство работы пользователей.

• Используйте несколько списков для хранения большого числа элементов в следующих случаях.

  • Разделение элементов на несколько списков является логически обоснованным.

  • Это обеспечит максимальное удобство работы пользователей.

  • У пользователей не будет возникать затруднений при выборе списка для добавления или поиска контента.

• Используйте архитектуру с несколькими семействами веб-сайтов в следующих случаях.

  • Репозиторий должен поддерживать хранение более десятков миллионов элементов.

  • Разделение элементов на несколько семейств веб-сайтов является логически обоснованным, например для группировки данных по годам.

Метаданные

В SharePoint Server 2010 метаданные и типы контента могут использоваться для создания архитектуры данных. Такие новые возможности, как управляемые метаданные, наборы терминов и навигация по метаданным, делают метаданные важным средством для извлечения контента. Поскольку такие операции, как изменение типов контента и столбцов, блокируются для больших списков, важно планировать требования к метаданным заблаговременно. Если будет использоваться навигация по метаданным или другие методы извлечения контента с помощью метаданных, на этапе проектирования необходимо спланировать типы контента и соответствующие им столбцы.

В большинстве сценариев использования списков метаданные не только полезны, но и являются обязательным требованием для обеспечения возможности использования системы пользователями. Существует три основных способа применения метаданных: встроенные системные процессы, настраиваемые конфигурации и код, а также применение пользователями вручную. Для использования столбцов с целью извлечения контента большинству элементов необходимо присвоить значение, указывающее на столбец. Поэтому важно решить, какие столбцы будут использоваться для навигации и как будут заполняться метаданные. Единственным способом гарантировать применение правильных метаданных является использование встроенных процессов и настроек. Например, каждый элемент относится к определенному типу контента. Поэтому если типы контента используются для классификации документов, каждый элемент будет обладать эти метаданные, что упростит фильтрацию по типу контента.

Типы контента

На самом базовом уровне категоризация контента должна осуществляться с помощью типов контента. Если для классификации контента используются метаданные, например тип документа или элемента, возможно, следует перенести эту классификацию на типы контента. Типы контента можно связывать с определенными столбцами, а также с рабочими процессами и шаблоном. С типом контента можно связать только один шаблон, а именно шаблон, используемый при создании экземпляра типа контента с помощью меню Создание документа в библиотеке документов.

Можно использовать шаблоны для форматов файлов, используемых в Microsoft Word, Microsoft PowerPoint и Excel, а также других продуктах. Когда пользователь создает экземпляр типа контента, то для его создания на основе шаблона используется соответствующее клиентское приложение. При отправке контента пользователь может выбрать один из доступных типов контента. Каждый список должен иметь минимальный достаточный набор типов контента, отличных друг от друга, чтобы у пользователей не возникало проблем с их выбором.

Поскольку от типов контента зависят метаданные, которые пользователи должны заполнять при создании или отправке элемента, продумайте, какие столбцы необходимы для выполнения бизнес-требований, и сведите к минимуму действия, необходимые для отправки контента. Правильный выбор набора типов контента для классификации контента на базовом уровне автоматически облегчает навигацию. Поскольку каждый элемент относится к определенному типу данных, существует единый признак, по которому может выполняться фильтрация для любого элемента.

Сводка рекомендаций по использованию типов контента

• Используйте типы контента в качестве самого базового метода упорядочения контента.

• Выберите определенные столбцы, которым необходимо назначить данный тип контента.

• Число типов контента в каждом списке должно быть небольшим (не более 10), и они должны четко различаться, чтобы у пользователей не возникало трудностей с выбором нужного типа контента.

• Для типа контента предусмотрен встроенный столбец, в котором у каждого элемента должно быть значение. Это значение может использоваться для фильтрации и навигации по метаданным.

Пример большого списка для совместной работы и типов контента: библиотека спецификаций продуктов

Библиотека спецификаций продуктов используется рабочими группами по разработке продуктов для хранения проектных спецификаций, планов тестирования и других документов, связанных с разработкой продуктов. В данном примере используются следующие шесть типов контента. Каждый тип контента предусматривает столбцы для даты начала проекта, даты окончания проекта, бюджета, состава проектной группы, названия продукта и его типа.

• Спецификация продукта — файл Word, содержащий подробные проектные сведения о продукте. Дополнительные метаданные включают проектировщика и дату окончательного рассмотрения.

• Спецификация тестирования — файл Word, содержащий план тестирования продукта. Дополнительные метаданные включают тестировщика и состояние выполнения тестирования.

• План разработки — файл Word, содержащий план разработки продукта.

• Раскадровка — презентация PowerPoint, используемая для представления макета проекта.

• Анализ затрат — электронная таблица Excel, в которой анализируются затраты на разработку продукта и рыночные возможности.

• График реализации — электронная таблица Excel, содержащая сведения о графике разработки продукта.

В этом примере пользователи могут выполнять фильтрацию по типу контента, чтобы найти спецификацию продукта или раскадровку. Настраиваемые шаблоны также позволяют организовать работу пользователей. Число столбцов и типов контента достаточно невелико, чтобы пользователи могли легко выбирать нужные варианты, а благодаря заполнению метаданных упрощается фильтрация и поиск контента.

Столбцы

Число столбцов и обязательные столбцы

С помощью столбцов можно указывать, какие метаданные должен иметь элемент, а также помечать их как скрытые, необязательные или обязательные. Используйте скрытые столбцы для выполнения автоматических задач, например рабочих процессов, в которые пользователи не могут вносить изменения. Используйте обязательные столбцы, только если это действительно необходимо. Например, свойство метаданных может быть необходимо для маршрутизации элемента в соответствующее расположение или для навигации. Такие значения не должны оставляться пустыми. Чем больше число элементов, для которых не заполнены метаданные в столбце, используемом в качестве фильтра навигации, тем ниже эффективность навигации, поскольку многие элементы не будут возвращаться запросами.

По мере увеличения числа столбцов метаданных растет вероятность того, что пользователи не будут заполнять метаданные, поскольку на определение необходимых столбцов и указание значений будут требоваться дополнительные усилия. Большое число обязательных столбцов может быть помехой для принятия решения пользователями, так как на отправку контента требуется много времени. В сценариях совместной работы с открытым доступом к данным это может иметь негативные последствия. Однако по мере увеличения ценности контента и усилий, затрачиваемых на его создание, вероятность того, что пользователи будут уделять время на заполнение соответствующих полей, возрастает, особенно если делать это приходится нечасто.

На этапе проектирования следует продумать, какие метаданные являются необходимыми для выполнения требуемых операций и извлечения контента, оценить время, которое пользователи будут затрачивать на заполнение метаданных, и решить, как это скажется на удобстве работы. Если пользователи не примут систему из-за больших временных затрат на создание контента, переделать ее в дальнейшем будет сложно.

Типы полей и выбор между полями с одним или с несколькими значениями

При выборе столбцов одним из моментов является тип столбца и число значений. Запросы к полям управляемых метаданных более эффективны, чем запросы к столбцам выбора, поэтому использование полей управляемых метаданных, возможно, будет более целесообразным. Такие столбцы, как столбцы управляемых метаданных или столбцы пользователей и групп, допускают несколько значений. Запросы к столбцам с несколькими значениями не так эффективны, как запросы к столбцам с одним значением.

Столбцы и типы контента обычно являются основным средством классификации и извлечения контента в больших списках. Список столбцов и типов контента должен быть выработан в процессе планирования. Добавление в список столбцов и типов контента может оказать скрытое влияние на производительность. Например, добавление столбцов определенного типа в отдельный список может привести к переносу по строкам. Дополнительные сведения см. в разделе Перенос по строкам выше в этой статье.

Пример большого списка для совместной работы и столбцов: библиотека спецификаций продуктов

В данном примере используются следующие столбцы:

• столбцы, задаваемые SharePoint Server 2010 автоматически: "Идентификатор", "Тип контента", "Изменен", "Создан", "Автор изменений", "Кем создан", "ИД документа";

• столбцы, задаваемые с помощью настроек:

  • значения метаданных по умолчанию для столбцов "Тип продукта" и "Группа разработки продукта" (каждое поле "Тип продукта" имеет папку, а каждая папка "Тип продукта" имеет несколько папок "Группа разработки продукта");

  • состояние рабочего процесса: "Состояние утверждения", "Проект завершен";

• столбцы, задаваемые пользователями: "Проектировщик", "Инженер-испытатель", "Дата окончательного рассмотрения";

• столбцы, служащие для навигации: "Тип контента", "Тип продукта", "Группа разработки продукта";

• столбцы, служащие для отслеживания состояния и также используемые для навигации: "Дата окончательного рассмотрения", "Состояние утверждения", "Проект завершен";

• столбцы, которые могут использоваться для навигации: "Проектировщик", "Инженер-испытатель", "Название продукта", "Изменен", "Автор изменений".

Сводка рекомендаций по использованию столбцов

• Сведите к минимуму число столбцов, доступных для заполнения.

• Тщательно выберите столбцы, которые будут использоваться для выполнения системных процессов и навигации. Продумайте, какие поля должны быть обязательными, чтобы свести их число к минимуму.

• Обязательные поля следует использовать, если они необходимы для навигации. Примером может служить использование веб-части "Запрос контента" применительно к определенному полю. Их также следует использовать для администрирования, например указания действий сохранения в поле даты пользователями.

• Поскольку запросы к столбцам с одним значением выполняются быстрее, чем к столбцам с несколькими значениями, пытайтесь использовать столбцы с несколькими значениями только в случае необходимости.

Если общее число столбцов определенного типа в списке превышает некоторое значение, происходит перенос по строкам, что снижает производительность. Сведите к минимуму число столбцов в большом списке и по возможности избегайте переноса по строкам.

Папки

Следует тщательно продумать организацию контента по папкам. Папки можно использовать тремя способами.

• Используйте папки для логической организации контента. Например, контракты можно распределить по папкам в соответствии с годом или месяцем их подписания, а счета — в соответствии с датой их создания. В таком случае пользователи смогут легко перемещаться по структуре папок или использовать метаданные для поиска документов. Кроме того, это упростит автоматическую маршрутизацию документов в нужные папки. Организатор контента предоставляет возможности, с помощью которых можно ограничить число элементов в отдельной папке. Для этого при превышении заданного числа элементов в папке создаются вложенные папки.

• Используйте организацию контента по папкам для задания срока хранения, разрешений или выполнения других административных задач. Например, можно создать папку для конфиденциальных документов, доступ к которым предоставляется ограниченному числу пользователей, или реализовать хранение на основе расположения, при котором документы имеют разное расписание хранения в зависимости от того, в какой папке они находятся. В этом сценарии навигация может быть более сложной для пользователей, поскольку они могут не знать, где именно находится нужный им документ. Предпочтительными способами поиска документов в этом случае являются навигация по метаданным и функция поиска, а не использование структуры папок.

• Используйте организацию контента по папкам, чтобы упростить пользователям навигацию по разделам или категориям. Многие пользователи привыкли к навигации с помощью папок. В некоторых ситуациях может быть желательно сохранить структуру папок, чтобы обеспечить удобство навигации, например, если пользователи хорошо знакомы со структурой папок и знают, где искать документы и куда их сохранять. В сочетании с этим методом можно использовать навигацию по метаданным и функцию поиска.

Улучшенные возможности SharePoint Server 2010 обеспечивают большую гибкость при использовании папок. При этом сохраняется высокий уровень производительности. С помощью управляемых метаданных и навигации по метаданным пользователи могут легко выполнять фильтрацию по метаданным вместо перемещения по папкам. Это позволяет учитывать при организации контента не только удобство навигации, но и удобство администрирования, например назначения разрешений или применения политик. Например, имеется папка с конфиденциальными материалами, доступ к которой разрешен ограниченному кругу лиц, и другая папка, доступ к которой разрешен всем сотрудникам. Для этих папок можно задать разные разрешения, а затем использовать организатор контента, чтобы автоматического помещать контент в соответствующую папку на основании метаданных. Использование папок для навигации можно также сочетать с навигацией по метаданным.

Организатор контента позволяет автоматически помещать контент в нужные папки в соответствии с типами контента и метаданными, освобождая пользователей от этой задачи. Кроме того, организатор контента можно использовать для автоматического создания новых папок, если число элементов в какой-либо из папок превышает заданное ограничение. Следует учесть, что функция "Открыть в проводнике" (WebDAV) не работает в больших списках, если элементы не упорядочены по папкам, корни которых содержат число элементов, не превышающее пороговое значение представления списка.

Производительность представлений на основе папок и представлений на основе метаданных почти не различается. С логической точки зрения и с позиции пользователя для разделения контента разумнее использовать папки. Навигация по метаданным предполагает рекурсивные запросы, поэтому возвращаются все элементы безотносительно к папкам. Если это основной метод извлечения контента, структура папок может быть ненужной.

На следующей диаграмме показаны результаты тестирования, в ходе которого для доступа к одному и тому же набору элементов использовались представления различных типов. Все представления возвращали 1000 результатов. Диаграмма иллюстрирует зависимость числа запросов в секунду от размера списка для каждого типа представления. Из этих результатов видно, что по мере увеличения размера списка производительность представлений папок и индексированных представлений остается сравнительно стабильной, хотя производительность представлений папок немного выше при малом размере списка. Для большинства больших списков представления папок и индексированные представления используются в сочетании, поэтому различия в производительности не должны обуславливать выбор папок или индексов в качестве средства извлечения данных.

Сводка рекомендаций по использованию папок

• Спланируйте способ организации элементов по папкам. Элементы могут помещаться в папки автоматически или вручную.

• Такие возможности, как навигация по метаданным, делают ограничение числа элементов в папках не столь важным.

• Используйте навигацию по метаданным в сочетании с навигацией по папкам. Таким образом папки можно использовать для управления политиками и сроками хранения, а не только для упорядочения контента с целью извлечения.

• Если это необходимо для обеспечения удобства работы пользователей, организуйте контент по папкам, даже если одновременно используются другие способы навигации.

• Если для автоматического помещения документов в папки в соответствии с метаданными используется организатор контента, рассмотрите необходимость включения функции, позволяющей создавать вложенные папки при превышении максимального числа элементов в папке.

• Если планируется использовать функцию "Открыть в проводнике" (WebDAV), элементы следует распределять по папкам так, чтобы число элементов в корне любой папки не превышало порогового значения представления списка.

• Если папки не используются, для извлечения контента в представлениях списка необходимо использовать навигацию по метаданным и индексы.

Пример большого списка для совместной работы и папок: библиотека спецификаций продуктов

В библиотеке спецификаций продуктов папки используются для навигации и логического разделения контента. Пользователям ясно, какую папку следует использовать для создания новой спецификации продукта. Для каждого типа продукта имеется отдельная папка, в которой имеется несколько папок для каждой группы разработки продукта. Каждая группа разработки имеет набор документов для каждого проектируемого продукта, в котором сохраняются документы, связанные с продуктом. Таким образом формируется следующая структура.

• "Горные лыжи" — тип продукта (папка)

  • "Гоночные лыжи" — группа разработки продукта (папка)

    "Super Faster Downhill Racer X" — продукт (набор документов)

Для каждой из папок можно настроить значения метаданных по умолчанию, и с помощью папок пользователи библиотеки могут легко находить контент.

Пример крупномасштабного архива и папок: центр записей

Сайт "Центр записей" используется для долгосрочного хранения элементов с целью соблюдения нормативных требований. Активного изменения контента не производится. В этом сценарии элементы автоматически перенаправляются в две папки: "Для служебного пользования" и "Конфиденциально". К папке "Для служебного пользования" имеет доступ строго ограниченный круг лиц; документы в ней должны храниться в течение 10 лет. Доступ к папке "Конфиденциально" не так ограничен, и документы в ней должны храниться 7 лет. Это позволяет сократить число уникальных разрешений и упрощает управление разрешениями, поскольку элементы наследуют разрешения от папки, в которой находятся. Все элементы, отправляемые на сайт "Центр записей", помещаются в корневую папку, папку "Конфиденциально" или папку "Для служебного пользования" в соответствии с метаданными.

Индексы

Максимальное число индексов, которые можно создать для одного списка, включая составные индексы и индексы, создаваемые SharePoint Server 2010 для столбцов по умолчанию, составляет 20. Изменить это значение невозможно. Добавление индексов к списку оказывает минимальное воздействие на производительность. Однако оно влияет на некоторые операции, например добавление и обновление. Следует избегать использования лишних индексов, поскольку неиспользуемые индексы будут немного снижать производительность, а некоторые компоненты SharePoint Server 2010 добавляют индексы, если они включены. Например, если используются функции "Истечение срока действия" и eDiscovery, серверу SharePoint Server 2010 требуются по крайней мере три свободных индекса. Рекомендуется оставлять по крайней мере три незанятых индекса на тот случай, если позднее потребуется создать дополнительные индексы.

Для работы со структурой таблицы базы данных в SharePoint Server 2010 используется собственный механизм индексации. Чтобы создать индексы в SharePoint Server, необходимо изменить параметры списка.

При планировании индексов учитывайте следующий моменты.

• Индексы необходимы для фильтрации списков, размер которых превышает пороговое значение представления списка.

• Тщательно продумайте, какие одиночные и составные индексы необходимо создать, поскольку существует ограничение в 20 индексов.

• Оставьте несколько незанятых индексов для компонентов SharePoint Server 2010, которым может потребоваться создать индексы, таких как eDiscovery и политика управления сведениями "Хранение".

• Создавайте одиночные индексы при использовании веб-частей "Запрос контента" для фильтрации по одному полю, представлений с фильтрами, а также иерархий навигации по метаданным и фильтров, которые часто используются как один фильтр.

• Создавайте составные индексы для запросов, которые выполняют фильтрацию по двум столбцам и часто возвращают число элементов, превышающее пороговое значение представления списка, если используются по отдельности, однако более избирательны при использовании в сочетании друг с другом.

• Индексы могут отрицательно влиять на производительность некоторых операций, таких как добавление документа или изменение его свойств. Поэтому создавать индексы следует, только если это необходимо.

Тщательное планирование индексов

Индексированные столбцы очень важны при использовании больших списков, однако существует жесткое ограничение в 20 индексов на список. Поэтому необходимо тщательно выбирать одиночные и составные индексы. Некоторые компоненты также используют индексы. Например, функция навигации по метаданным автоматически выполняет индексацию для настроенных иерархий навигации и ключевых фильтров. Индексы следует создавать для тех столбцов, которые имеют важное значение для навигации и архитектуры данных.

Автоматически создаваемые индексы

Компоненты SharePoint Server могут создавать индексы, которые учитываются в общем числе индексов. В следующей таблице приведен список компонентов SharePoint Server 2010, добавляющих индексированные столбцы, которые часто используются в библиотеках документов.

Столбец	Компонент	Использование
Состояние записи и удержания	"Управление записями по месту" или "Удержания и eDiscovery"	Этот столбец добавляется и индексируется, если включена функция "Управление записями по месту" семейства веб-сайтов или функция "Удержания и eDiscovery" и элемент списка объявляется записью или помещается на удержание.
"Срок действия", "Тип контента"	Политика управления сведениями	Эти два столбца добавляются и индексируются, если в компоненте политики управления сведениями включено хранение для типа контента, добавляемого в список, или если для списка включено хранение на основе расположения.

Когда следует создавать одиночные и составные индексы

Функция навигации по метаданным автоматически создает соответствующие индексы для столбцов иерархии и ключевого фильтра, выбранных на странице параметров навигации по метаданным. Одиночные индексы создаются для всех полей иерархического дерева и для некоторых более избирательных типов ключевых фильтров, чтобы при их использовании по отдельности могли возвращаться индексированные результаты и частичные результаты. Составные индексы создаются для всех поддерживаемых комбинаций иерархий и ключевых фильтров, чтобы максимально повысить избирательность при совместном использовании значений фильтра дерева и ключевого фильтра.

Если в списке имеется много столбцов, по которым может производиться фильтрация, может потребоваться ручное управление индексами во избежание достижения ограничения на число индексов. Если определенные комбинации иерархий навигации и ключевых фильтров никогда не будут использоваться, не следует создавать для них составные индексы, чтобы не увеличивать их числа. При создании индексов следует создавать одиночные индексы для столбцов, которые обладают достаточной селективностью и могут самостоятельно использоваться в представлении списка либо в качестве единственного фильтра, либо в качестве первого фильтра, после применения которого выбирается следующий. Составные индексы следует применять в том случае, если два фильтра обычно используются вместе в навигации по метаданным или в настраиваемых запросах и если один индекс сам по себе недостаточно селективен. Создавайте индексы для столбцов, используемых для фильтрации с помощью представлений списка, веб-частей и других методов доступа к данным.

В некоторых случаях в использовании нескольких индексов нет необходимости. Рассмотрим ситуацию, в которой производится фильтрация по двум столбцам: "Отдел" и "Тип контента". Поскольку это операция И, возвращается пересечение соответствий для фильтров по столбцам "Отдел" и "Тип контента". Это означает, что при выполнении запроса сначала возвращаются все элементы, соответствующие фильтру "Отдел", после чего они фильтруются по столбцу "Тип контента". Если имеется только 10 элементов, соответствующих определенному отделу, набор данных будет достаточно небольшим и в индексе для столбца "Тип контента" не будет необходимости. Если значению, указанному для столбца "Отдел", соответствуют тысячи элементов, следует использовать составной индекс.

Составные индексы позволяют создавать индексы для двух столбцов, что повышает эффективность запросов. Составные индексы следует использовать при применении операции И к двум столбцам. Единственной встроенной функцией SharePoint Server, использующей составные индексы, является навигация по метаданным. Если эта функция включена, логика повторных и резервных запросов используется, даже если для списка не настроены элементы управления навигацией по метаданным. Составные индексы используются представлениями только при выполнении запросов навигации по метаданным.

Влияние индексов на производительность

Индексы необходимы для выполнения запросов к спискам, содержащим контейнеры, число элементов в которых превышает пороговое значение представления списка. Они могут обеспечивать значительное повышение производительности. Хотя индексы необходимы для эффективного выполнения запросов к большим спискам и могут ощутимо улучшить производительность запросов, они могут оказывать негативное влияние на другие операции, поскольку для их поддержания требуются ресурсы. При создании, изменении или удалении элементов также производится обновление всех индексов, в которые эти элементы включены. Было проведено тестирование операций отправки, изменения и удаления применительно к списку, содержащему 10 000 элементов, и результаты показали, что разница в производительности в случаях, когда индексы не используются и когда используется 20 индексов, составляет менее 10 %.

Создание индексов

По умолчанию функция навигации по метаданным автоматически создает одиночные и составные индексы. Этот параметр можно отключить на странице параметров навигации по метаданным. Функция навигации по метаданным автоматически создает одиночный индекс для каждого поддерживаемого типа столбца и составной индекс для каждой поддерживаемой комбинации иерархии навигации и ключевого фильтра. Для комбинаций двух ключевых фильтров составные индексы не создаются автоматически, однако их можно создать вручную. Функция навигации по метаданным автоматически создает одиночные и составные индексы для большинства типов столбцов, поддерживающих индексы. Одиночные индексы не создаются автоматически для типов ключевых фильтров, которые имеют мало значений и сами по себе могут быть недостаточно селективными. К ним относятся столбцы типа "Да/Нет", столбцы с выбором одного значения и столбцы типа контента. Однако индексы для таких столбцов поддерживаются, и их можно создать вручную.

Столбцы, поддерживающие одиночные индексы

В следующей таблице приведены сведения об индексах, автоматически создаваемых функцией навигации по метаданным. Эта функция создает индексы с одним значением для всех столбцов, поддерживающих создание индекса.

Тип столбца	Создается ли индекс
Иерархии навигации
Управляемые метаданные с одним значением	Да
Управляемые метаданные с несколькими значениями	Нет (индексируется системой как имеющий несколько значений)
Идентификатор типа контента	Да
Выбор одного значения	Да
Папка	Нет (индексируется системой по папке)
Ключевые фильтры
Управляемые метаданные с одним значением	Да
Управляемые метаданные с несколькими значениями	Нет (индексируется системой как имеющий несколько значений)
Идентификатор типа контента	Нет (можно создать вручную)
Выбор одного значения	Нет (можно создать вручную)
Выбор нескольких значений	Нет (индексация не поддерживается)
Число	Да
Дата	Да
Да/Нет	Нет (можно создать вручную)
Денежный	Да
Пользователь (одно значение)	Да
Пользователь (несколько значений)*	Нет (индексируется системой как имеющий несколько значений)
Все теги	Нет (индексируется системой как имеющий несколько значений; специальный фильтр, применяемый ко всем значениям управляемых метаданных элемента)

Автоматически создаваемые составные индексы

С помощью функции навигации по метаданным пользователь может выбрать комбинацию из иерархии навигации и ключевого фильтра. Функция навигации по метаданным автоматически создает составные индексы для всех поддерживаемых комбинаций иерархий навигации и ключевых фильтров. В следующей таблице приведены поддерживаемые комбинации.

Иерархии навигации	Управляемые метаданные с одним значением	Управляемые метаданные с несколькими значениями	Идентификатор типа контента	Выбор одного значения	Папка
Ключевые фильтры
Управляемые метаданные с одним значением	Да	Нет	Да	Нет	Нет
Управляемые метаданные с несколькими значениями	Нет	Нет	Нет	Нет	Нет
Идентификатор типа контента	Да	Нет	Нет	Нет	Нет
Выбор одного значения	Нет	Нет	Нет	Нет	Нет
Выбор нескольких значений	Нет	Нет	Нет	Нет	Нет
Число	Да	Нет	Да	Нет	Нет
Дата	Да	Нет	Да	Нет	Нет
Пользователь (одно значение)	Да	Нет	Да	Нет	Нет
Все теги	Нет	Нет	Нет	Нет	Нет
Да/Нет	Да	Нет	Да	Нет	Нет
Денежный	Да	Нет	Да	Нет	Нет
Пользователь (несколько значений)	Нет	Нет	Нет	Нет	Нет

Селективность метаданных

Значение селективности метаданных возрастает по мере увеличения размера списка. Однако следующие рекомендации относятся к спискам любого размера, хотя могут быть не столь важны для небольших списков.

Селективность — это число элементов, которое необходимо просмотреть, чтобы запрос вернул результаты. Селективность имеет два аспекта: фактическая селективность (общее число результатов, соответствующих условию поиска в запросе) и селективность регулирования (число результатов, которое необходимо просканировать после применения условий к индексированным столбцам). С точки зрения пользователя наибольшую важность имеет фактическая селективность. Но с точки зрения влияния на экземпляр SQL Server большее значение имеет селективность регулирования.

Для эффективного использования навигации по метаданным и других механизмов фильтрации списка метаданные, используемые для фильтрации, должны быть селективными. По умолчанию в представлениях списка отображается 30 элементов, чтобы пользователи могли быстро просмотреть результаты и найти то, что их интересует. Если запросы возвращают более 30 результатов, пользователям необходимо использовать постраничный просмотр. При использовании веб-части "Запрос контента" число результатов обычно составляет от 10 до 15. Если же их больше, дополнительные результаты не отображаются. Если запрос возвращает сотни результатов, найти среди них нужный становится непросто. Селективность также позволяет избежать превышения порогового значения представления списка при выполнении операций, которое в случае с навигацией по метаданным приводит к резервным запросам и неполным результатам.

Организатор контента и автоматическая балансировка

Организатор контента может быть наиболее важным компонентом для организации контента в репозитории документов. В репозитории, в которых используется организатор контента, пользователи обычно отправляют документы в окончательном состоянии. К некоторым примерам сценариев, в которых может использоваться организатор контента, относятся следующие:

• автоматическая маршрутизация документов между сайтами и внутри них в соответствии с метаданными;

• автоматическая маршрутизация документов и создание папок, например, в соответствии с днем, месяцем и годом;

• автоматическая балансировка числа элементов в папках.

Доступ к данным и их извлечение

Основным назначением большинства больших списков является хранение контента с возможностью его последующего извлечения. Важно спланировать, как пользователи будут извлекать контент, так как от этого во многом зависит производительность большого списка и успешность его реализации. Чтобы обеспечить извлечение контента пользователями, можно использовать ряд возможностей, включая поиск, навигацию по метаданным, веб-части "Запрос контента" и представления. Также часто используются настраиваемые решения, например настраиваемые веб-части, выполняющие запросы к данным. Заблаговременно спланируйте организацию веб-сайта. Для сведения контента и предоставления точек входа в большой список может использоваться центральная начальная страница, например домашняя страница сайта "Центр документов". Используя публикацию страниц, можно также создать веб-сайт, на котором различным темам посвящены отдельные страницы, а затем использовать веб-части для извлечения связанных документов или элементов из большого списка. При планировании доступа к данным и их извлечения следует учитывать следующие моменты.

• Поиск, веб-части "Запрос контента", навигацию по метаданным, представления списка и настраиваемые веб-части можно использовать в любых сочетаниях.

• Заранее спланируйте, как будет извлекаться контент и какие столбцы будут использоваться для фильтрации и сортировки.

• Создайте базовую модель страницы. Решите, будет ли вся работа вестись в библиотеке документов, будет ли использоваться начальная страница или будет использоваться модель с несколькими страницами со ссылками на связанный контент.

Методы доступа к данным

В SharePoint Server 2010 имеются три основные возможности, позволяющие запрашивать и фильтровать данные списка после несложной настройки: представление списка и навигация по метаданным, веб-часть "Запрос контента" и поиск. Существуют также дополнительные возможности по использованию настраиваемого кода для выполнения запросов к списку, которые не рассматриваются в этой статье.

• Представления позволяют настраивать отображаемые столбцы. Существуют различные методы отображения данных списка. В представлениях можно настроить фильтрацию и сортировку результатов по столбцам.

  • Навигация по метаданным — это элемент управления фильтрацией для представлений списка SharePoint Server 2010. При настройке навигации по метаданным можно выбрать иерархии метаданных и ключевые фильтры для динамической фильтрации результатов, отображаемых в представлении списка.

• Веб-часть "Запрос контента" отображает данные из списков SharePoint Server 2010. Можно настроить запросы, возвращающие результаты из одного или нескольких списков. По умолчанию веб-часть "Запрос контента" кэшируется. Однако она может быть и некэшируемой.

• Результаты поиска могут возвращаться полями поиска и веб-частями результатов поиска. Эти результаты можно ограничить определенным списком и выполнять управляемый поиск с помощью элементов уточнения метаданных поиска.

В следующей таблице перечислены методы запроса и способы их использования.

Метод запроса	Использование
Представление списка и навигация по метаданным	Представления списка всегда обращаются к базе данных SQL Server с таблицами, что приводит к наибольшему воздействию на производительность при выполнении запросов и повышает нагрузку на сервер SQL Server. Используйте представления списка, если необходимы расширенные возможности по взаимодействию с документами (извлечение, возврат, изменение свойств) и доступ к данным в режиме реального времени.
Веб-часть "Запрос контента"	Веб-части "Запрос контента" используют поставщик карты сайта портала для кэширования запросов и обрабатывают минимальный объем HTML-кода, что приводит к более быстрому выполнению запросов и подготовке к просмотру. Используйте веб-части "Запрос контента" для динамической навигации и выполнения нескольких запросов на одной странице.
Веб-часть "Запрос контента" без кэширования	Чтобы обеспечить доступ к данным в режиме реального времени, веб-часть "Запрос контента" может обращаться к базе данных напрямую. Используйте такую конфигурацию, если запрос не может кэшироваться, если необходимы изменения в режиме реального времени или если обращения к странице происходят реже, чем один раз в час, так что кэш заполняться не будет. Первоначальная загрузка кэшируемой веб-части "Запрос контента" связана с дополнительной нагрузкой.
Поиск	Используйте поисковые запросы, чтобы перенести нагрузку, связанную с выполнением операций чтения, на инфраструктуру серверов, которая легче масштабируется и оптимизирована для выполнения таких операций. Можно настроить статические поисковые запросы или разрешить пользователям создавать собственные поисковые запросы.

Веб-части "Запрос контента"

В следующей таблице приведены различные преимущества и недостатки использования веб-частей "Запрос контента".

Плюсы	Минусы
Эффективный компонент навигации, например для создания ссылок на связанные документы или страницы. Легко настроить для отображения различных столбцов. На одной странице можно легко использовать несколько веб-частей "Запрос контента". Наиболее быстрая отрисовка по сравнению с функцией поиска и представлениями списка. По умолчанию кэшируется, что снижает нагрузку на сервер SQL Server.	Отображаться может ограниченное число свойств. Ссылки могут указывать напрямую только на элементы, например документ, страницу или элемент списка. Нельзя выполнять действия со списком.

Веб-часть "Запрос контента" служит для извлечения контента из списков. Она может использоваться для страниц, документов и элементов списка. По умолчанию веб-части "Запрос контента" кэшируются, что обеспечивает более высокую производительность и меньшую нагрузку на ресурсы сервера SQL Server. По умолчанию период кэширования равен 30 минутам. Поэтому данные поддерживаются в достаточно актуальном состоянии. Однако это также означает, что веб-часть "Запрос контента" потребляет больше ресурсов сервера SQL Server, чем запросы поиска. Поскольку веб-части "Запрос контента" обрабатывают наименьший объем HTML-кода, они обеспечивают наиболее быструю отрисовку страниц. .Кроме того, на одной странице можно настроить несколько веб-частей "Запрос контента". Кэшируемые веб-части "Запрос контента" обеспечивают быстрый доступ к данным по мере увеличения размера списка. Задержки при использовании некэшируемых веб-частей "Запрос контента" почти равны задержкам при выполнении аналогичных запросов представления списка.

Веб-части "Запрос контента" следует использовать в качестве компонента навигации и для сведения контента на страницах. Например, на страницах можно представить обзор контента, содержащегося в библиотеке документов, и затем использовать веб-части "Запрос контента" для извлечения соответствующих страниц и документов. Другими примерами могут служить элементы, измененные текущим пользователем, последние элементы и элементы с наиболее высоким рейтингом. Веб-части "Запрос контента" можно использовать в сценариях с высокой интенсивностью операций чтения, когда большинству пользователей не требуется выполнять действия со списками, такие как извлечение, возврат или управление версиями. На следующем рисунке показана веб-часть "Запрос контента", отображающая документы с наиболее высоким рейтингом.

Веб-часть "Запрос контента" можно использовать, чтобы получать доступ к контенту, не открывая представление списка. Например, пользователи могут часто обращаться к небольшому набору контента или отслеживать определенные элементы. В шаблоне сайта "Центр документов" по умолчанию используются три веб-части "Запрос контента": первая возвращает элементы, измененные вошедшим пользователем, вторая — документы с наиболее высоким рейтингом, а третья — последние документы. В сочетании эти три веб-части "Запрос контента" формируют начальную страницу, обеспечивающую доступ к наиболее востребованному контенту. Они позволяют находить новый контент и быстро открывать часто используемые документы. Другим примером может служить создание списка избранного, позволяющего пользователям помечать контент для отслеживания, с последующим использованием веб-части "Запрос контента" для извлечения этого списка. Таким образом пользователи могут быстро получать доступ к часто используемому контенту, не обращаясь к самому списку.

При использовании веб-части "Запрос контента" с большим списком необходимо учесть ряд моментов для того, чтобы запросы возвращали правильные результаты и не блокировались пороговым значением представления списка. Чтобы число отфильтрованных элементов не превышало порогового значения представления списка, следует использовать индексированные столбцы. Не рекомендуется использовать запросы к нескольким спискам, если один из списков является большим. Если общее число элементов, проверяемых запросом к спискам, превышает пороговое значение представления списка для аудиторов и администраторов (по умолчанию 20 000), операция блокируется.

Сводка рекомендаций по использованию веб-частей "Запрос контента"

• Используйте веб-части "Запрос контента" для извлечения элементов, к которым пользователи могут часто обращаться, которые могут интересовать их или которые могут помочь пользователям в нахождении контента.

• При использовании веб-части "Запрос контента" применительно к большому списку число отфильтрованных элементов при выполнении запроса не должно превышать порогового значения представления списка.

• Для фильтрации следует использовать только столбцы с индексами.

• Не используйте веб-часть "Запрос контента" для запросов к нескольким спискам, если общее число проверяемых элементов превышает пороговое значение представления списка для аудиторов и администраторов (по умолчанию 20 000).

• Используйте кэширование, чтобы ускорить загрузку и снизить нагрузку на сервер SQL Server.

Веб-части поиска

В следующей таблице приведены различные преимущества и недостатки использования веб-частей поиска.

Плюсы

Минусы

Нагрузка, связанная с выполнением запросов, переносится с серверов SQL Server на поисковые серверы, которые легче масштабируются. Серверы запросов поиска и серверы индексов легче масштабируются и обеспечивают более высокую производительность по сравнению с прямыми запросами к серверам SQL Server. Возвращаются результаты полнотекстового поиска документов, а не поиска только по метаданным. Сводки текста предоставляют больше сведений о результатах, чем веб-части "Запрос контента".

Результаты наименее актуальны; их актуальность зависит от времени последнего обхода контента. В результатах не отображаются значения столбцов. Нельзя выполнять действия со списком.

Запросы поиска масштабируются лучше, чем прямые запросы к ресурсам SQL Server, поскольку функция поиска оптимизирована для сценариев с высокой интенсивностью операций чтения. Кроме того, серверы запросов поиска и серверы индекса проще масштабировать, чем экземпляры SQL Server. Чтобы обеспечить извлечение контента пользователями, можно использовать предварительно настроенные веб-части поиска, поля поиска или их комбинацию. Запросы поиска позволяют переносить выполнение запросов на индексы поиска, снижая нагрузку на сервер SQL Server. Кроме того, по сравнению с веб-частями "Запрос контента" или запросами представления списка на запросы поиска размер списка влияет меньше.

Функцию поиска можно использовать для отображения результатов предварительно настроенных или заданных пользователями запросов в любых сценариях. При высоком уровне масштабирования функция поиска обеспечивает наилучшую производительность. Однако ее не следует использовать в том случае, если необходимо выполнять действия со списками или отображать данные в режиме реального времени, поскольку актуальность результатов зависит от времени последнего обхода контента. В следующей таблице описываются три веб-части поиска, доступные для использования.

Веб-часть поиска	Описание
Веб-часть "Основные результаты"	Наиболее полнофункциональная веб-часть, отображающая полные результаты с разбиением по страницам. Она может выполнять системные или задаваемые пользователями запросы.
Веб-часть "Федеративные результаты"	Небольшой набор результатов с дополнительной ссылкой на полные результаты.
Веб-часть "Поле поиска"	Веб-часть, используемая для ввода пользователем запроса.

Представления списка

В следующей таблице приведены различные преимущества и недостатки использования представлений списка.

Плюсы	Минусы
Действия представления списка, такие как извлечение, возврат и изменение свойств, можно использовать для взаимодействия с документами. Представления просты в настройке и позволяют отображать различные столбцы. Интерактивные возможности динамической фильтрации и сортировки результатов в режиме реального времени.	Наибольшее отрицательное влияние на производительность в плане времени задержки и пропускной способности. Наибольшее время отрисовки. Максимальное удобство для пользователей достигается, если на странице используется только одна веб-часть представления списка.

Представления списка и навигация по метаданным обеспечивают извлечение контента в больших библиотеках документов, в которых используются папки и индексы (в том числе одновременно). Запросы представления списка выполняются в режиме реального времени и обращаются напрямую к базе данных SQL Server. Это позволяет получать самые актуальные результаты. Однако это также приводит к наибольшему снижению производительности. Про увеличении размеров списков уменьшается общая пропускная способность и увеличивается задержка операций. Кроме того, при использовании представлений списка для загрузки страницы обрабатывается наибольший объем контента. Поэтому время отрисовки страницы часто увеличивается.

Навигацию по метаданным и представления списка следует использовать, если необходимо выполнять действия представления списка с элементами. В сценариях с низкой интенсивностью операций чтения представления списка могут быть предпочтительным методом работы со списком. В противоположных сценариях, возможно, следует предпочесть другие методы в качестве основного способа доступа к данным списка.

Настройка представлений

Сводка рекомендаций по настройке представлений

• Тщательно выбирайте столбцы, используемые в представлениях. Чем больше столбцов, тем больше данных должно обрабатываться, а это увеличивает время загрузки страницы. Необходимо найти компромисс между временем загрузки страницы и удобством работы пользователей.

• Сведите к минимуму число столбцов подстановки в представлениях, например столбцов управляемых метаданных и столбцов пользователей и групп, поскольку они приводят к созданию соединений с другими таблицами базы данных и увеличивают нагрузку на базу данных.

• Не используйте итоги для столбцов.

• Если для фильтрации в представлениях не используются индексированные столбцы, включите параметр "Отображать элементы папок" и убедитесь в том, что число элементов в отдельных папках не превышает порогового значения представления списка.

• Представления следует фильтровать по индексированным столбцам, чтобы сократить число возвращаемых элементов и избежать превышения порогового значения представления списка (особенно если нет вложенных папок или если число элементов в папках превышает пороговое значение представления списка).

• Включите функцию навигации по метаданным, чтобы запросы, которые в противном случае блокировались бы пороговым значением представления списка, могли возвращать последние результаты. По умолчанию эта функция включена почти для всех сайтов.

• Если отфильтрованные представления используются в сочетании с навигацией по метаданным, можно использовать представления для расположений, чтобы создать неотфильтрованные представления для сводок навигации по метаданным, возвращающие все результаты.

Число обычных столбцов и столбцов подстановки

Представления — это самый обычный метод доступа к данным списка. К их выбору необходимо подойти тщательно, чтобы оптимизировать поиск контента для пользователей и выполнить требования к производительности. В случае с большим списком обратите особое внимание на настройку представлений. Рекомендуется использовать только стандартные и настраиваемые представления. Представления таблицы данных, диаграммы Ганта и календаря не рекомендуется использовать со списками, размер которых превышает пороговое значение представления списка, поскольку они могут блокироваться этим ограничением. Число столбцов в представлениях должно быть как можно меньше. Особое внимание обратите на число столбцов подстановки (управляемых метаданных, пользователей и групп, типов подстановки), поскольку при подстановке выполняется соединение с другими таблицами, что сказывается на производительности.

Фильтрация столбцов и итоги

С появлением в SharePoint Server 2010 порогового значения представления списка были внесены существенные изменения в использование представлений с большими списками. Пользователи получают сообщение об ошибке, если представления пытаются вернуть результаты, число которых превышает пороговое значение представления списка. Использование итогов в большом списке всегда блокируется пороговым значением представления списка. Поэтому использовать их не следует. В первую очередь имеет значение число элементов, которые должны быть просканированы, а не число возвращаемых строк. Если в представлении имеется фильтр, в котором для столбца "Цвет" задано значение “Красный”, но столбец "Цвет" не является индексированным, запрос может быть блокирован. Даже если этому запросу соответствует всего 100 элементов, но список содержит 10 000 элементов, запрос должен просканировать все 10 000 элементов. В этом случае при попытке доступа к представлению пользователи получают сообщение об ошибке. Чтобы решить эту проблему, можно воспользоваться папками, фильтрами и индексацией, а также навигацией по метаданным.

Папки

Если список организован так, что ни в одной из папок число элементов не превышает порогового значения представления списка, можно выбрать параметр "Отображать элементы папок". Отображения всех элементов безотносительно того, в какой папке они находятся, следует избегать, если только не реализован механизм, позволяющий отфильтровывать результаты до наборов, размер которых не превышает предельного значения представления списка.

Индексация

В приведенном выше примере выполнение запроса по столбцу "Цвет" завершалось ошибкой, поскольку этот столбец не был проиндексирован. Чтобы решить эту проблему, можно проиндексировать столбец "Цвет", после чего запросы станут выполняться нормально, если значения достаточно селективны. Если имеется только 100 элементов со значением "Красный", то проблем не возникнет. Однако если число соответствующих элементов превышает пороговое значение представления списка, то даже при использовании индексации запрос будет блокироваться. По умолчанию поле идентификатора, структура папок и столбцы подстановки с несколькими значениями индексируются системой. Индексы для создаваемых столбцов, по которым будет производиться фильтрация, должны создаваться вручную.

Примеры представлений

Недавно измененные элементы

Представление "Недавно измененные элементы" служит для отображения последних измененных элементов. Его можно использовать в качестве представления по умолчанию, если пользователи часто обращаются к недавно изменявшемуся контенту из различных источников. Настроить это представление не сложно, поскольку в нем используются системные метаданные, которые всегда задаются для каждого элемента. Для большого списка следует задать максимальное число элементов, не превышающее порогового значения представления списка, либо реализовать фильтрацию результатов до набора, размер которого не превышает предельного значения представления списка. Чтобы создать это представление, необходимо проиндексировать поле "Изменено" и выполнить сортировку по убыванию. Задайте фильтр для столбца "Изменено" и воспользуйтесь следующей формулой: [Сегодня-x], где x — это число дней, за которые необходимо показать данные. Выберите вариант "больше или равно". Формула [Сегодня-x] должна возвращать число элементов, не превышающее порогового значения представления списка.

Мои элементы

Представление "Мои элементы" может использоваться в репозиториях, пользователи которых часто обращаются к собственным документам. Настроить это представление не сложно, поскольку в нем используются системные метаданные, которые всегда задаются для каждого элемента. В этом представлении выполняется фильтрация по столбцам "Автор изменения" и "Кем создано". Чтобы создать это представление, выберите в фильтре столбец "Автор изменения", установите значение [Я], после чего задайте второй фильтр с оператором ИЛИ для столбца "Кем создано", также установив для него значение [Я]. Столбец "Кем создано" следует использовать в дополнение к столбцу "Автор изменения", если несколько пользователей изменяют одни и те же документы. В столбце "Автор изменения" указывается только один пользователь. Поэтому это представление может не отображать все документы, которые пользователь когда-либо изменял. В данном примере оба столбца должны быть проиндексированы, так как выполняется операция ИЛИ.

Заключение

SharePoint Server 2010 предоставляет новые и улучшенные возможности, повышающие удобство работы пользователей и производительность при работе с большими списками. Регуляторы и ограничения обеспечивают производительность фермы для других пользователей и предотвращают потребление операциями несоразмерно большого количества ресурсов SQL Server. Улучшенные возможности метаданных и навигация по метаданным расширяют возможности по извлечению данных из списков. Для работы с большими списками можно настроить веб-части "Запрос контента", функцию поиска и представления списка. Чтобы создавать правильные решения, соответствующие предъявляемым требованиям, по-прежнему необходимо тщательное планирование. Однако существуют готовые решения, разработанные для обеспечения высокой производительности, которые позволяют быстро создавать большие списки.

See Also

Other Resources

Центр ресурсов: управление емкостью в SharePoint Server 2010