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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt

Answer 3

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

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

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