Изображения в базе данных и файловой системе

Ответ 1

Был хороший исследовательский документ, опубликованный Microsoft Research под названием To Blob или не в Blob, где они смотрели на всевозможные переменные и удары.

Их вывод в конце:

• размером до 256 КБ, капли хранятся в базе данных более эффективно, чем в файловой системе.
• для 1 МБ и более, файловая система более эффективна
• между ними подбрасывается

Поскольку этот документ был опубликован, SQL Server 2008 также добавил атрибут FILESTREAM, который позволяет хранить материал в файловой системе, но в транзакционном управлении - реальность. Очень рекомендую вам проверить это!

Ответ 2

Этот вопрос часто возникает - см. этот результат поиска SO.

Нет никакого правильного ответа - это зависит от обстоятельств.

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

Ответ 3

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

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

В предложениях по хранению пути в db отсутствует реальная проблема, которая реплицирует это на нескольких машинах.

Ответ 4

Хорошо, если ваши две лучшие потребности - это целостность и репликация, тогда ответ определенно DB.

У вас есть другие пункты:

• Integrity - DB, поэтому базы данных существуют против файловых систем.

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

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

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

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

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

Ответ 5

Ваши проблемы разбиваются на два лагеря. Следующие проблемы касаются хранения документов в базе данных:

• Целостность данных
• Репликация данных
• Несколько резолюций
• Управление данными и резервное копирование

Эти проблемы (возможно) способствуют хранению документов в файловой системе:

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

Итак, решите, что самое главное и выберите соответственно.

Ответ 6

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

Хранилище Inline/BLOB

Поверхность: упрощает архитектуру и реализацию, упрощает резервное копирование и восстановление или миграцию системы; просто сделайте дамп, резервную копию, экспорт (независимо от того, какой термин для вашего аромата БД) и переместите его в новую базу данных. Управление версиями/согласованность обрабатывается БД, поэтому позволяет восстанавливать время в момент. Безопасность/контроль доступа также более чисты, поскольку доступ к BLOB изображения является неотъемлемой частью доступа к общей строке. Перемещение изображения за пределами БД и предоставление HTTP-сервера для его получения, а лучше для concurrency и масштабируемости, могут иметь проблемы с тем, чтобы люди не могли взломать URL-адреса и запросить изображения, которыми они не владеют. Если вы размещаете их вне БД, убедитесь, что ваша политика безопасности охватывает контроль доступа к изображениям между пользователями. Либо ваша аутентификация HTTP-сервера должна интегрироваться с общей системной аутентификацией, либо ваша программа HTTP-сервера, которая обслуживает изображения, использует какой-то механизм сеанса, чтобы гарантировать, что HTTP-запрос действителен. Это очень большая проблема в базе данных с несколькими арендаторами. Меньше проблемы в одиночных, однопользовательских системах с простой аутентификацией.

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

Всегда учитывайте время восстановления в любой системе. Если ваши требования к хранению < несколько гигабайт, скажем, 50-100 ГБ, и у вас много запланированного резервного пространства, встроенное хранилище чище. Помимо этого, разделение проблем и предоставление файловой системе своей работы становится ключевым преимуществом. Ничто не хуже, чем попытка восстановить, восстановить и открыть огромную базу данных ради небольшой ошибки данных. Время восстановления было бы самой большой проблемой.

Ответ 7

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

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

Несколько соображений, почему вы должны рассмотреть FileSystem

• Браузер выполняет всю работу, и вам выгодно кэширование прокси изображений и т.д.
• В качестве ответвления вышеизложенного вы можете легко использовать сети доставки контента (CDN)
• Репликация данных изображений легко с помощью таких инструментов, как rsync и т.д.
• Время обработки (т.е. CPU) сильно оптимизировано.

Ответ 8

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

Недостатки файловой системы

-Не автоматически реплицируется

-Может усложнить вашу репликацию, имея разные физические местоположения для каждого экземпляра

-Slow с очень большим количеством файлов

Поверхность файловой системы

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

Ответ 9

Я бы хотел;

1) Назначьте уникальный идентификатор (GUID) для каждого изображения 2) Тег/Назовите изображение с помощью этого GUID 3) Сохранить GUID в ОС (файловая система) 4) Сохранить в базе данных полное имя имени файла (FQN).

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

Ответ 10

Я бы не хранил изображения в базе данных по одной причине (мой ответ исходит от SQL-сервера):

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

Ответ 11

Спасибо за весь быстрый ввод, у нас есть только около 5-10 ГБ изображений, и многое из того, что мы имеем несколько разрешений одного и того же изображения.

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

Еще раз спасибо за вход!