ASP.NET местоположение хранилища загрузки изображения MVC (дб по сравнению с файловой системой)
Я пишу веб-приложение с помощью стека ASP.NET MVC + NHibernate + Postres. Интересно, должны ли загруженные изображения быть сохранены в базе данных как двоичные блобы или в файловой системе (и ссылка только в дб). Одним преимуществом устройства хранения данных дб, о котором я могу думать, является легкое резервное копирование/восстановление всех данных, не возвращаясь к инструментам копии файловой системы. С другой стороны, я подозреваю, что доступ к файловой системе может быть быстрее (но это особенно при контакте со многими параллельными запросами?), Каковы Ваши предложения?
3 ответа
Я бы сделал и то, и другое - обеспечил хранение изображений в базе данных, чтобы все данные были централизованы для легкого резервного копирования, но кэшировал данные и снаружи, чтобы повторяющиеся запросы больших изображений не разрушали буферный кэш базы данных. При правильном подходе вы можете внедрить новые внешние веб-серверы, которые после запуска будут прозрачно заполнять свой локальный кэш изображений из базы данных.
Наличие централизованного хранилища для изображений также полезно для обеспечения отправки хороших заголовков Last-Modified и ETag HTTP-ответов для изображений в системе с несколькими веб-серверами, поскольку эти заголовки могут быть сделаны из содержимого базы данных, а не взяты из локальных объектов кэша.
Небольшое замечание по реализации конкретно для PostgreSQL: вы можете установить "режим хранения" столбца, содержащего данные изображения, на "внешний": это остановит попытки PostgreSQL сжать данные изображения (используя zlib, что вряд ли принесет пользу) и заставит хранить данные изображения во вспомогательной таблице TOAST, обеспечивая лучшую производительность, если вы просто запрашиваете метаданные изображения. См. пункт "SET STORAGE" команды ALTER TABLE, например:
ALTER TABLE media.image ALTER COLUMN content SET STORAGE EXTERNAL
Мы используем хранилище оригиналов в базе данных для резервного копирования, но сгенерировали уменьшенные изображения, которые кэшируются в файловой системе на веб-серверах.
Однако мы стараемся по возможности избегать любых обращений к базе данных, потому что это создает огромную нагрузку, поскольку одна страница обычно вызывает несколько запросов изображения на просмотр страницы.
Одно замечание о хранении больших двоичных объектов в базе данных. Я предлагаю вам хранить фактические столбцы больших двоичных объектов в специальной таблице с однозначным отображением на вашу сущность / сущности. Это упростит резервное копирование, а также изменение ваших таблиц. Когда таблица становится большой, любые изменения будут длиться вечно, и блокировка становится большой проблемой даже во время резервного копирования.
Если у вас есть вся информация об изображениях (кроме двоичных данных), выбор этих данных не будет затронут, если вам не понадобятся двоичные данные (которые вам редко нужны, поскольку они будут кэшироваться в файловой системе).
Всего два цента.
Это зависит от обстоятельств. Цените ли вы возможность напрямую ссылаться на изображение или вы хотите всегда использовать ресурсы на стороне сервера для вызова БД, а затем записывать двоичные данные для изображения?