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

Question

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

1. Хранить файлы в формате BLOB в базе данных.

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

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

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

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

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

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

Answer 1

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

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

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

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

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

По поводу ваших вопросов:

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

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

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

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

Answer 2

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

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

Answer 3

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

Поскольку вы будете получать доступ к файлам непосредственно из SQL Server, а не из файловой системы, вам следует хранить их с использованием больших двоичных объектов.

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

Answer 4

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

Спецификация реализации библиотеки поставщика удаленного хранилища больших двоичных объектов

Блог группы SQL Remote Blob Storage

Answer 5

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

Answer 6

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

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

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

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