Стратегія обробляти БД SQL Server із занадто великою кількістю файлів (BLOB)?

Сценарій:
база даних SQL Server 2005, що обслуговує додаток ASP.NET (на окремих веб-серверах).

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

Побоювання:
Зберігання такої кількості файлів у БД вже викликає проблеми (наприклад: Великий загальний розмір бази даних ускладнює періодичні резервні копії та розгортання БД.).

І ми переживаємо, що буде більше проблем . (наприклад: проблеми з продуктивністю - можливо, спричинені тим, що неможливо зберегти весь БД в оперативній пам'яті, можливо?)

Питання:
Яке технічне рішення ви б запропонували у цій проблемі? Зберігати файли у файловій системі? Розподіліть базу даних на два і матимете більшу, повільну для файлів?

Подальші подробиці, якщо знадобляться:
ці файли не надто важливі та не потребують дуже швидкого часу доступу - пару секунд було б чудово, а наразі, мабуть, десяток вибору в годину. Інші "звичайні" дані в БД включають інформацію, необхідну багато разів на секунду.

Я доглядаю за дуже подібною базою даних, наразі 3 ТБ і зростаючою 5 ГБ на день.

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

Зважте свої плюси та мінуси для Filestream і подивіться, чи він відповідає вашому випадку. У нашому випадку ми взяли інший маршрут та обрали розділ бази даних, щоб ми могли скористатися частковою доступністю / відновленням на частини .

Один з недоступних нам варіантів, який, можливо, є, - позначити старі / архівні групи файлів як лише для читання. Потім файли групи, доступні лише для читання, можуть нечасто створювати резервні копії.

Якщо ви затрималися на стандарті 2005 року (розділ є функцією Enterprise Edition) і у вас є можливість лише для читання для історії, ви можете вирішити це старомодно.

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

Одним із останніх варіантів (який ми розглядаємо для нашого блоку 3TB) є переміщення даних файлів у базу даних документів або хмарне сховище (наприклад, AmazonS3 , Azure BLOB Storage ). Це вводить проблему узгодженості транзакцій, про яку я згадував раніше, але це знімає навантаження з тих дуже дорогих серверів SQL.

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

FILESTREAM інтегрує двигун бази даних SQL Server з файловою системою NTFS, зберігаючи варбінарні (макс.) Бінарні великі об'єкти (BLOB) дані у вигляді файлів у файловій системі

приємні статті про це

1. Вступ до FileStream SQL Server
2. Для BLOB чи не для BLOB: велике сховище об’єктів у базі даних або файловій системі
3. Зберігання FILESTREAM в SQL Server 2008