Хранение изображений в DB – Yea или Nay?

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

Как вы думаете, какие плюсы и минусы?

  • Является ли хранение разделенного списка в столбце базы данных действительно так плохо?
  • 30 Solutions collect form web for “Хранение изображений в DB – Yea или Nay?”

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

    Есть несколько вопросов:

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

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

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

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

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

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

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

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

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

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

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

    Из статьи MSDN:

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

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

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

    Трюк здесь – не стать фанатиком.

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

    Нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Когда-то общее решение этого – вывести их в сбалансированное дерево подкаталогов.

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

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

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

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

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

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

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

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

    Как и большинство других вещей, это зависит от ожидаемого размера и бюджета.

    Мы внедрили систему обработки документов, которая хранит все изображения в блоках BLOB SQL2005. В настоящий момент существует несколько сотен GB, и мы наблюдаем отличное время отклика и небольшую декомпрессию производительности. Кроме того, у нас есть уровень промежуточного программного обеспечения, который архивирует недавно опубликованные документы в оптическую систему автомата, которая предоставляет их в качестве стандартной файловой системы NTFS.

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

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

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

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

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

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

    • Amazon S3
    • Мозо облачное хранилище

    Другие streamи StackOverflow говорят об этом здесь .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Плюсы:

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

    Минусы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    + VES:

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

    -ves:

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

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

    Interesting Posts

    Настройка локальной сети клиент-сервер с ограниченным доступом

    Не удается ssh для моего iphone: ssh_exchange_identification: соединение закрыто удаленным хостом

    Автоматическое связывание ссылок в тексте с библиографической записью

    Локальные и IP-адреса Интернета

    Включение удаленных рабочих станций Список последних подключений (список переходов)

    Нужно ли иметь кодовую фразу для моего ключа SSA SSH?

    Могу ли я навсегда запретить обновлениям безопасности Java от установки панели инструментов Yahoo?

    Ошибка FTP FileZilla «Соединение отказано сервером»

    Передача права собственности на Windows 7

    Используя dd для копирования раздела в другой раздел, при использовании физического диска

    Могу ли я заставить Google Chrome использовать полноэкранный режим по умолчанию?

    Как сделать Bash моей оболочкой по умолчанию на Ubuntu?

    Как включить привязку к сетке по умолчанию в Mac OS X?

    Файл MP4 игнорирует настройки субтитров в VLC

    Команда MS-DOS для удаления всех файлов, кроме одного

    Давайте будем гением компьютера.