Стратегия для обработки базы данных SQL Server со слишком большим количеством файлов (BLOB)?
Сценарий:
База данных SQL Server 2005, обслуживающая приложение ASP.NET (на отдельных веб-серверах).
База данных:
DB имеет около 5 ГБ «нормальных» данных в нем и около 15 ГБ «файлов» (например: 200 тыс. PDF, хранящихся в виде изображения (BLOB)). Больше файлов загружаются пользователями и быстро потребляют больше места на диске (в ближайшие несколько месяцев БД может вырасти до 50 ГБ, в основном файлы).
Озабоченность:
Хранение так много файлов в БД уже вызывает проблемы (например: большой общий размер базы данных затрудняет временные резервные копии и развертывания всего БД).
И мы обеспокоены тем, что будет больше проблем . (например, проблемы с производительностью - возможно, из-за невозможности сохранить всю БД в ОЗУ, возможно?)
Вопрос:
Какое техническое решение вы предложите этой проблеме? Хранить файлы в файловой системе? Разделить базу данных на две части и иметь большую, более медленную для файлов?
Дополнительная информация, если необходимо:
Эти файлы не очень важны и не требуют очень быстрого времени доступа - через пару секунд все будет в порядке, и в настоящее время может быть не более десятка выборок в час. Другие «нормальные» данные в БД включают информацию, необходимую много раз в секунду.
2 ответа
Я забочусь о очень похожей базе данных, в настоящее время 3 ТБ и растущей 5 ГБ в день.
- Filestream (2008+) не решает задачу резервного копирования и восстановления .
- Filestream работает лучше, чем LOB-хранилище для файлов> 1MB, так говорит Пол Испытания Рэндала . Это зависит от рабочей нагрузки при 256 КБ-1 МБ и, как правило, хуже при <256 КБ.
- Большим плюсом для Filestream в некоторых средах является то, что он обходит пул буферов и вместо этого использует системный кеш Windows.
- Если вы помещаете файлы в файловую систему, вы теряете последовательность транзакций с записью базы данных. Вы также добавили накладные расходы на резервное копирование миллионов отдельных файлов, что может быть проблематичным.
Взвесьте pro и con для Filestream и посмотрите, подходит ли это вашему делу. В нашем случае мы выбрали другой маршрут и решили разделить базу данных, чтобы мы могли использовать частичную доступность /поэтапное восстановление .
Один из вариантов, который у нас не был доступен, - это отметка старых /архивных файловых групп как доступная только для чтения. Постоянная файловая группа (-ы) для чтения может быть скопирована нечасто.
Если вы застряли в стандарте 2005 года (разделение - это функция Enterprise edition), и у вас есть возможность читать только для истории, вы можете решить этот старомодный способ.
- Разделите таблицу. Вы могли бы рассмотреть активный /исторический маршрут или дату, например. таблица в месяц.
- Поместите исторические данные в файловую группу только для чтения и создайте резервную копию только при архивировании дополнительных данных. Убедитесь, что ваши пользователи понимают, что это сокращает время резервного копирования. Восстановление может занять некоторое время, если у вас нет частичной доступности.
- Создайте секционированный вид поверх таблицы.
Один окончательный вариант (который мы рассматриваем для нашего 3TB blobber) заключается в перемещении данных файла в базу данных документа или облачное хранилище (например, AmazonS3 , Azure BLOB Storage ) , Это приводит к проблеме транзакционной согласованности, о которой я упоминал ранее, но она отнимает нагрузку от очень дорогостоящих SQL-серверов.
попробуйте FILESTREAM на сервере SQL,
FILESTREAM объединяет SQL Server Database Engine с файловой системой NTFS, сохраняя данные двоичного большого двоичного файла (BLOB) в формате varbinary (max) как файлы в файловой системе
приятные статьи об этом