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

Я создаю приложение asp.net MVC, в котором пользователи могут прикрепить изображение к своему профилю, а также в других областях системы, таких как гаджет обмена сообщениями на панели инструментов, который отображает последние сообщения и т. Д.

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

Преимущества базы данных

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

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

Преимущества файловой системы

  • загрузка файлов с диска, вероятно, быстрее

  • какие-нибудь другие преимущества?

Где другие сайты хранят такую ​​информацию? Правильно ли я, что немного беспокоюсь о производительности базы данных для чего-то вроде этого?

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

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

Соответствующая инфраструктура

  • Веб-сайт будет развернут в IIS на сервере Windows 2003 с файловой системой NTFS.
  • База данных будет SQL Server 2008

Резюме

Читая много связанных тем здесь, на SO, многие люди сейчас склоняются к типу потока файлов SQL Server. Однако из того, что я мог понять (я могу ошибаться), нет особой пользы, когда файлы довольно маленькие. Однако потоковая передача файлов значительно улучшает производительность, когда файлы имеют размер несколько МБ или больше.

Поскольку мои изображения в профиле обычно занимают около 5 КБ, я решил просто оставить их в хранилище файлов в базе данных как varbinary (max).

В ASP.NET MVC я заметил небольшую проблему с производительностью, возвращающую FileContentResults для изображений, извлеченных из базы данных, как это. Итак, я закончил кеширование файла на диске при его чтении, если местоположение этого файла не найдено в кеше моего приложения.

Думаю, я выбрал гибрид;

  • Хранение базы данных для упрощения записи данных, а файлы связаны напрямую с профилями
  • Теневое копирование на диск для лучшего кэширования

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


person Joshua Hayes    schedule 21.07.2010    source источник
comment
Вы должны прочитать это: http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay   -  person Anders    schedule 22.07.2010
comment
Извините, что в моем вопросе допущено несколько опечаток. Набираю это с моего iPhone. Буду редактировать, когда доберусь до пк.   -  person Joshua Hayes    schedule 22.07.2010
comment
Спасибо, Андерс, это именно то, что я искал. Множество просмотров и мнений в той цепочке, которую вы связали.   -  person Joshua Hayes    schedule 22.07.2010


Ответы (2)


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

reiserfs (устаревший) действительно хорош для поиска, zfs, xfs и NTFS имеют фантастические алгоритмы хеширования, linux ext4 тоже выглядит многообещающим.

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

Необходимо учитывать несколько вещей, включая попадание в сеть, попадание при обработке, возможность распространения и т. Д. Если вы храните данные в базе данных, вы можете их перемещать. Опять же, если вы храните изображения в службе доставки контента, это может быть НАМНОГО быстрее, поскольку вы не делаете никаких сетевых обращений к себе.

Подумайте об этом и помните, что небольшой сравнительный анализ никогда никому не повредит :-), поэтому проверьте его с вашим типичным размером набора данных и примите во внимание такие вещи, как одновременные запросы и т. Д.

person Elf King    schedule 21.07.2010
comment
Привет, король эльфов. Вы хорошо отметили инфраструктуру, я обновил свой вопрос. Хотя я понимаю, что необходимо учитывать множество факторов (как вы указали), я ищу некоторые информированные мнения /, возможно, некоторый опыт людей, которые пробовали тот или иной путь, и то, как это сработало. - person Joshua Hayes; 22.07.2010
comment
Что ж, я успешно сделал и то, и другое в производственных средах для больших проектов. В одном проекте система создавала около 10 изображений по 10 МБ каждую секунду каждый день, и все их нужно было отсортировать и связать с несколькими пользователями. (Использовал там комбинацию ФС и БД). Здесь из-за высокой скорости производства пришлось использовать распределенные FS. В других случаях изображения были большими, но статичными, там использовались капли БД. Я думаю, что для вашего приложения вам может быть лучше просто DB. Возможно, вам также придется рассмотреть вопрос о законности того, кому принадлежит цифровое изображение. - person Elf King; 22.07.2010

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

Этот подход более гибкий и его легче масштабировать.

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

Так работает Flickr.

Я дал более подробный ответ здесь, он может оказаться полезным.

person Frankie    schedule 10.08.2010
comment
Потрясающий. Я пытался найти хороший способ сохранить изображение профиля на своем веб-сайте, я тоже собираюсь использовать это решение - person Jon Koivula; 06.08.2015
comment
@JonKoivula У меня есть еще один ответ, в котором подробно рассказывается. Это может быть полезно. stackoverflow.com/questions/8922056/ - person Frankie; 07.08.2015
comment
Вау, большое спасибо, Фрэнки, ты действительно дал мне полезный ответ. Я очень это ценю. - person Jon Koivula; 07.08.2015