Поэтому я использую приложение, которое в большой степени хранит изображения в БД. Что вы думаете об этом? Я больше похож на то, чтобы хранить расположение в файловой системе, чем хранить его непосредственно в БД.
Как вы думаете, плюсы / минусы?
Я отвечаю за некоторые приложения, которые управляют многими изображениями ТБ. Мы обнаружили, что лучше всего хранить пути к файлам в базе данных.
Есть пара вопросов:
- хранение в базе данных обычно дороже, чем в файловой системе
- Вы можете супер-ускорить доступ к файловой системе с помощью стандартных готовых продуктов
- Например, многие веб-серверы используют системный вызов sendfile () операционной системы для асинхронной отправки файла непосредственно из файловой системы в сетевой интерфейс. Изображения, хранящиеся в базе данных, не выигрывают от этой оптимизации.
- такие вещи, как веб-серверы и т. д., не требуют специального кодирования или обработки для доступа к изображениям в файловой системе
- базы данных выигрывают там, где важна целостность транзакций между изображением и метаданными.
- сложнее управлять целостностью между метаданными БД и данными файловой системы
- трудно (в контексте веб-приложения) гарантировать, что данные были записаны на диск в файловой системе
Ваш веб-сервер (я предполагаю, что вы используете его) предназначен для обработки изображений, а база данных - нет. Таким образом, я бы проголосовал против «за».
Сохраните только путь (и, возможно, информацию о файле) в базе данных.
Я лично храню большие данные за пределами базы данных.
Плюсы: хранит все в одном, пожалуйста, легкий доступ к файлам данных, простое запоминание Минусы: снижает производительность базы данных, много разбиений страниц, возможное повреждение базы данных
Обычно я категорически против того, чтобы брать самую дорогую и сложную для масштабирования часть вашей инфраструктуры (базу данных) и вкладывать в нее всю нагрузку. С другой стороны: это значительно упрощает стратегию резервного копирования, особенно если у вас есть несколько веб-серверов и вам необходимо каким-то образом синхронизировать данные.
Как и большинство других вещей, это зависит от ожидаемого размера и бюджета.
Вторая рекомендация о путях к файлам. Я работал над парой проектов, которые требовали управления коллекциями активов большого размера, и любые попытки хранить вещи непосредственно в БД приводили к боли и разочарованию в долгосрочной перспективе.
Единственное реальное «про», о котором я могу подумать относительно хранения их в БД, - это возможность легкого использования отдельных ресурсов изображений. Если нет путей к файлам, и все изображения передаются прямо из БД, нет опасности, что пользователь найдет файлы, к которым у него не должно быть доступа.
Похоже, что это было бы лучше решить с помощью промежуточного скрипта, извлекающего данные из недоступного в сети хранилища файлов. Таким образом, хранение БД НЕ ДЕЙСТВИТЕЛЬНО необходимо.
Если это веб-приложение, то могут быть преимущества хранения изображений в сторонней сети хранения данных, такой как Amazon S3 или платформа Nirvanix.
По моему опыту, иногда самое простое решение - назвать изображения в соответствии с первичным ключом . Таким образом, легко найти изображение, которое принадлежит определенной записи, и наоборот. Но в то же время вы не хранить что - либо об изображении в базе данных.
Путь к файлам в БД - это, безусловно , правильный путь - я слышал историю за историей от клиентов с ТБ изображений, которые превратились в кошмар, пытающийся сохранить сколько-нибудь значительное количество изображений в БД - один только удар по производительности слишком велик.
В компании, где я работал, мы хранили 155 миллионов изображений в базе данных Oracle 8i (тогда 9i). 7,5 ТБ стоит.
Небольшие статические изображения (не более пары мегабайт), которые не часто редактируются, должны храниться в базе данных. Этот метод имеет несколько преимуществ, включая более простую переносимость (изображения передаются вместе с базой данных), более легкое резервное копирование / восстановление (резервное копирование изображений с помощью базы данных) и лучшую масштабируемость (папка файловой системы с тысячами маленьких файлов миниатюрных изображений звучит как кошмар масштабируемости для меня).
Обслуживание изображений из базы данных легко, просто реализуйте обработчик http, который обслуживает массив байтов, возвращаемый сервером БД, в виде двоичного потока.
Это может показаться чем-то большим, но если вы используете (или планируете использовать) SQL Server 2008, я бы рекомендовал взглянуть на новый тип данных FileStream .
FileStream решает большинство проблем, связанных с хранением файлов в БД:
- Капли на самом деле хранятся в виде файлов в папке.
- В Blobs можно получить с помощью либо соединения с базой данных или через файловую систему.
- Резервные копии интегрированы.
- Миграция "просто работает".
Однако «прозрачное шифрование данных» в SQL не шифрует объекты FileStream, поэтому, если это важно, вам лучше просто хранить их как varbinary.
Из статьи MSDN:
Операторы Transact-SQL могут вставлять, обновлять, запрашивать, искать и резервировать данные FILESTREAM. Интерфейсы файловой системы Win32 обеспечивают потоковый доступ к данным.
FILESTREAM использует системный кеш NT для кэширования данных файла. Это помогает уменьшить любой эффект, который данные FILESTREAM могут оказать на производительность компонента Database Engine. Буферный пул SQL Server не используется; поэтому эта память доступна для обработки запросов.
Уличное слово гласит, что если вы не являетесь поставщиком базы данных, пытаясь доказать, что ваша база данных может это сделать (например, скажем, Microsoft хвастается тем, что Terraserver хранит изображения в виде баджиллиона в SQL Server), это не очень хорошая идея. Когда альтернатива - хранение изображений на файловых серверах и в базе данных путей намного проще, зачем беспокоиться? Поля блобов напоминают внедорожные возможности внедорожников - большинство людей их не используют, те, кто обычно попадают в неприятности, а есть и те, которые делают, но только для удовольствия.
Я бы пошел с подходом файловой системы. Как отметили некоторые другие, большинство веб-серверов созданы для отправки изображений по пути к файлу. Вы будете иметь гораздо более высокую производительность, если вам не придется записывать или выводить BLOB-поля из базы данных. Наличие файловой системы для хранения изображений упрощает настройку статических страниц, когда содержимое не изменяется или требуется ограничить нагрузку на базу данных.
Попытка имитировать файловую систему с использованием SQL, как правило, плохой план. В конечном итоге вы пишете меньше кода с одинаковыми или лучшими результатами, если придерживаетесь файловой системы для внешнего хранения.
Одна вещь, о которой я еще не упоминал, но которую стоит отметить, - это проблемы, связанные с хранением большого количества изображений в большинстве файловых систем. Например, если вы используете упомянутый выше подход и называете каждый файл изображения после первичного ключа, в большинстве файловых систем вы столкнетесь с проблемами, если попытаетесь поместить все изображения в один большой каталог, как только вы достигнете очень большого количества изображений ( например, сотнями тысяч или миллионами).
Однажды общее решение этого состоит в том, чтобы объединить их в сбалансированное дерево подкаталогов.
Файловое хранилище. Инженеры Facebook здорово поговорили об этом. Один из них - узнать практический предел количества файлов в каталоге.
Игла в стоге сена: эффективное хранение миллиардов фотографий
Я не уверен, насколько это «реальный мир», но в настоящее время у меня есть приложение, в котором хранятся данные для торговой карточной игры, включая изображения для карточек. Предполагается, что количество записей для базы данных на сегодняшний день составляет всего 2851 записей, но, учитывая тот факт, что определенные карты выпущены несколько раз и имеют альтернативное оформление, на самом деле было более эффективно сканировать «первичный квадрат» рисунка, а затем динамически генерировать границы и прочие эффекты для карты по запросу.
Первоначальный создатель этой библиотеки изображений создал класс доступа к данным, который отображает изображение на основе запроса, и делает это довольно быстро для просмотра и отдельной карты.
Это также облегчает развертывание / обновление при выпуске новых карт, вместо того, чтобы заархивировать целую папку с изображениями и отправить их по конвейеру и убедиться, что создана правильная структура папок, я просто обновляю базу данных и заставляю пользователя загружать ее снова. В настоящее время его размер составляет до 56 МБ, что не очень хорошо, но я работаю над функцией постепенного обновления для будущих выпусков. Кроме того, существует версия приложения «без изображений», которая позволяет пользователям, подключенным к сети, получить приложение без задержки загрузки.
На сегодняшний день это решение отлично работает, поскольку само приложение предназначено для использования в качестве единственного экземпляра на рабочем столе. Существует веб-сайт, где все эти данные архивируются для онлайн-доступа, но я ни в коем случае не использовал бы одно и то же решение для этого. Я согласен, что доступ к файлам будет предпочтительнее, поскольку он будет лучше масштабироваться в зависимости от частоты и объема запросов к изображениям.
Надеюсь, что это не слишком много болтовни, но я увидел тему и хотел поделиться своими соображениями относительно относительно успешного приложения для малого и среднего масштаба.
Только причина , мы сохраняем изображения в наших таблицах , поскольку каждая таблица (или набор таблиц в диапазон работы) является временной и упала в конце рабочего процесса. Если бы существовало какое-либо долговременное хранилище, мы бы точно выбрали пути к файлам.
Следует также отметить, что мы работаем с клиент-серверным приложением внутри, поэтому нет необходимости беспокоиться о веб-интерфейсе.
Однажды я работал над приложением для обработки изображений. Мы сохранили загруженные изображения в каталоге, который был что-то вроде / images / [сегодняшняя дата] / [id номер]. Но мы также извлекли метаданные (exif-данные) из изображений и сохранили их в базе данных вместе с отметкой времени и тому подобным.
Если вам нужно хранить много изображений в файловой системе, подумайте о следующих вещах:
- Резервное копирование и восстановление. Как вы держите изображения в синхронизации.
- Производительность файловой системы. Зависит от того, что вы делаете, и от файловой системы, но вы можете захотеть реализовать механизм хеширования, чтобы у вас не было ни одного каталога с миллиардами файлов.
- Репликация. Вам нужно синхронизировать файлы между несколькими серверами?
Выгрузка двоичных данных из вашей БД по проводам вызовет огромные задержки и не будет хорошо масштабироваться.
Сохраняйте пути в БД, и пусть ваш веб-сервер берет на себя нагрузку - это то, для чего он был разработан!
Как и в большинстве вопросов, это не так просто, как кажется. Есть случаи, когда имеет смысл хранить изображения в базе данных.
- Вы храните изображения, которые динамически изменяются, например, счета-фактуры, и вы хотите получить счет-фактуру, как это было 1 января 2007 года?
- Правительство хочет, чтобы вы сохранили 6 лет истории
- Изображения, хранящиеся в базе данных, не требуют другой стратегии резервного копирования. Изображения хранятся в файловой системе
- Проще контролировать доступ к изображениям, если они находятся в базе данных. Свободные администраторы могут получить доступ к любой папке на диске. Требуется действительно решительный администратор, чтобы искать информацию в базе данных, чтобы извлечь изображения
С другой стороны, есть проблемы, связанные
- Требовать дополнительный код для извлечения и потоковой передачи изображений
- Задержка может быть медленнее, чем прямой доступ к файлам
- Более тяжелая нагрузка на сервер базы данных
Нет, из-за разбиения страницы. По сути, вы определяете строки, которые могут иметь размер 1 КБ - n МБ, поэтому в вашей базе данных будет много пустых мест на страницах, что ухудшает производительность.
Файловая система, наверняка. Затем вы можете использовать все функциональные возможности ОС для работы с этими изображениями - резервные копии, веб-сервер, даже просто пакетные изменения сценариев с использованием таких инструментов, как imagemagic. Если вы храните их в БД, вам нужно написать собственный код для решения этих проблем.
SQL Server 2008 предлагает решение, которое имеет лучшее из обоих миров: тип данных файлового потока .
Управляйте им как обычной таблицей и обладайте производительностью файловой системы.
Одна вещь, которую вы должны иметь в виду, это размер вашего набора данных. Я полагаю, что Дилли-О была единственной, кто даже отдаленно достиг цели.
Если у вас есть небольшое приложение для одного пользователя, я бы сказал, DB. У меня есть приложение для управления DVD, которое использует файловую систему (в программных файлах) и это PIA для резервного копирования. Я желаю КАЖДЫЙ раз, когда они будут хранить их в БД, и позвольте мне выбрать, где сохранить этот файл.
Для более крупного коммерческого применения я бы начал менять свое мышление. Раньше я работал в компании, которая разработала приложение для управления информацией уездных служащих. Мы будем хранить изображения на диске в закодированном формате [для решения проблем FS с большим количеством файлов] на основе назначенного округом номера инструмента. Это было полезно с другой стороны, так как изображение могло существовать до записи в БД (из-за их рабочего процесса).
Как и в большинстве случаев: «Это зависит от того, что вы делаете»
Еще одно преимущество хранения изображений в файловой системе заключается в том, что вам не нужно делать ничего особенного, чтобы клиент кешировал их ...
... если, конечно, изображение не доступно через корень документа (например, барьер аутентификации), в этом случае вам нужно будет проверить заголовки контроля кэша, который отправляет ваш код.
Как уже говорили другие, SQL 2008 поставляется с типом Filestream, который позволяет вам сохранять имя файла или идентификатор в виде указателя в БД и автоматически сохраняет изображение в вашей файловой системе, что является отличным сценарием.
Если вы используете более старую базу данных, то я бы сказал, что если вы храните ее как данные BLOB-объектов, то вы действительно не собираетесь ничего извлекать из базы данных для поиска функций, поэтому, вероятно, лучше хранить адрес в файловой системе и хранить изображение таким образом.
Таким образом, вы также экономите место в вашей файловой системе, так как вы собираетесь сэкономить только точное количество места или даже сжатое пространство в файловой системе.
Кроме того, вы можете решить сохранить с некоторой структурой или элементами, которые позволяют вам просматривать необработанные изображения в вашей файловой системе без каких-либо ударов по БД, или переносить файлы в массе на другую систему, жесткий диск, S3 или другой сценарий - обновляя расположение в ваша программа, но сохраняйте структуру, опять же, без особых усилий, пытаясь вывести изображения из вашей БД при попытке увеличить объем хранилища.
Вероятно, это также позволит вам добавить некоторый элемент кэширования, основанный на часто используемых URL-адресах изображений, в ваш веб-движок / программу, так что вы сохраняете себя там же.
Я ведущий разработчик корпоративной системы управления документами, в которой некоторые клиенты хранят сотни гигабайт документов. Терабайты в недалеком будущем. Мы используем подход файловой системы по многим причинам, упомянутым на этой странице, а также по другой причине: архивирование.
Многие из наших клиентов должны соответствовать отраслевым правилам архивирования, таким как хранение на оптическом диске или хранение в непатентованном формате. Кроме того, у вас есть возможность просто добавить больше дисков на устройство NAS. Если у вас есть файлы, хранящиеся в вашей базе данных, даже с типом данных потока файлов в SQL Server 2008, ваши параметры архивирования стали намного более узкими.
Хитрость в том, чтобы не стать фанатиком.
Здесь следует отметить, что никто в лагере профессиональных файловых систем не перечислил конкретную файловую систему. Означает ли это, что все от FAT16 до ZFS легко превосходит каждую базу данных?
Нет.
Правда состоит в том, что многие базы данных побеждают многие файловые системы, даже когда мы говорим только о скорости.
Правильный курс действий состоит в том, чтобы принять правильное решение для вашего точного сценария, и для этого вам понадобятся некоторые цифры и некоторые оценки вариантов использования.