Хранение изображений в БД - да или нет?

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

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

Ответов (25)

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

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

Есть пара проблем:

  • хранение базы данных обычно дороже, чем хранение файловой системы
  • вы можете супер-ускорять доступ к файловой системе с помощью стандартных готовых продуктов
    • например, многие веб-серверы используют системный вызов sendfile () операционной системы для асинхронной отправки файла непосредственно из файловой системы в сетевой интерфейс. Изображения, хранящиеся в базе данных, не получают выгоды от этой оптимизации.
  • такие вещи, как веб-серверы и т. д., не требуют специального кодирования или обработки для доступа к изображениям в файловой системе.
  • базы данных выигрывают там, где важна целостность транзакций между изображением и метаданными.
    • сложнее управлять целостностью между метаданными БД и данными файловой системы
    • трудно (в контексте веб-приложения) гарантировать, что данные были сброшены на диск в файловой системе

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

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

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

Файловая система, конечно. Затем вы можете использовать все функции ОС для работы с этими изображениями - резервные копии, веб-сервер, даже просто сценарии пакетных изменений с использованием таких инструментов, как imagemagic. Если вы храните их в БД, вам нужно будет написать свой собственный код для решения этих проблем.

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

Если у вас есть небольшое, однопользовательское, потребительское приложение, я бы сказал DB. У меня есть приложение для управления DVD, которое использует файловую систему (в том числе Program Files), и это PIA для резервного копирования. Я хочу КАЖДЫЙ раз, чтобы они хранили их в базе данных, и позволяю мне выбирать, где сохранить этот файл.

Для более крупного коммерческого приложения я бы начал менять свое мышление. Раньше я работал в компании, которая разработала приложение для управления информацией окружных клерков. Мы будем хранить изображения на диске в закодированном формате [для решения проблем FS с большим количеством файлов] на основе присвоенного округом номера инструмента. Это было полезно с другой стороны, поскольку изображение могло существовать до записи БД (из-за их рабочего процесса).

Как и в большинстве случаев: «Это зависит от того, что вы делаете»

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

База данных для данных

Файловая система для файлов

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

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

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

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

  • Переместите свои образы на другой раздел или сервер, просто обновив глобальную конфигурацию.
  • Найдите запись, соответствующую изображению, выполнив поиск по ее первичному ключу.
  • Ваши изображения доступны для инструментов обработки, таких как imagemagick.
  • В веб-приложениях ваши изображения могут обрабатываться вашим веб-сервером напрямую (с сохранением обработки).
  • Инструменты CMS и веб-языки, такие как Coldfusion, могут обрабатывать загрузку изначально.

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

У меня было приложение с множеством маленьких миниатюр (по 2Кб каждая). Когда я помещал их в файловую систему, каждый из них потреблял 8 КБ из-за размера блока файловой системы. Увеличение площади на 400%!

См. Этот пост для получения дополнительной информации о размере блока: Каков размер блока файловой системы iphone?

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

Small static images (not more than a couple of megs) that are not frequently edited, should be stored in the database. This method has several benefits including easier portability (images are transferred with the database), easier backup/restore (images are backed up with the database) and better scalability (a file system folder with thousands of little thumbnail files sounds like a scalability nightmare to me).

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

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

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

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

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

Из статьи MSDN:

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

Файловое хранилище. Инженеры Facebook здорово поговорили об этом. Один вывод заключался в том, чтобы знать практический предел количества файлов в каталоге.

Игла в стоге сена: эффективное хранение миллиардов фотографий

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

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

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

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

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

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

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

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

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

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

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

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

Здесь следует отметить, что никто из профессионалов в области файловых систем не указал конкретную файловую систему. Означает ли это, что все, от FAT16 до ZFS, легко превосходит любую базу данных?

Нет.

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

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

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

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

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

Вот интересный технический документ по этой теме.

В BLOB или нет: хранилище больших объектов в базе данных или файловой системе

Ответ: «Это зависит от обстоятельств». Конечно, это будет зависеть от сервера базы данных и его подхода к хранилищу BLOB-объектов. Это также зависит от типа данных, хранящихся в больших двоичных объектах, а также от способа доступа к этим данным.

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

Вот еще один момент, о котором следует помнить. Одной из причин, поддерживающих использование базы данных для хранения больших двоичных объектов, является соответствие ACID. Однако подход, который тестировщики использовали в техническом документе (опция SQL Server с массовым протоколированием), который удвоил пропускную способность SQL Server, фактически изменил букву D в ACID на d, поскольку данные большого двоичного объекта не регистрировались с помощью начальная запись для транзакции. Поэтому, если полное соответствие ACID является важным требованием для вашей системы, уменьшите вдвое показатели пропускной способности SQL Server для записи в базу данных при сравнении файлового ввода-вывода с вводом-выводом больших двоичных объектов базы данных.

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

Еще одним преимуществом подхода к файловой системе является возможность выполнять некоторые необычные вещи, например, вы можете использовать Amazon S3 в качестве основного хранилища (сохранять URL-адрес в базе данных вместо пути к файлу). В случае сбоя в работе S3 вы возвращаетесь к файловому серверу (это может быть другая запись в базе данных, содержащая путь к файлу). Немного вуду для Apache или любого другого веб-сервера, который вы используете.

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

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

Я работал со многими системами цифрового хранения, и все они хранят цифровые объекты в файловой системе. Они, как правило, используют подход ветвления, поэтому в файловой системе будет дерево архивов, часто начиная с года записи, например, 2009, подкаталог будет месяц, например, 8 для августа, следующий каталог будет днем, например, 11, и иногда они будут использовать час, тогда файлу будет присвоено имя с постоянным идентификатором записи. Использование BLOBS имеет свои преимущества, и я слышал о его частом использовании в ИТ-подразделениях химической промышленности для хранения тысяч или миллионов фотографий и диаграмм. Он может обеспечить более детальную безопасность, единый метод резервного копирования, потенциально лучшую целостность данных и улучшенный поиск между носителями. Oracle имеет для этого множество функций в пакете, который они использовали для вызова Intermedia (я думаю, что сейчас это называется как-то иначе). Файловая система также может иметь детализированную защиту, обеспечиваемую с помощью такой системы, как XACML или другой объект защиты типа XML. Примеры см. В разделе D Пространство хранилища объектов Fedora.

Если вы используете Teradata, то в Teradata Developer Exchange есть подробная статья о загрузке и получении больших и больших двоичных объектов ..

http://developer.teradata.com/applications/articles/large-objects-part-1-loading