Хранить файл в базе данных в отличие от файловой системы? - PullRequest
80 голосов
/ 12 августа 2008

Какое плохое влияние на производительность вызывает сохранение файла в базе данных (в частности, в mssql), а не в файловой системе? Я не могу придумать причину за пределами переносимости приложения, что я хотел бы сохранить свои файлы как varbinaries в SQL Server.

Ответы [ 10 ]

75 голосов
/ 12 августа 2008

Посмотрите на этот ответ:

Хранение изображений в БД - да или нет?

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

Есть несколько противоположных примеров (например, Microsoft Sharepoint), но обычно хранение файлов в базе данных не является хорошей идеей.

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

36 голосов
/ 12 августа 2008

Если вы можете перейти на SQL Server 2008, вы можете воспользоваться поддержкой FILESTREAM, которая дает вам лучшее из обоих - файлы хранятся в файловой системе, но интеграция с базой данных намного лучше, чем просто сохранение пути к файлу в Варчарское поле. Ваш запрос может вернуть стандартный поток файлов .NET, что значительно упрощает интеграцию.

Начало работы с хранилищем FILESTREAM

22 голосов
/ 12 августа 2008

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

6 голосов
/ 12 августа 2008

Что за вопрос здесь?

Современные СУБД SQL2008 имеют множество способов работы с BLOB, которые не просто помещаются в них в таблице. Конечно, есть плюсы и минусы, и вам, возможно, придется подумать об этом немного глубже.

Это интересная статья, к концу (?) Джим Грей

К BLOB или не К BLOB: хранение больших объектов в базе данных или файловой системе

3 голосов
/ 28 августа 2008

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

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

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

3 голосов
/ 12 августа 2008

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

2 голосов
/ 12 августа 2008

Мы приняли решение хранить как varbinary для http://www.freshlogicstudios.com/Products/Folders/, ожидая проблем с производительностью. Могу сказать, что мы были приятно удивлены тем, насколько хорошо это сработало.

1 голос
/ 12 августа 2008

Издержки, связанные с анализом большого двоичного объекта (изображения) в байтовом массиве и последующей записью его на диск с правильным именем файла и последующим чтением, достаточны для того, чтобы отговорить вас делать это слишком часто, особенно файлы довольно большие.

1 голос
/ 12 августа 2008

Я согласен с @ZombieSheep. Еще одна вещь - я вообще не думаю, что базы данных действительно должны быть переносимыми, потому что вы упускаете все функции, которые предоставляет ваш поставщик СУБД. Я думаю, что переход на другую базу данных будет последним, что нужно учитывать. Просто мои $ .02

0 голосов
/ 12 августа 2008

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

...