Соображения, где хранить документы - на файловом сервере или в БД? - PullRequest
Новая
       28

Соображения, где хранить документы - на файловом сервере или в БД?

4 голосов
/ 04 февраля 2010

У меня есть дизайнерское решение, касающееся документов, загруженных на мой веб-сайт: я могу либо хранить их где-нибудь на своем файловом сервере, либо сохранять в виде BLOB-объектов в своей базе данных (MSSQL 2005). Если это имеет какое-либо значение для проектного решения, эти документы являются конфиденциальными и должны иметь определенную степень защиты.

Соображения, о которых я подумал:

  1. Хранение на файловом сервере приводит к HUUUUUUUGE количеству файлов, которые все выгружаются в один каталог, и, следовательно, к более медленному доступу, если я не могу выработать разумное семантическое определение для структуры дерева каталогов
  2. OTOH, я предполагаю, что файловый сервер может справиться со сжатием несколько лучше, чем с БД ... или я не прав?
  3. Мои инстинкты говорят мне, что безопасность БД сильнее, чем файлового сервера, но я не уверен, что это обязательно так.
  4. Не знаю, как терабайты больших двоичных объектов в моей БД повлияют на производительность.

Я бы очень признателен за некоторые рекомендации здесь. Спасибо!

Ответы [ 3 ]

7 голосов
/ 04 февраля 2010

В SQL Server 2005 у вас есть только выбор использования VARBINARY(MAX) для хранения файлов в таблице базы данных или для их хранения вне.

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

SQL Server 2008 вводит атрибут FILESTERAM для типов VARBINARY(MAX), который позволяет вам оставлять файлы вне таблицы базы данных, но все еще под транзакционным контролем базы данных - например, Вы не можете просто удалить файлы с диска, файлы являются неотъемлемой частью базы данных и, следовательно, копируются и сохраняются вместе с ней. Отлично, если вам это нужно, но это может привести к огромным резервным копиям! : -)

При запуске SQL Server 2008 были представлены «лучшие практики» в отношении того, когда хранить вещи в базе данных напрямую, а когда использовать FILESTREAM. Это:

  • если размер файлов обычно меньше 256 КБ, лучшим вариантом будет таблица базы данных
  • если размер файлов обычно превышает 1 МБ или может превышать 2 ГБ, тогда FILESTREAM (или в вашем случае: простая старая файловая система) - ваш лучший выбор
  • нет рекомендаций для файлов между этими двумя полями

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

Так что это может дать вам представление о том, с чего начать!

3 голосов
/ 04 февраля 2010

Я настоятельно рекомендую вам рассмотреть решение файловой системы. Причины:

  • у вас есть лучший доступ к файлам (очень ценно в случае отладки), что означает, что вы можете использовать обычные консольные инструменты
  • вы можете быстро и легко использовать преимущества ОС для распределения нагрузки, например, с помощью распределенной файловой системы, добавления избыточности через аппаратный RAID и т. Д.
  • вы можете воспользоваться списками контроля доступа ОС для обеспечения прав доступа.
  • Вы не засоряете свою базу данных

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

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt
1 голос
/ 04 февраля 2010

За этим популярным предметом МНОГО "зависит". Поскольку вы говорите, что документы деликатные и конфиденциальные, я бы не стал хранить их в базе данных. Вот несколько причин:

  • Потенциально лучшая безопасность. Часто проще взломать файловую систему, чем базу данных.
  • Лучше регулятор громкости. Тысячи файлов в одной папке могут перегружать операционную систему, где база данных может занять миллионы строк в одной таблице, не мигая.
  • Улучшен поиск и сканирование. Добавьте столбцы категоризации при загрузке данных или попробуйте выполнить полнотекстовое индексирование для сканирования фактических документов.
  • Резервное копирование может быть более эффективным - просто добавьте другую базу данных в свой план резервного копирования, и все будет в порядке (разумеется, после того, как вы проработаете детали пространства). И эти файлы резервных копий - еще один слой запутывания для любого, кто пытается получить доступ к вашим конфиденциальным документам.
  • SQL Server 2008 имеет параметры сжатия данных, которые могут помочь здесь. Это или приложение делает это? (Возможно, больше безопасности благодаря запутыванию)

SQL Server 2008 также имеет тип данных filestream, который может здесь помочь, но я недостаточно знаком с ним, чтобы дать рекомендацию для вашей ситуации.

...