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

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

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

Преимущества Databse

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

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

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

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

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

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

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

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

Рассматриваемая инфраструктура

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

Сводка

При чтении вокруг на большом количестве связанных потоков здесь на Так, многие люди теперь отклоняются к SQL Server тип Filestream. Из того, что я мог собраться однако (я могу быть неправым), нет большого преимущества, когда файлы являются довольно маленькими. Filestreaming однако надеется значительно улучшать производительность, когда файлы - несколько МБ или больше.

Поскольку мои фотографии профиля имеют тенденцию сидеть без дела ~5kb, я решил просто оставить их сохраненными в хранилище файлов в базе данных как varbinary (макс.).

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

Таким образом, я предполагаю, что пошел для гибрида;

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

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

17
задан marc_s 10 January 2018 в 17:10
поделиться

2 ответа

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

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

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

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

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

4
ответ дан 30 November 2019 в 14:41
поделиться

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

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

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

Flickr работает именно так.

Надеюсь, это поможет.

4
ответ дан 30 November 2019 в 14:41
поделиться
Другие вопросы по тегам:

Похожие вопросы: