Списки SharePoint и производительность таблиц базы данных

Question

1. Мы ищем данные о транзакциях в списках SharePoint. Списки легко увеличатся до 100 000+ пунктов.
2. Как сравнить производительность запросов с запросами к таблице базы данных с этими столбцами?

Запросы: Выбрать по идентификатору Выберите Где ColumnValue = X Группировать по OrderId Группировка по дате

Список SP будет состоять из 6 столбцов: Id, Date, OrderId (Lookup), Quanity, ItemName, Title

Answer 1

Не делай этого. SharePoint плохо справляется с транзакционными данными и плохо работает.

Любые возможности, которые могут вам понадобиться для повышения производительности на уровне базы данных (например, добавление индексов), могут иметь пагубные последствия для установки SharePoint (хотя столбцы в списках можно «проиндексировать» через SharePoint.

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

К счастью, в SharePoint есть несколько способов интеграции транзакционных данных.

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

Если у вас нет лицензии Enterprise, я могу порекомендовать либо пользовательские элементы управления / веб-части, либо веб-часть просмотра данных, чтобы эти данные «отображались» на соответствующих страницах в SharePoint.

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

Answer 2

Я согласен со всеми приведенными выше комментариями. У меня был большой опыт работы с клиентами, которые хотели использовать списки SharePoint для вещей, которые им не подходили. Если вы вообще беспокоитесь о производительности, то списки SharePoint - не лучший способ. Если это просто для целей архивации, и вы выполняете нечастый поиск по данным, и вам достаточно функций поиска SharePoint, я мог бы рассмотреть это и не отклонить его из-под контроля (если вы используете MOSS).

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

И снова, если производительность вообще является требованием, тогда не делайте этого.

Для получения дополнительной информации о рекомендациях по масштабируемости и производительности SharePoint см .: http://technet.microsoft.com/en-us/library/cc287790.aspx

Answer 3

Практическое правило - ограничивать списки SharePoint до 2000 элементов из соображений производительности.

При 100k производительность будет идти «от сосания до удара».

Единственный способ, которым это может сработать, - это сегментировать набор данных в несколько списков, каждый из которых содержит менее 2000.

Answer 4

Конечно, предложенный подход не рекомендуется.

Но, будучи в теме, здесь является хорошим документом для больших списков перф в WSS

Answer 5

Сделав это сам, я бы сказал, постарайтесь избежать этого, если это возможно! Это минное поле, особенно после примерно 100 000 рядов.

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

Answer 6

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

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

Answer 7

+ 1 Нет

Основная функция SharePoint - это совместная работа. В вашем случае вы просто перечислите данные только для чтения. В вашей ситуации я бы рекомендовал хранить данные в SQL DB, если вам нужно отобразить их на портале SharePoint, вы можете использовать BDC или что-то вроде веб-части Bamboo Data View. http://store.bamboosolutions.com/p-71-data-viewer-web-part.aspx

Answer 8

Списки SharePoint будут работать медленнее.

Больше накладных расходов = худшая производительность.