[database] Хранение изображений в DB - Yea или Nay?


Answers

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

  • Вы сохраняете изображения, которые меняются динамически, скажите счета и вы хотите получить счет-фактуру, как это было 1 января 2007 года?
  • Правительство хочет, чтобы вы поддерживали 6-летнюю историю
  • Изображения, хранящиеся в базе данных, не требуют другой стратегии резервного копирования. Изображения, хранящиеся в файловой системе,
  • Легче контролировать доступ к изображениям, если они находятся в базе данных. Idle admins могут обращаться к любой папке на диске. Требуется действительно решительный администратор, чтобы отслеживать в базе данных, чтобы извлечь изображения

С другой стороны, есть проблемы, связанные с

  • Требовать дополнительный код для извлечения и потоковой передачи изображений
  • Задержка может быть медленнее, чем прямой доступ к файлам
  • Более тяжелая нагрузка на сервер базы данных
Question

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

Как вы думаете, какие плюсы и минусы?




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

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

Учитывая, что изображения представляют собой фактические данные, которые нужно искать, и что им легче управлять (изображения не будут внезапно исчезать) в одной интегрированной базе данных, вместо того, чтобы взаимодействовать с какой-то файловой системой (если файловая система имеет независимый доступ, изображения МОГУТ «внезапно исчезнуть»), я бы хотел хранить их непосредственно в виде BLOB или таких.




SQL Server 2008 предлагает решение, имеющее лучшее из обоих миров: Тип данных для фильтрации .

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




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

Когда-то общее решение этого - вывести их в сбалансированное дерево подкаталогов.




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

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

Похоже, что это было бы лучше разрешено с помощью промежуточного сценария, вытаскивающего данные из недоступного в сети хранилища файлов. Поэтому хранилище БД не является ДЕЙСТВИТЕЛЬНО необходимым.




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

+ VES:

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

-ves:

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

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




Это может быть немного длинным, но если вы используете (или планируете использовать) SQL Server 2008, я бы рекомендовал взглянуть на новый тип данных FileStream .

FileStream решает большинство проблем с хранением файлов в БД:

  1. Блоки фактически хранятся в виде файлов в папке.
  2. Доступ к блокам можно получить, используя либо подключение к базе данных, либо через файловую систему.
  3. Резервные копии интегрированы.
  4. Миграция «просто работает».

Однако SQL-шифрование «Прозрачное шифрование данных» не шифрует объекты FileStream, поэтому, если это необходимо, вам может быть лучше хранить их как varbinary.

Из статьи MSDN:

Операторы Transact-SQL могут вставлять, обновлять, запрашивать, искать и создавать резервные копии данных FILESTREAM. Интерфейсы файловой системы Win32 обеспечивают потоковый доступ к данным.
FILESTREAM использует системный кеш NT для кэширования данных файла. Это помогает уменьшить любое влияние, которое могут иметь данные FILESTREAM на производительность Database Engine. Пул буферов SQL Server не используется; поэтому эта память доступна для обработки запросов.




Если вы не используете SQL Server 2008, и у вас есть веские причины для размещения определенных файлов изображений в базе данных, вы можете использовать «оба» подхода и использовать файловую систему в качестве временного кеша и использовать базу данных в качестве основного хранилища ,

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




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

Как и большинство других вещей, это зависит от ожидаемого размера и бюджета.




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

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




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




Однажды я работал над приложением для обработки изображений. Мы сохранили загруженные изображения в каталоге, который был что-то вроде / images / [сегодняшняя дата] / [номер идентификатора]. Но мы также извлекли метаданные (exif-данные) из изображений и сохранили их в базе данных, а также временную метку и т. Д.




Если это веб-приложение, тогда могут быть преимущества для хранения изображений в сторонней сети доставки хранилища, такой как S3 Amazon или платформа Nirvanix.




Недавно я создал приложение PHP / MySQL, в котором хранятся файлы PDF / Word в таблице MySQL (до 40 МБ на файл).

Плюсы:

  • Загруженные файлы реплицируются на сервер резервного копирования вместе со всем остальным, не требуется отдельная стратегия резервного копирования (душевное спокойствие).
  • Настройка веб-сервера немного проще, потому что мне не нужно иметь папку uploads / folder и рассказывать обо всех моих приложениях, где они есть.
  • Я могу использовать транзакции для редактирования, чтобы улучшить целостность данных. Мне не нужно беспокоиться о потерянных и потерянных файлах

Минусы:

  • mysqldump теперь занимает время ожидания, так как в одной из таблиц содержится 500 Мбайт данных.
  • В целом, не очень эффективная память / процессор по сравнению с файловой системой

Я бы назвал свою реализацию успешной, она заботится о требованиях к резервному копированию и упрощает компоновку проекта. Производительность отлично подходит для 20-30 человек, которые используют приложение.




В тех местах, где вы ДОЛЖНЫ гарантировать ссылочную целостность и соответствие ACID, требуется хранение изображений в базе данных.

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




Related