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

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

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

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

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

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

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

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

  • любые другие преимущества?

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

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

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

Инфраструктура, о которой идет речь

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

Резюме

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

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

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

Итак, я думаю, я пошел на гибрид,

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

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

Ответы

Ответ 1

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

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

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

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

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

Ответ 2

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

Этот подход является более гибким и более простым в масштабировании.

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

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

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