Изображения в базе данных по сравнению с файловой системой

Этот вопрос возникает часто - см. этот результат поиска SO.

Нет однозначного ответа - все зависит от обстоятельств.

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

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

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

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

Что ж, если две ваши главные потребности - целостность и репликация, то ответ определенно - БД.

Вы также можете сказать о другом:

• Целостность - БД, поэтому существуют базы данных по сравнению с плоскими файловыми системами.

• Репликация - Не уверен, что вы имеете в виду репликацию образов, но если это так, то, очевидно, БД, поскольку вы, конечно, не будете балансировать нагрузку.

• Из изображения БД можно получить несколько разрешений, однако это увеличивает затраты на обработку. Кроме того, чем выше разрешение, тем больше размер, тем дольше сеть ждет. Множественные разрешения обменивают пространство на скорость.

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

• Накладные расходы - Откровенно говоря, это зависит от вашего определения накладных расходов и того, как вы получаете доступ к изображениям.

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

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

Обратные стороны файловой системы

-Не реплицируется автоматически

-Может усложнить вашу репликацию из-за наличия разных физических местоположений для каждого экземпляра

-Медленно с очень большим количеством файлов

Вверх по отношению к файловой системе

-Если вы храните несколько очень больших файлов, он будет работать немного лучше.

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

Встроенное хранилище / хранилище больших двоичных объектов

Плюс : упрощает архитектуру и реализацию, упрощает резервное копирование и восстановление или миграцию системы; просто сделайте дамп, резервную копию, экспорт (независимо от того, какой термин используется для вашего вкуса БД) и переместите его в новую базу данных. Контроль версий / согласованность осуществляется БД, что позволяет выполнять восстановление на определенный момент времени. Безопасность / контроль доступа также более понятны, поскольку доступ к BLOB-объекту изображения является неотъемлемой частью доступа ко всей строке. При перемещении изображения за пределы БД и разрешении HTTP-серверу загружать его, хотя это лучше для параллелизма и масштабируемости, могут возникнуть проблемы с обеспечением того, чтобы люди не могли взломать URL-адреса и запросить изображения, которыми они не владеют. Если вы размещаете их за пределами БД, убедитесь, что ваша политика безопасности охватывает управление доступом к изображениям между пользователями. Либо ваша аутентификация HTTP-сервера должна интегрироваться с аутентификацией всей системы, либо ваша программа HTTP-сервера, которая обслуживает изображения, использует какой-то механизм сеанса, чтобы гарантировать, что HTTP-запрос действителен. Это очень большая проблема для мультитенантных баз данных. Меньше проблем в одноцелевых, однотенантных системах с простой аутентификацией.

Обратной стороной : для действительно ДЕЙСТВИТЕЛЬНО больших баз данных резервное копирование и восстановление становится неприятным или даже проблематичным и дорогостоящим, потому что там, где у вас может быть небольшой базовый набор данных, в противном случае у вас может быть много ГБ или ТБ данных изображений. Рассмотрение всего этого как одной согласованной базы данных хорошо с точки зрения целостности, но плохо для резервного копирования, если вы не используете СУБД корпоративного качества, резервное копирование и восстановление с настройками хранилища данных (например, Oracle RMAN и скользящее резервное копирование).

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

Microsoft Research опубликовала интересную исследовательскую работу под названием To Blob or not to Blob , в которой они рассмотрели всевозможные переменные и воздействия.

В итоге они пришли к выводу:

• размером до 256 КБ большие двоичные объекты хранятся в базе данных более эффективно, чем в файловой системе
• , при размере 1 МБ и более файловая система более эффективна
• между ними - подбрасывание

. С тех пор, как эта статья была опубликована, SQL Server 2008 также добавил атрибут FILESTREAM, который делает хранение данных в файловой системе, но под транзакционным контролем, реальностью. Настоятельно рекомендую вам это проверить!

Я бы хотел;

1) Назначьте уникальный идентификатор (GUID) каждому изображению 2) Отметьте / назовите изображение с этим GUID 3) Сохраните GUID в ОС (файловая система) 4) Сохраните указатель полного имени файла (FQN) в базе данных.

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

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

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

Несколько моментов, почему вам следует рассмотреть файловую систему

1. Браузер выполняет всю работу, и вы получаете выгоду от прокси-кеширования изображений и т. Д.
2. Как ответвление выше, вы можете легко использовать сети доставки контента (CDN)
3. Репликация данных изображений упрощается с помощью таких инструментов, как rsync и т. д.
4. Время обработки (т.е. CPU) значительно оптимизировано

Я бы не стал хранить изображения в базе данных по одной причине (мой ответ исходит от sql server):

Я не хочу, чтобы кэш данных SQL-сервера заполнялся простыми изображениями для веб-сайта. Я хочу, чтобы в кэше данных действительно были данные. Кроме того, если у вас многоуровневая архитектура, гораздо проще передать URL-адрес изображения, чем сгусток двоичных данных. Однако если вы хотите, чтобы изображения видели только определенные люди (безопасность), вы столкнетесь с проблемами.

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

• Целостность данных
• Репликация данных
• Множественные разрешения
• Управление данными и резервное копирование

Эти проблемы (вероятно) говорят в пользу хранения документов в файловой системе:

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

Итак, решите, что важнее всего, и выбирайте соответственно.