Стратегия для обработки БД SQL Server со слишком большим количеством файлов (BLOB)?

Сценарий:
база данных SQL Server 2005, обслуживающая приложение ASP.NET (на отдельных веб-серверах).

База данных: в
БД содержится около 5 ГБ «обычных» данных и около 15 ГБ «файлов» (например, 200 КБ PDF, хранящийся в виде изображения (BLOB), и тому подобное). Пользователи загружают больше файлов и быстро занимают больше дискового пространства (в ближайшие несколько месяцев объем БД может увеличиться до 50 ГБ, в основном файлов).

Проблемы:
Хранение такого количества файлов в БД уже вызывает проблемы (например: Большой общий размер базы данных затрудняет случайное резервное копирование и развертывание всей БД).

И мы обеспокоены тем, что будет больше проблем . (например: проблемы с производительностью - может быть вызвано невозможностью сохранить всю БД в ОЗУ, возможно?)

Вопрос:
Какое техническое решение вы бы предложили для этой проблемы? Хранить файлы в файловой системе? Разделить базу данных на две части и получить большую, более медленную для файлов?

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

Я присматриваю за очень похожей базой данных, в настоящее время 3 ТБ и объемом 5 ГБ в день.

• Filestream (2008+) не решает проблему резервного копирования / восстановления.
• Filestream работает лучше, чем LOB-хранилище для файлов размером более 1 МБ, так утверждает Пол Рэндал . Его рабочая нагрузка составляет 256 КБ-1 МБ и, как правило, хуже <256 КБ.
• Большим плюсом для Filestream в некоторых средах является то, что он обходит пул буферов и вместо этого использует системный кеш Windows.
• Если вы поместите файлы в файловую систему, вы потеряете согласованность транзакций с записью базы данных. Вы также добавили накладные расходы на резервное копирование миллионов отдельных файлов, что может быть хлопотно.

Взвесьте «за» и «против» для Filestream и посмотрите, подходит ли он для вашего случая. В нашем случае мы выбрали другой маршрут и выбрали разделение базы данных, чтобы мы могли использовать частичное восстановление / частичное восстановление .

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

Если вы застряли на стандарте 2005 года (разделение - это выпуск Enterprise Edition) и у вас есть опция «только для чтения для истории», вы можете заняться этим по старинке.

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

Последний вариант (который мы рассматриваем для нашего блобера объемом 3 ТБ) - переместить данные файла в базу данных документов или в облачное хранилище (например, AmazonS3 , хранилище BLOB- объектов Azure ). Это действительно вызывает проблему согласованности транзакций, о которой я упоминал ранее, но снимает нагрузку с этих очень дорогих SQL-серверов.

попробуйте функцию FILESTREAM на сервере SQL,

FILESTREAM интегрирует ядро ​​СУБД SQL Server с файловой системой NTFS, сохраняя данные varbinary (max) для больших двоичных объектов (BLOB) в виде файлов в файловой системе.

хорошие статьи об этом

1. Введение в SQL Server FileStream
2. BLOB или не BLOB: хранение больших объектов в базе данных или файловой системе
3. Хранилище FILESTREAM в SQL Server 2008