Хранить изображения в виде файлов или в базе данных для веб-приложения?


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

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

большое спасибо, Стефан

дублировать: хранение изображений в БД - да или нет?,как хранить изображения в вашей файловой системе,хранение небольшого количества изображений: blob или fs? и, возможно, некоторые другие.


комментарий: Спасибо за много хороших ответов. Я пойду на файловое решение, даже если мне нравится идея иметь 100% - ное решение, управляемое базой данных. Похоже, что нет сегодня хороших решений, чтобы делать то, что я хочу с базами данных и т. д., Но у меня есть несколько причин не делать оно.

  • Я буду на это решение, у меня огромное количество памяти(10 Гб), но только 300 МБ для базы данных. Это будет стоить много для дополнительного хранения в БД.

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

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

10 114

10 ответов:

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

Почему? Потому что...

  1. вы сможете служить фотографии в качестве статических файлов.
  2. для получения изображений не требуется доступ к базе данных или код приложения.
  3. изображения могут быть поданы с другого сервера для повышения производительности.
  4. это уменьшит узкое место базы данных.
  5. база данных в конечном счете хранит свои данные в файловой системе.
  6. изображения могут быть легко кэшируется при хранении в файловой системе.

в моих недавно разработанных проектах я хранил изображения (и все виды двоичных документов) в виде столбцов изображений в таблицах базы данных.

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

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

пословица Всегда была "файлы в файловой системе, метаданные файла в базе данных"

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

при обслуживании Images

Я нашел этот ответ из Google ваш вопрос и читать комментарии на http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html

Мне обычно нравится иметь двоичные файлы в базе данных, потому что:

  • целостность данных: нет неиспользуемого файла, нет пути в БД без какого-либо файла, связанного
  • согласованность данных: возьмите дамп базы данных, и это все. нет " O я забыл targz этот каталог данных."

хранение изображений в базе данных добавляет накладные расходы БД для обслуживания отдельных изображений и затрудняет разгрузку в альтернативное хранилище (S3, Akami), если вы дорастете до этого уровня. Хранение их в базе данных значительно упрощает перемещение приложения на другой сервер, так как это только БД, что нужно действовать.

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

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

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

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

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

Почему бы не выбрать отдельную базу данных NoSql для хранения файлов.

Он приносит вам целостность данных, согласованность данных, как упоминалось в @chburd.

в то время как вы РСУБД по-прежнему держать небольшой.

  1. вот пошаговый пример (общий подход, Весенняя реализация,Eclipse) хранения изображений в файловой системе и хранения их метаданных в БД -- http://www.devmanuals.com/tutorials/java/spring/spring3/mvc/Spring3MVCImageUpload.html
  2. вот пример тоже -- http://www.journaldev.com/2573/spring-mvc-file-upload-example-tutorial-single-and-multiple-files
  3. Также вы можете изучить тексты этой проект -- https://github.com/jdmr/fileUpload . Обратите внимание на этой контроллер.