Лучшая стратегия хранения документов в SQL Server 2008

Одна из наших команд будет разрабатывать приложение для хранения записей в базе данных SQL2008, и каждая из этих записей будет иметь связанный файл PDF. В настоящее время около 340 ГБ файлов, причем большинство (70%) составляют около 100 тыс., Но некоторые из них имеют размер в несколько мегабайт. Данные в основном вставляются и читаются, но файлы иногда обновляются. Мы обсуждаем следующие варианты:

  • Храните файлы в виде BLOB в базе данных.

  • Храните файлы за пределами базы данных и сохраняйте пути в базе данных.

  • Используйте функцию фильтрации файлов SQL2008 для хранения файлов.

Мы прочитали лучшие практики Micrsoft в отношении данных потока, но поскольку файлы различаются по размеру, мы не знаем, какой путь выбрать. Мы склоняемся к варианту 3 (filestream), но имеем несколько вопросов:

  • Какую архитектуру вы бы выбрали, учитывая количество данных и размер файлов, отмеченных выше?

  • Доступ к данным будет осуществляться с использованием проверки подлинности SQL, а не проверки подлинности Windows, и веб-сервер, скорее всего, не сможет получить доступ к файлам с помощью Windows API. Будет ли это делать поток потока хуже, чем два других варианта?

  • Так как резервные копии SQL включают данные потока, это приведет к очень большому резервному копированию базы данных. Как другие обрабатывают базы данных с большим количеством данных для фильтрации?

Ответы

Ответ 1

Хорошо, здесь мы идем. Вариант 2 - это действительно плохая идея - вы получаете непроверяемые ограничения целостности и резервные копии, которые не гарантируют согласованности для каждого определения, потому что вы не можете использовать резервные копии времени. Не проблема в сценариях MOST, она превращается в один момент, когда у вас есть более сложный (момент времени).

Варианты 1 и 3 довольно равны, хотя и с некоторыми последствиями.

  • Filestream может использовать намного больше дискового пространства. В принципе, каждая версия имеет руководство, если вы делаете обновления, старые файлы остаются до следующей резервной копии.

  • OTOH файлы не учитываются как размер db (экспресс-выпуск - не против ограничения 10gb, если вы его используете), и доступ к нему еще возможен, используя общий ресурс файла. Это добавляет гибкость.

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

Относительно ваших вопросов:

1: Я бы пошел в хранилище базы данных. Попробуйте оба - filestream и нет. Поскольку вы используете тот же API в любом случае, это простое изменение в определении таблицы.

2: Да, хуже прямого доступа к файлам, но он будет более защищен, чем прямой доступ к файлам. В противном случае я не думаю, что поток и blob имеют существенную разницу.

3: где у вас есть огромная резервная копия? Извините, но спросите, но ваш 340gb - это не совсем большая база данных. И вам нужно поддержать его в любое время. Лучше сделайте это в одном согласованном состоянии, чего вы достигнете при хранении db. Плюс целостность (никто не случайно удаляет неиспользуемые документы без очистки базы данных). БД не намного больше, чем выполнение этого разделения, и это простая резервная копия одного места.

В конце концов, вопрос заключается в целостности и простоте резервного копирования. Выиграйте для SQL Server, если вы не получите большой - и это означает, что 360 терабайт данных.

Ответ 2

Храните файлы за пределами базы данных и сохраняйте пути в базе данных.

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

Ответ 3

Я бы определенно рекомендовал (3) - это сценарий, который эта функция специально построена для обработки, и, на мой взгляд, она очень хорошо справляется.

В этом техническом документе есть много полезной информации - http://msdn.microsoft.com/en-us/library/cc949109(SQL.100).aspx - и с точки зрения безопасности упоминает, что...

Существует два требования безопасности для использования функции FILESTREAM. Во-первых, SQL Server должен быть настроен для интегрированной безопасности. Во-вторых, если будет использоваться удаленный доступ, то SMB-порт (445) должен быть включен через любые системы брандмауэра.

Что касается резервных копий, см. принятый ответ на этот вопрос - Ограничение FILESTREAM SQL Server

Ответ 4

Я использовал метод Index/Content, который вы не указали, но может помочь. У вас есть таблица файлов, которые хранятся в виде блока двоичного кода с уникальным номером id или строки. Следующая таблица SQL предоставит индекс, имя файла, путь к нему, ключевые слова, тип файла, размер файла, контрольную сумму... что вам нужно. Это лучшее, что я видел, чтобы хранить файлы для работы с тысячами загруженных документов. Индекс необходим для просмотра файла, поскольку он будет просто двоичным текстом для пользователя, если они не имеют представления о типе файла. Мы сохраняем данные в двух отдельных базах данных, чтобы можно было легко индексировать один сервер и хранилище файлов на нескольких серверах. В этот момент индексная таблица/база данных содержит имя или ключ к серверу, на котором находится файл. Если у пользователя есть доступ к чтению этой конкретной индексной таблицы, они имеют доступ к файлу.

Ответ 5

Вы посмотрели решение RBS (Remote Blob Storage)? Если вы используете провайдер Filestream RBS, он будет внутренне сохранять ваши капли в виде файлов Filestream или значений varbinary (max), в зависимости от того, что улучшает производительность на основе размера blob.

Спецификация реализации библиотеки поставщика BLOB-хранилища

SQL Remote Blob Storage Team Blog

Ответ 6

Этот сценарий прост: рекомендация FILESTREAM говорит, что лучше всего, когда файлы (в среднем) больше 1 МБ, что не является вашим случаем, для небольших объектов хранение двоичных (макс.) BLOB в базе данных часто обеспечивает лучшую поточную передачу представление.

Поскольку вы будете обращаться к файлам непосредственно с SQL Server, а не из файловой системы, тогда вы должны хранить их с помощью BLOB.

Прочтите, когда использовать FILESTREAM: http://technet.microsoft.com/en-us/library/bb933993%28v=sql.105%29.aspx