Максимальный размер баз данных контента SharePoint

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

Как далеко вам удалось продвинуть установку SharePoint? Я слышал бывшие в употреблении истории> 1 ТБ контентных баз данных, но я хотел бы услышать от самих администраторов SharePoint.

Спасибо за любую информацию у вас есть.

У нас есть базы данных на 111 и 102 ГБ соответственно, резервное копирование которых занимает менее 30 минут в сети GigE. Я слышал, что у больших баз данных могут быть проблемы с долго выполняющимися хранимыми процедурами, но я не видел демонстрации этого.

Хорошая цитата из документа «Масштабирование SharePoint 2007: архитектура хранилища»:

«... Это обычно называют« ограничением размера базы данных контента в 100 ГБ ». На самом деле это не настоящее ограничение, а скорее рекомендация. Базы данных SQL Server уже несколько лет масштабируются гораздо больше 100 ГБ. Рекомендация основана в первую очередь на двух важных факторах:

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

2. Подсистема хранения должна быть достаточно устойчивой, чтобы соответствовать требованиям дискового ввода-вывода решения SharePoint, которое она обслуживает.

До тех пор, пока данная организация может смягчить эти два соображения, базы данных контента могут расти. В реальных реализациях были реализованы успешные развертывания SharePoint, в которых реализованы базы данных размером 100, 150, 200, 250, 300, 350 и 400 ГБ ».

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

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

У нас есть база данных контента размером 300 ГБ. Никаких проблем с резервным копированием после перехода на Lite Speed. До перехода мы увидели бы серьезное снижение производительности на веб-сайтах.

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

Когда мы впервые начали работу, у нас были серьезные проблемы с блокировкой базы данных во время пиковой нагрузки. Мы проследили это до использования объекта CrossListQueryCache в SharePoint. Мы отказались от использования этого API, и это сильно повлияло на нашу производительность.

Я написал небольшую статью в блоге с дополнительной информацией здесь .

Мы по-прежнему видим проблемы с блокировкой определенных типов обновлений (удаление больших двоичных объектов> 20 МБ), переименование веб-сайтов (это может привести к обновлению большого количества записей в таблице AllUserData. Мы работаем с MS Support в определенных случаях (например, удаляя крупные элементы из корзины). Это связано с тем, как определенные хранимые процедуры в SharePoint удаляют данные, но у нас пока нет решения.

Лично я думаю, что проблемы возникают после того, как вы получите так много записей в таблице AllUserData, и самый простой способ сообщить MS об этом людям - это остаться ниже 100 ГБ.

Я предлагаю пинговать людей в MS IT ... Я слышал, что у них есть контент-БД SharePoint> 800 ГБ.

Наша компания в настоящее время имеет базу данных в 140 Мб. Мы наблюдаем низкую производительность в одном конкретном списке, которому разрешено увеличиваться до 1,5 ГБ, который содержит вложения, включая несколько версий вложения. (Я был там только около 2 месяцев). Сейчас мы планируем миграцию, и похоже, что переход на SP 2010 с использованием инструмента Metalogix может занять несколько дней, основываясь на наших тестах. Наша база данных - плохо спроектированная база данных, плохо спроектированный портал, и теперь у нас есть те, кто сталкивается с реальными проблемами.

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

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