хранение загруженных фотографий и документов - файловая система или блоб базы данных

Question

Моя конкретная ситуация

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

Для фотографий будут эскизы каждого.

Мой вопрос

Мой приоритет # 1 - производительность. Для конечного пользователя я хочу загрузить страницы и показать изображение как можно быстрее.

Должен ли я хранить изображения в базе данных или файловой системе, или это не имеет значения? Нужно ли что-то кэшировать?

Заранее спасибо!

Answer 1

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

Похоже, ваша бизнес-модель хорошо вписывается в этот сценарий.

Answer 2

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

Изменить на кеширование: Если вы хотите кэшировать файл, пока пользователь загружает его, чтобы гарантировать, что операция завершится как можно скорее, выгрузка его прямо на диск (то есть файловая система) происходит почти так же быстро, как и происходит. Пока файлы не слишком велики и у вас не слишком много одновременных пользователей, вы можете «кэшировать» файл в памяти, вернуться к пользователю, а затем сохранить на диск. Если честно, я бы не стал беспокоиться.

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

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

Answer 3

Определенно храните ваши изображения в файловой системе. Одна проблема, которую люди не считают достаточно, рассматривая эти типы вещей, является раздутой; встраивание изображений в виде двоичных объектов в вашу базу данных - это действительно быстрый способ увеличить вашу базу данных. Большая база данных сопровождается повышенными требованиями к оборудованию, более сложными требованиями к репликации и резервному копированию и т. Д. Размещение изображений в файловой системе означает, что вы можете легко и просто создавать резервные копии / реплицировать их с помощью многих существующих инструментов. Объем памяти гораздо проще увеличить в файловой системе, чем в базе данных.

Answer 4

Комментарий к ответу Шипи.

Обычно хранение файлов в SQL лучше, когда размер файла меньше 256 килобайт, и стоит, когда оно больше 1 мегабайта. Таким образом, между 256-1024 килобайтами это зависит от нескольких факторов. Прочитайте это , чтобы узнать больше о причинах использования SQL или файловых систем.

Answer 5

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

Answer 6

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

также, хороший веб-сервер внешнего интерфейса (например, nginx) работает намного быстрее, чем любой слой веб-приложения, который вам нужно написать, чтобы прочитать BLOB-объект из БД. в некоторых тестах nginx примерно наравне с memcached для обработки необработанных данных файлов среднего размера (например, больших HTML или изображений среднего размера).

иди ФС. нет конкурса.