Хранить документы / видео в базе данных или как отдельные файлы?

Question

Лучше ли хранить медиафайлы (документы, видео, изображения и, в конечном итоге, исполняемые файлы) в самой базе данных, или мне просто добавить ссылку на них в базу данных и сохранить их как отдельные файлы?

Answer 1

Чтение этого документа от MS исследования (в BLOB или не в BLOB) - в нем подробно рассматривается вопрос.

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

Answer 2

Два требования определяют ответ на ваш вопрос:

1. Существует ли более одного сервера приложений, считывающего двоичные файлы с сервера базы данных?
2. Есть ли у вас соединение с базой данных, которое может передавать двоичные файлы для записи и чтения?

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

Потоковая передача важна для того, чтобы при чтении или записи файл не полностью находился в памяти сервера (похоже, ответ @ Эндрю о SQL Server 2008 FILESTREAM может говорить об этом). Представьте себе файл размером в несколько гигабайт - если его полностью прочитать в память - этого будет достаточно для сбоя многих серверов приложений, которые просто не имеют физической памяти для размещения. Если у вас нет потоковых соединений с базой данных, хранение в базе данных действительно нежизнеспособно, если только вы не ограничите размер файла таким образом, чтобы программное обеспечение сервера приложений выделило как минимум столько же памяти, сколько максимальный размер файла * количество соединений для обслуживания запросов + некоторые дополнительные накладные расходы.

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

Answer 3

Это интересный документ, на который ссылается Одед - если вы используете Sql Server 2008 с его функцией FileStream , вывод такой же. Я процитировал несколько важных моментов из связанного документа FileStream:

«Хранилище FILESTREAM подходит не во всех случаях. Исходя из предыдущих исследований и поведения функции FILESTREAM, данные BLOB размером 1 МБ и более, к которым не будет доступа через Transact-SQL, лучше всего подходят для хранения в качестве данных FILESTREAM».

«Необходимо также учитывать рабочую нагрузку обновления, поскольку любое частичное обновление файла FILESTREAM создает полную копию файла. При особенно большой рабочей нагрузке обновления производительность может быть такой, что FILESTREAM не подходит»

Answer 4

Вот подробное сравнение, которое я сделал http://akashkava.com/blog/127/huge-file-storage-in-database-instead-of-file-system/

Answer 5

Хранение BLOB-данных в базе данных не считается правильным способом, если только они не очень малы.Вместо хранения их путь более уместен.это значительно улучшит производительность запросов и поиска в базе данных.