Итак, я использую приложение, которое хранит изображения в БД. Что вы думаете об этом? Я больше отношусь к типу для хранения местоположения в файловой системе, чем хранить его непосредственно в БД.
Как вы думаете, какие плюсы и минусы?
Хранение изображений в DB - Yea или Nay?
Ответ 1
Я отвечаю за некоторые приложения, которые управляют многими ТБ изображений. Мы обнаружили, что лучше хранить пути к файлам в базе данных.
Есть несколько проблем:
- Хранилище базы данных
- обычно более дорогое, чем хранилище файловой системы.
- вы можете супер-ускорить доступ к файловой системе со стандартными продуктами на полке
- Например, многие веб-серверы используют системный вызов операционной системы sendfile() для асинхронной отправки файла непосредственно из файловой системы в сетевой интерфейс. Изображения, хранящиеся в базе данных, не пользуются этой оптимизацией.
- вещи, такие как веб-серверы и т.д., не нуждаются в специальном кодировании или обработке для доступа к изображениям в файловой системе.
- базы данных выигрывают, когда важна целостность транзакций между изображением и метаданными.
- сложнее управлять целостностью между метаданными db и данными файловой системы.
- сложно (в контексте веб-приложения) гарантировать, что данные были сброшены на диск в файловой системе.
Ответ 2
Как и в большинстве проблем, это не так просто, как кажется. Бывают случаи, когда имеет смысл хранить изображения в базе данных.
- Вы сохраняете изображения, которые динамически меняются, скажите счета и вы хотите получить счет-фактуру, как это было 1 января 2007?
- Правительство хочет, чтобы вы поддерживали 6-летнюю историю.
- Изображения, хранящиеся в базе данных, не требуют другой стратегии резервного копирования. Изображения, хранящиеся в файловой системе,
- Легче контролировать доступ к изображениям, если они находятся в базе данных. Idle admins могут обращаться к любой папке на диске. Требуется действительно решительный администратор, чтобы отслеживать в базе данных, чтобы извлечь изображения.
С другой стороны, существуют проблемы, связанные с
- Требуется дополнительный код для извлечения и поток изображений
- Задержка может быть медленнее прямого доступа к файлам.
- Более тяжелая нагрузка на сервер базы данных
Ответ 3
Хранилище файлов. У инженеров Facebook были отличные разговоры об этом. Один из них - узнать практический предел файлов в каталоге.
Игла в стоге сена: эффективное хранение миллиардов фотографий
Ответ 4
Это может быть немного длинным, но если вы используете (или планируете использовать) SQL Server 2008, я бы рекомендовал взглянуть на новый FileStream.
FileStream решает большинство проблем с хранением файлов в БД:
- Блоки фактически хранятся как файлы в папке.
- Доступ к блокам можно получить либо с помощью подключения к базе данных, либо через файловую систему.
- Резервные копии интегрированы.
- Миграция "просто работает".
Однако SQL "Прозрачное шифрование данных" не шифрует объекты FileStream, поэтому, если это необходимо, вам может быть лучше хранить их как varbinary.
Из статьи MSDN:
Операторы Transact-SQL могут вставлять, обновлять, запрашивать, искать и создавать резервные копии данных FILESTREAM. Интерфейсы файловой системы Win32 обеспечивают потоковый доступ к данным.
FILESTREAM использует системный кеш NT для кэширования данных файла. Это помогает уменьшить любое влияние, которое могут иметь данные FILESTREAM на производительность Database Engine. Пул буферов SQL Server не используется; поэтому эта память доступна для обработки запросов.
Ответ 5
Пути к файлу в БД определенно, чтобы идти - я слышал историю после истории от клиентов с TB-изображениями, что она стала кошмаром, пытаясь сохранить любое значительное количество изображений в DB - слишком сильно ударяется производительность.
Ответ 6
По моему опыту, иногда самым простым решением является назвать изображения в соответствии с основным ключом. Поэтому легко найти изображение, принадлежащее конкретной записи, и наоборот. Но в то же время вы не храните ничего о изображении в базе данных.
Ответ 7
Трюк здесь - не стать фанатиком.
Здесь следует отметить, что никто в лагере pro файловой системы не указал конкретную файловую систему. Означает ли это, что все, начиная от FAT16 и заканчивая ZFS, легко удаляет каждую базу данных?
Нет.
По правде говоря, многие базы данных избивают многие файловые системы, даже когда мы говорим только о необработанной скорости.
Правильный курс действий - принять правильное решение для вашего точного сценария, и для этого вам понадобятся некоторые цифры и некоторые оценки использования.
Ответ 8
В тех местах, где вы ДОЛЖНЫ гарантировать ссылочную целостность и соответствие ACID, требуется хранение изображений в базе данных.
Вы не можете гарантировать транзакцию, чтобы изображение и метаданные об этом изображении, хранящиеся в базе данных, ссылались на один и тот же файл. Другими словами, невозможно гарантировать, что файл в файловой системе будет только изменен одновременно и в той же транзакции, что и метаданные.
Ответ 9
Как уже отмечалось, SQL 2008 имеет тип Filestream, который позволяет хранить имя файла или идентификатор в качестве указателя в db и автоматически сохраняет изображение в вашей файловой системе, что является отличным сценарием.
Если вы используете более старую базу данных, я бы сказал, что если вы храните ее в виде данных blob, то вы действительно не собираетесь извлекать что-либо из базы данных для поиска функций, поэтому вероятно, лучше всего сохранить адрес в файловой системе и сохранить изображение таким образом.
Таким образом, вы также сэкономите место на своей файловой системе, так как вы собираетесь сохранить точное количество пространства или даже сжатое пространство в файловой системе.
Кроме того, вы можете решить сохранить с некоторой структурой или элементами, которые позволяют просматривать необработанные изображения в вашей файловой системе без каких-либо удалений db или переносить файлы навалом в другую систему, жесткий диск, S3 или другой сценарий - обновление место в вашей программе, но сохраните структуру, снова без большого количества попыток вывести изображения из вашего db при попытке увеличить объем хранилища.
Вероятно, это также позволит вам бросить некоторый элемент кеширования, основанный на часто попадающих URL-адресах изображений в ваш веб-движок/программу, поэтому вы также можете сохранить себя там.
Ответ 10
Небольшие статические изображения (не более нескольких мегабайт), которые не часто редактируются, должны храниться в базе данных. Этот метод имеет несколько преимуществ, в том числе упрощает переносимость (изображения передаются вместе с базой данных), упрощает резервное копирование/восстановление (изображения подкрепляются базой данных) и улучшает масштабируемость (папка файловой системы с тысячами небольших миниатюрных файлов звучит как кошмар масштабируемости меня).
Обслуживать изображения из базы данных легко, просто реализовать обработчик http, который обслуживает массив байтов, возвращенный с сервера БД в виде двоичного потока.
Ответ 11
Вот интересный технический документ по этой теме.
В BLOB или не в BLOB: большое хранилище объектов в базе данных или файловой системе
Ответ: "Это зависит". Конечно, это будет зависеть от сервера базы данных и его подхода к хранению памяти. Это также зависит от типа данных, хранящихся в блоках, а также того, как эти данные должны быть доступны.
Файлы меньшего размера могут быть эффективно сохранены и доставлены с использованием базы данных в качестве механизма хранения. Более крупные файлы, вероятно, лучше всего будут сохранены в файловой системе, особенно если они будут часто модифицироваться/обновляться. (фрагментация blob становится проблемой в отношении производительности.)
Вот еще один момент, чтобы иметь в виду. Одной из причин, поддерживающих использование базы данных для хранения блоб, является соответствие ACID. Тем не менее, подход, который тестеры использовали в белом документе (опция Bulk Logged SQL Server), которая удваивала пропускную способность SQL Server, эффективно изменила "D" в ACID на "d", поскольку данные blob не были зарегистрированы с начальная запись для транзакции. Поэтому, если полное соответствие ACID является важным требованием для вашей системы, уменьшите показатели производительности SQL Server для записи в базу данных при сравнении ввода/вывода файлов с базой данных ввода/вывода.
Ответ 12
Одна вещь, о которой я еще никого не упоминал, но определенно стоит отметить, что есть проблемы, связанные с хранением большого количества изображений в большинстве файловых систем. Например, если вы примете описанный выше подход и назовите каждый файл изображения после первичного ключа, то на большинстве файловых систем вы столкнетесь с проблемами, если попытаетесь поместить все изображения в один большой каталог, как только вы достигнете очень большого количества изображений ( например, в сотнях тысяч или миллионов).
Как только общее решение для этого состоит в том, чтобы хэшировать их в сбалансированное дерево подкаталогов.
Ответ 13
Что-то, о чем никто не упоминал, заключается в том, что DB гарантирует атомарные действия, целостность транзакций и имеет дело с concurrency. Даже ссылочная целостность вне окна с файловой системой - так как вы знаете, что ваши имена файлов действительно правильные?
Если у вас есть изображения в файловой системе, и кто-то читает файл, когда вы пишете новую версию или даже удаляете файл - что происходит?
Мы используем blob, потому что они легче управлять (резервное копирование, репликация, передача). Они хорошо работают для нас.
Ответ 14
Проблема с сохранением только путей к файлам в базе данных заключается в том, что целостность базы данных больше не может быть принудительно.
Если фактическое изображение, на которое указывает путь к файлу, становится недоступным, база данных невольно имеет ошибку целостности.
Учитывая, что изображения представляют собой фактические данные, которые нужно искать, и что их можно управлять легче (изображения не будут внезапно исчезать) в одной интегрированной базе данных, а не для взаимодействия с какой-то файловой системой (если файловая система независимо от доступа, изображения МОГУТ "внезапно" исчезнуть "), я бы хотел хранить их непосредственно как BLOB или такие.
Ответ 15
В компании, где я работал, мы хранили 155 миллионов изображений в базе данных Oracle 8i (тогда 9i). 7,5 ТБ.
Ответ 16
Как правило, я не против использования самой дорогой и сложнейшей части вашей инфраструктуры (базы данных) и размещения на ней всех загрузок. С другой стороны: это значительно упрощает стратегию резервного копирования, особенно когда у вас несколько веб-серверов и нужно как-то синхронизировать данные.
Как и большинство других вещей, это зависит от ожидаемого размера и бюджета.
Ответ 17
Мы реализовали систему визуализации документов, которая хранит все изображения в блоках BLOB SQL2005. В настоящий момент существует несколько сотен GB, и мы наблюдаем отличное время отклика и небольшую декомпрессию производительности. Кроме того, у нас есть уровень промежуточного программного обеспечения, который архивирует недавно опубликованные документы в оптическую систему автомата, которая предоставляет их в качестве стандартной файловой системы NTFS.
Мы были очень довольны результатами, особенно в отношении:
- Простота репликации и резервного копирования
- Возможность легко реализовать систему управления версиями документов
Ответ 18
Если это веб-приложение, тогда могут быть преимущества для хранения изображений в сторонней сети доставки хранилища, такой как Amazon S3 или платформа Nirvanix.
Ответ 19
Предположение: приложение основано на веб-интерфейсе/веб-сайте
Я удивлен, что никто не упомянул об этом... передайте его другим специалистам → , используя сторонний поставщик изображений/файлов хостинга.
Храните свои файлы в платной онлайн-службе, например
Другие потоки StackOverflow говорят об этом здесь.
Этот поток объясняет, почему вы должны использовать сторонний хостинг-провайдер.
Это так стоит. Они эффективно хранят его. Никакая передача полосы пропускания с ваших серверов на запросы клиентов и т.д.
Ответ 20
Если вы не используете SQL Server 2008, и у вас есть веские причины для размещения определенных файлов изображений в базе данных, вы можете использовать "оба" подхода и использовать файловую систему в качестве временного кеша и использовать базу данных как мастер-репозиторий.
Например, ваша бизнес-логика может проверить, существует ли файл образа на диске перед его обслуживанием, извлекая из базы данных, когда это необходимо. Это позволяет вам использовать несколько веб-серверов и меньше проблем с синхронизацией.
Ответ 21
Я не уверен, какой из примеров является "реальный мир", но в настоящее время у меня есть приложение, в котором хранятся данные для торговой карточной игры, в том числе изображения для карт. Предоставлено количество записей для базы данных - всего 2851 записей на сегодняшний день, но учитывая тот факт, что некоторые карты выпущены несколько раз и имеют альтернативное оформление, было фактически более эффективно выполнять сканирование "первичного квадрата" произведения, а затем динамически генерировать границу и разные эффекты для карты по запросу.
Оригинальный создатель этой библиотеки изображений создал класс доступа к данным, который отображает изображение на основе запроса, и он делает это довольно быстро для просмотра и отдельной карты.
Это также облегчает развертывание/обновление при выпуске новых карт, вместо того, чтобы закрепить всю папку изображений и отправить их вниз по каналу и обеспечить правильную структуру папок, я просто обновляю базу данных и загружаю ее пользователю еще раз. В настоящее время размер составляет до 56 МБ, что не очень удобно, но я работаю над инкрементной функцией обновления для будущих выпусков. Кроме того, есть версия приложения "без изображений", которая позволяет тем через dial-up получать приложение без задержки загрузки.
Это решение отлично поработало с тех пор, как само приложение предназначено как один экземпляр на рабочем столе. Существует веб-сайт, на котором все эти данные заархивированы для онлайн-доступа, но я бы никоим образом не использовал одно и то же решение для этого. Я согласен, что доступ к файлам будет предпочтительнее, потому что он будет лучше масштабироваться по частоте и объему запросов, сделанных для изображений.
Надеюсь, это не слишком много болтовни, но я увидел эту тему и хотел бы дать некоторые мои идеи из относительно успешного малого/среднего приложения.
Ответ 22
SQL Server 2008 предлагает решение, имеющее лучшее из обоих миров: Тип данных потока.
Управляйте им как обычной таблицей и выполняйте производительность файловой системы.
Ответ 23
Это зависит от количества изображений, которые вы собираетесь хранить, а также от их размеров. Я использовал базы данных для хранения изображений в прошлом, и мой опыт был довольно хорошим.
IMO, Плюсы использования базы данных для хранения изображений,
а. Вам не нужна структура FS для хранения ваших изображений
B. Индексы базы данных работают лучше, чем деревья FS, когда нужно хранить большее количество элементов
C. Интеллектуально настроенная база данных выполняет хорошую работу по кэшированию результатов запроса
D. Резервные копии просты. Он также хорошо работает, если у вас установлена репликация, а контент доставляется с сервера рядом с пользователем. В таких случаях явная синхронизация не требуется.
Если ваши изображения будут небольшими (скажем, 64 КБ), а механизм хранения ваших баз данных поддерживает встроенные (в записи) BLOB файлы, это улучшает производительность, так как не требуется никакое косвенное направление (достигается местность ссылки).
Сохранение изображений может быть плохой идеей, когда вы имеете дело с небольшим количеством изображений огромного размера. Другая проблема с хранением изображений в db заключается в том, что метаданные, такие как создание, даты модификации, должны обрабатываться вашим приложением.
Ответ 24
Недавно я создал приложение PHP/MySQL, в котором хранятся файлы PDF/Word в таблице MySQL (до 40 МБ на файл).
Плюсы:
- Загруженные файлы реплицируются на сервер резервного копирования вместе со всем остальным, не требуется отдельная стратегия резервного копирования (спокойствие).
- Настройка веб-сервера немного проще, потому что мне не нужно иметь папку uploads/folder и сообщать обо всех моих приложениях, где они есть.
- Я могу использовать транзакции для редактирования, чтобы улучшить целостность данных. Мне не нужно беспокоиться о потерянных и потерянных файлах.
Минусы:
- mysqldump теперь занимает время looooong, потому что в одной из таблиц содержится 500 Мбайт данных.
- В целом не очень эффективная память/процессор по сравнению с файловой системой.
Я бы назвал свою реализацию успешной, она заботится о требованиях к резервному копированию и упрощает компоновку проекта. Производительность отлично подходит для 20-30 человек, которые используют приложение.
Ответ 25
Мне очень понравилось, что мне приходилось управлять обеими ситуациями: изображения, хранящиеся в базе данных и изображениях в файловой системе, с пути, хранящимся в db.
Первое решение, изображения в базе данных, несколько "чище", так как ваш уровень доступа к данным будет иметь дело только с объектами базы данных; но это хорошо только тогда, когда вам приходится иметь дело с низкими цифрами.
Очевидно, что производительность доступа к базе данных при работе с бинарными большими объектами ухудшается, а размеры базы данных будут расти много, что приведет к еще большей потере производительности... и обычно пространство базы данных намного дороже, чем пространство в файловой системе.
С другой стороны, наличие больших двоичных объектов, хранящихся в файловой системе, приведет к созданию планов резервного копирования, которые должны учитывать как базу данных, так и файловую систему, и это может быть проблемой для некоторых систем.
Еще одна причина для файловой системы - когда вы должны делиться своими данными изображений (или звуками, видео и т.д.) с сторонним доступом: в настоящее время я разрабатываю веб-приложение, которое использует образы, к которым нужно получить доступ от "вне" моей веб-фермы таким образом, что доступ к базе данных для извлечения двоичных данных просто невозможно. Поэтому иногда есть и соображения дизайна, которые помогут вам выбрать.
Учитывайте также, когда вы делаете этот выбор, если вам приходится иметь дело с разрешением и аутентификацией при доступе к двоичным объектам: эти реквизиты обычно могут быть решены более простым способом, когда данные хранятся в db.
Ответ 26
Я когда-то работал над приложением для обработки изображений. Мы сохранили загруженные изображения в каталоге, который был что-то вроде /images/ [today date]/[id number]. Но мы также извлекли метаданные (exif-данные) из изображений и сохранили их в базе данных вместе с меткой времени и т.д.
Ответ 27
В предыдущем проекте я сохранил изображения в файловой системе и вызвал много головных болей с резервными копиями, репликацией и файловой системой, которые не синхронизировались с базой данных.
В моем последнем проекте я храню изображения в базе данных и кэширую их в файловой системе, и он работает очень хорошо. До сих пор у меня не было проблем.
Ответ 28
Во-вторых, рекомендация по путям файлов. Я работал над несколькими проектами, которые необходимы для управления коллекциями активов большого объема, и любые попытки хранить вещи непосредственно в БД приводили к боли и разочарованиям в долгосрочной перспективе.
Единственный реальный "профессионал", который я могу думать о хранении их в БД, - это потенциал для легкого использования отдельных имиджевых активов. Если нет путей к файлу для использования, и все изображения передаются прямо из БД, нет никакой опасности, что пользователь найдет файлы, к которым у них не должно быть доступа.
Похоже, что было бы лучше решить с помощью промежуточного script вытаскивания данных из недоступного в сети хранилища файлов. Таким образом, хранилище БД не является ДЕЙСТВИТЕЛЬНО необходимым.
Ответ 29
Слово на улице состоит в том, что, если вы не являетесь продавцом базы данных, пытающимся доказать, что ваша база данных может это сделать (например, пусть Microsoft может похвастаться тем, что Terraserver хранит изображения bajillion в SQL Server), это не очень хорошая идея. Когда альтернатива - хранение изображений на файловых серверах и пути в базе данных намного проще, зачем беспокоиться? Поля Blob похожи на внедорожные возможности внедорожников - большинство людей их не используют, те, у кого обычно возникают проблемы, а затем есть те, кто это делает, но только ради удовольствия.
Ответ 30
Сохранение изображения в базе данных по-прежнему означает, что данные изображения заканчиваются где-то в файловой системе, но скрываются, поэтому вы не можете получить к нему доступ напрямую.
+ VES:
- целостность базы данных
- его легко управлять, так как вам не нужно беспокоиться о синхронизации файловой системы при добавлении или удалении изображения.
-ves:
- Снижение производительности - поиск базы данных обычно медленнее, чем поиск файловой системы.
- вы не можете редактировать изображение напрямую (обрезка, изменение размера)
Оба метода распространены и практикуются. Посмотрите на преимущества и недостатки. В любом случае вам придется подумать о том, как преодолеть недостатки. Хранение в базе данных обычно означает настройку параметров базы данных и реализацию какого-либо кэширования. Использование файловой системы требует от вас поискать способ синхронизации файловой системы +.