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

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

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

• хранение базы данных обычно дороже, чем хранение файловой системы
• you can super-accelerate file system access with standard off the shelf products
  • for example, many web servers use the operating system's sendfile() system call to asynchronously send a file directly from the file system to the network interface. Images stored in a database don't benefit from this optimization.
• такие вещи, как веб-серверы и т. д., не требуют специального кодирования или обработки для доступа к изображениям в файловой системе.
• databases win out where transactional integrity between the image and metadata are important.
  • it is more complex to manage integrity between db metadata and file system data
  • трудно (в контексте веб-приложения) гарантировать, что данные были сброшены на диск в файловой системе

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

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

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

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

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

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

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

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

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

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

Из статьи MSDN:

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

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

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

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

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

No.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предположение: приложение подключено к Интернету / работает в Интернете

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

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

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

Еще одна ветка StackOverflow говорит об этом здесь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если ваши изображения будут небольшими (скажем, ‹64k) и механизм хранения вашей базы данных поддерживает встроенные (в записи) большие двоичные объекты, это еще больше повысит производительность, поскольку не требуется косвенное обращение (достигается локальность ссылки).

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

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

Плюсы:

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

Минусы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+ вес:

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

-ves:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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