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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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

Answer 1

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

Этот подход более гибок и легче масштабируется.

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

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

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

Answer 2

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

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

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

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

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