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

83

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

Кейд
источник

Ответы:

77

Взгляните на этот ответ:

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

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

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

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

Майкл Штум
источник
36

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

Начало работы с FILESTREAM Storage

Джон Гэллоуэй
источник
1
У меня здесь некоторые оговорки. В частности, аспекты масштабируемости и доступности: как вы контролируете, где хранятся эти «капли»?
Дэйв Ван ден Эйнде,
3
Масштабируемость и доступность, кажется, были достаточно хорошо продуманы - см. Этот технический документ: msdn.microsoft.com/en-us/library/cc949109.aspx
Джон Галлоуэй
2
Одно предостережение: при подключении к базе данных необходимо использовать встроенную систему безопасности (например, проверку подлинности Windows): blogs.msdn.com/b/psssql/archive/2008/04/10/…
Свен Гросен,
22

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

Лэнс Фишер
источник
6

В чем вопрос?

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

Это интересная статья покойного (?) Джима Грея.

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

Уилл Дин
источник
3

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

ЗомбиОвца
источник
3

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

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

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

Маркус Даунинг
источник
Что вы считаете большим или маленьким файлом?
ubiquibacon
2

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

Шон Миллер
источник
1

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

martinsb
источник
1

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

Джон Лимджап
источник
1
Я нигде не упоминаю, что этот «файл» нужно записать на диск и прочитать заново.
Дэйв Ван ден Эйнде,
Это неявная задача, когда изображения должны отображаться позже, особенно когда они хранятся в разных форматах или в сценариях, где они не могут храниться в памяти в течение длительных периодов времени из-за огромного размера.
Джон Лимджап,
0

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

N8g
источник