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

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

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

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

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

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

Файловая система, наверняка. Тогда Вы добираетесь для использования всей функциональности ОС для контакта с этими изображениями - назад взлеты, веб-сервер, даже просто пишущий сценарий пакетных инструментов использования изменений как imagemagic. При хранении их в DB тогда, необходимо будет записать собственный код для решения этих проблем.

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

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

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

Как с большинством вещей: 'Это зависит от того, что Вы делаете'

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

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

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

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

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

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

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

Прием здесь не должен становиться зилотом.

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

№

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

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

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

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

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

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

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

Что-то, что никто не упомянул, - то, что DB гарантирует атомарные действия, целостность транзакций и соглашения с параллелизмом. Даже соотносимо целостность вне окна с файловой системой - поэтому, как Вы знаете, что Ваши имена файлов действительно все еще корректны?

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

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

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

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

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

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

1. Простота Репликации и Резервного копирования
2. Способность легко реализовать систему управления версиями документа

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

Профессионалы:

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

Недостатки:

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

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

Вот интересный отчет о теме.

К BLOB или Не К BLOB: устройство хранения данных Большого объекта в Базе данных или Файловой системе

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

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

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

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

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

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

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

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

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

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

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

+ ves:

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

-ves:

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

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

Предположение: приложение работает в сети / работает в сети

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

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

• Amazon S3
• Moso Cloud Storage

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

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

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

In a previous project i stored images on the filesystem, and that caused a lot of headaches with backups, replication, and the filesystem getting out of sync with the database.

In my latest project i'm storing images in the database, and caching them on the filesystem, and it works really well. I've had no problems so far.

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

• Переместите изображения на другой раздел или сервер, просто обновив глобальную конфигурацию.
• Найдите запись, соответствующую изображению, выполнив поиск по ее первичному ключу.
• Ваши изображения доступны для обработки. такие инструменты, как 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) системы.