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

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

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

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

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

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

Я лично храню большие данные вне базы данных.

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

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

Как и многое другое, это зависит от ожидаемого размера и бюджета.

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

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

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

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

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

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

В компании, где я работал, мы хранили 155 миллионов изображений в базе данных Oracle 8i (затем 9i). Стоит 7,5 ТБ.

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

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

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

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

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

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

Из статьи MSDN:

Transact-SQL statements can insert, update, query, search, and back up FILESTREAM data. Win32 file system interfaces provide streaming access to the data.
FILESTREAM uses the NT system cache for caching file data. This helps reduce any effect that FILESTREAM data might have on Database Engine performance. The SQL Server buffer pool is not used; therefore, this memory is available for query processing.

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

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

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

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

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

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

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

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

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

Это также упрощает развертывание / обновления при выпуске новых карточек, вместо того, чтобы заархивировать всю папку с изображениями и отправить их по конвейеру и обеспечить создание надлежащей структуры папок, я просто обновляю базу данных и прошу пользователя снова загрузить ее. В настоящее время он имеет размер до 56 МБ, что не очень хорошо, но я работаю над функцией инкрементного обновления для будущих выпусков. Кроме того, существует версия приложения «без изображений», которая позволяет пользователям, подключенным к телефонной линии, получить приложение без задержки загрузки.

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

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

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

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

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

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

• Резервное копирование и восстановление. Как синхронизировать изображения.
• Производительность файловой системы. Зависит от того, что вы делаете, и от файловой системы, но вы можете реализовать механизм хеширования, чтобы у вас не было единого каталога с миллиардами файлов.
• Репликация. Вам нужно синхронизировать файлы между несколькими серверами?

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

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

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

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

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

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

Нет, из-за разбиения страницы. По сути, вы определяете строки размером от 1 КБ до n МБ, поэтому на страницах вашей базы данных будет много пустых пространств, что плохо для производительности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет.

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

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

По моему опыту, мне приходилось управлять обеими ситуациями: изображения, хранящиеся в базе данных, и изображения в файловой системе с путем, хранящимся в db.

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

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

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

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

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

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

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

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

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

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

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

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

ИМО, Плюсы использования базы данных для хранения изображений:

A. Вам не нужна структура FS для хранения ваших изображений Б. Индексы базы данных работают лучше, чем деревья ФС, когда нужно хранить большее количество элементов C. Грамотно настроенная база данных хорошо справляется с кэшированием результатов запроса D. Резервные копии просты. Это также хорошо работает, если у вас настроена репликация и контент доставляется с сервера, расположенного рядом с пользователем. В таких случаях явная синхронизация не требуется.

Если ваши изображения будут маленькими (скажем,

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

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

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

В моем маленьком приложении у меня есть как минимум миллион файлов, по последним подсчетам, весом около 200 ГБ. Все файлы находятся в файловой системе XFS, смонтированной на сервере Linux через iscsi. Пути хранятся в базе данных. используйте какое-то разумное соглашение об именах для ваших путей к файлам и имен файлов.

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

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

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

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

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

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

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

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

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

Мы реализовали систему визуализации документов, в которой все изображения хранятся в полях BLOB-объектов SQL2005. На данный момент их несколько сотен ГБ, и мы наблюдаем отличное время отклика и незначительное снижение производительности или его отсутствие. Кроме того, в соответствии с нормативными требованиями, у нас есть промежуточный уровень, который архивирует недавно отправленные документы в оптическую систему музыкального автомата, которая представляет их как стандартную файловую систему NTFS.

Мы очень довольны результатами, особенно в отношении:

1. Легкость репликации и резервного копирования
2. Возможность легко реализовать систему управления версиями документов

Если вы планируете общедоступный веб-сайт, вам не следует выбирать ни один из вариантов. Вам следует использовать сеть доставки контента (CDN). У CDN есть преимущества в цене, масштабируемости и скорости при доставке большого количества статического контента через Интернет.

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

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

Мы используем большие двоичные объекты, потому что ими проще управлять (резервное копирование, репликация, передача). Они хорошо работают для нас.

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

Плюсы:

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

Минусы:

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

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

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

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

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

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

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

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

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

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

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

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

+ вес:

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

-ves:

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

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

Предположение: приложение подключено к сети / веб-интерфейс

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

Храните файлы в платном онлайн-сервисе, например

• Amazon S3
• Облачное хранилище Moso

Другой поток StackOverflow говорит об этом здесь.

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

Это того стоит. Они хранят это эффективно. Нет загрузки полосы пропускания с ваших серверов на запросы клиентов и т. д.

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

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

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

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

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

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

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

Вы можете взглянуть на WKT Raster, проект, направленный на разработку поддержки растров в PostGIS, который, в свою очередь, служит геопространственным расширением для системы баз данных PostgreSQL. Идея, лежащая в основе WKT Raster, заключается не только в том, чтобы определить формат для сериализации и хранения растров (с использованием системы PostgreSQL), но, что гораздо важнее, чем хранение, - это указать эффективную обработку изображений на стороне базы данных, доступную из SQL. Короче говоря, идея состоит в том, чтобы перенести рабочий вес с клиента на серверную часть базы данных, чтобы он занимал места как можно ближе к самому хранилищу. WKT Raster, как PostGIS, предназначен для приложений определенного домена, ГИС.

Для более полного обзора проверьте интернет сайт и презентация (PDF) системы.

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

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

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

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

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

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

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

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