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

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

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

6.08.2008 17:38:35
Ну, вы можете сделать оба с транзакционным дисковым кешем .
Lilith River 15.08.2011 21:16:28
30 ОТВЕТОВ

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

Есть пара вопросов:

  • хранение в базе данных обычно дороже, чем в файловой системе
  • Вы можете супер-ускорить доступ к файловой системе с помощью стандартных готовых продуктов
    • Например, многие веб-серверы используют системный вызов sendfile () операционной системы для асинхронной отправки файла непосредственно из файловой системы в сетевой интерфейс. Изображения, хранящиеся в базе данных, не выигрывают от этой оптимизации.
  • такие вещи, как веб-серверы и т. д., не требуют специального кодирования или обработки для доступа к изображениям в файловой системе
  • базы данных выигрывают там, где важна целостность транзакций между изображением и метаданными.
    • сложнее управлять целостностью между метаданными БД и данными файловой системы
    • трудно (в контексте веб-приложения) гарантировать, что данные были записаны на диск в файловой системе
350
20.11.2010 17:25:42
какие готовые продукты доступны для «суперускорения» файловой системы?
Andrei Rînea 4.10.2008 10:53:05
Хотя я управляю только 3 ТБ файлов, я определенно согласен. Базы данных предназначены для структурированных данных, а не для блобов.
derobert 22.03.2009 19:31:40
@derobert: именно так, если вы никогда не будете использовать элемент данных в запросе, в качестве условия или для соединения, он, вероятно, не принадлежит базе данных. Опять же, если у вас есть хорошая функция базы данных для запроса изображений на подобие ...
Nils Weinander 18.05.2009 14:34:01
какие готовые продукты доступны для «суперускорения» файловой системы?
ablmf 31.07.2009 15:16:54
Re: «суперускоряющие» продукты: большинство веб-серверов теперь могут использовать системный вызов sendfile () для асинхронной доставки статических файлов клиенту. Он переносит на операционную систему задачу переноса файла с диска на сетевой интерфейс. ОС может сделать это намного эффективнее, работая в пространстве ядра. Мне кажется, это большая победа для файловой системы и базы данных для хранения / обслуживания изображений.
Alan Donnelly 20.11.2010 17:07:44

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

Сохраните только путь (и, возможно, информацию о файле) в базе данных.

1
6.08.2008 18:55:02

Я лично храню большие данные за пределами базы данных.

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

1
6.08.2008 17:41:26
ты имеешь ввиду внутри базы данных?
nickf 28.11.2008 05:46:16

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

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

14
6.08.2008 17:42:21

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

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

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

3
6.08.2008 17:51:00

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

11
6.08.2008 17:52:51

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

35
6.08.2008 17:59:59
Очень мило на самом деле. Теперь ваши пользователи могут легко увеличить ваше имя файла, чтобы получить доступ к другим файлам ...
Marijn Huizendveld 24.10.2010 17:53:14
@Marijn: Это только если вы выставите изображения миру.
Seun Osewa 26.11.2010 14:15:08
Мы сделали нечто очень похожее с нашими отображаемыми документами (наш первичный ключ - это составной ключ из трех элементов), но мы добавили дату и время сканирования документа, чтобы мы могли иметь несколько версий в одном каталоге.
Andrew Neely 4.08.2011 13:55:18
@ Osewa, Как это? Да, для прямого доступа к файлу конечному пользователю потребуется доступ к папке. У вас может быть процесс для обслуживания файла через FTP на основе запроса, и безопасность будет на уровне SQL-сервера.
Andrew Neely 4.08.2011 13:56:38

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

39
6.08.2008 18:17:52

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

17
6.08.2008 18:37:17
Абсолютно. Очевидно, база данных теперь намного больше. Наличие данных в базе данных означает, что репликация базы данных на разных сайтах также намного проще.
graham.reeds 12.03.2009 12:06:12
Я видел демонстрацию Oracle, где можно было смонтировать файловую систему в базу данных или что-то в этом роде. Знаете ли вы, что это то, что вы сделали? (Извините, я не разбираюсь в Oracle, поэтому, может быть, я говорю мусор.)
Stu Thompson 28.07.2009 08:33:21
Я так не думаю - это хранили изображения в базе данных как базу данных. База данных была агрессивно настроена - я помню многократные обсуждения относительно размера изображений, изменяющихся, поскольку поля были добавлены и удалены. Все было выровнено по границе.
graham.reeds 28.07.2009 09:52:44

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

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

27
6.08.2008 18:46:49
Я бы сказал, что база данных лучше подходит для файлов, которые часто редактируются, поскольку в этом случае может возникнуть проблема с согласованностью.
Seun Osewa 5.11.2010 01:40:54

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

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

  1. Капли на самом деле хранятся в виде файлов в папке.
  2. В Blobs можно получить с помощью либо соединения с базой данных или через файловую систему.
  3. Резервные копии интегрированы.
  4. Миграция "просто работает".

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

Из статьи MSDN:

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

56
26.07.2011 21:47:17
+1 для FileStream. На самом деле он сохраняет большие двоичные объекты в виде файлов на диске, но управляет ими транзакционно.
John Gietzen 26.07.2011 21:30:01
Кроме того, сервер SQL обеспечивает доступ к
John Gietzen 26.07.2011 21:30:59
Тем не менее, добавленная задержка между БД и веб-сервером ... И веб-сервер должен будет загрузить его в память, чтобы передать его клиенту, вместо того, чтобы передавать его с диска, если только вы не используете кеширование диска.
Lilith River 15.08.2011 21:14:55

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

3
6.08.2008 21:19:16

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

-1
6.08.2008 21:45:51

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

0
20.08.2008 18:15:08

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

Однажды общее решение этого состоит в том, чтобы объединить их в сбалансированное дерево подкаталогов.

25
20.08.2008 18:25:12
Вы бы так подумали, но проблемы на самом деле незначительные; У меня есть приложение с миллионами файлов в одном каталоге, к которому обращаются сотни пользователей, без проблем. Это не умно, но это работает. Самая большая проблема в том, что если вы используете Проводник для просмотра каталога, вы всегда смотрите на фонарик.
SqlACID 5.10.2008 13:07:00
Лучше использовать файловую систему, которая не имеет проблем с большими каталогами
Seun Osewa 29.10.2008 03:46:31
У меня было приложение с миллионами файлов в одном каталоге (сервер, на котором запущен RHEL 4) - даже для составления списка содержимого каталога (передачи в файл) потребовались дни, и был создан выходной файл размером 100 МБ. Теперь они находятся в базе данных. У меня есть один файл, который я могу легко переместить или создать резервную копию.
Richard 17.06.2009 15:24:16
@Seun Osewa: каждая файловая система имеет ограничения ... и если вы знаете одну, у которой нет проблем с хранением миллионов записей в одном каталоге, пожалуйста, дайте мне знать!
Guillaume 4.11.2010 12:51:04
@Seun Osewa: база данных до 28 ГБ, с 5,4 млн записей. В итоге мне пришлось разделить таблицу базы данных, чтобы у меня было несколько файлов для резервного копирования размером около 5 ГБ. Теперь я могу перенести отдельные изображения на Amazon S3, поэтому мне нужно только сохранить имя файла в БД (а Amazon может делать резервные копии). )
Richard 12.11.2010 07:41:36

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

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

99
20.08.2008 18:35:15
Dir_index от ext3 очень помогает.
Seun Osewa 5.05.2011 08:41:38

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

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

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

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

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

7
20.08.2008 18:42:14
При работе с репликацией хранение изображений в базе данных намного лучше IMO.
Beep beep 3.05.2009 20:26:00

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

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

1
20.08.2008 18:49:45

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

4
20.08.2008 18:51:56

Если вам нужно хранить много изображений в файловой системе, подумайте о следующих вещах:

  • Резервное копирование и восстановление. Как вы держите изображения в синхронизации.
  • Производительность файловой системы. Зависит от того, что вы делаете, и от файловой системы, но вы можете захотеть реализовать механизм хеширования, чтобы у вас не было ни одного каталога с миллиардами файлов.
  • Репликация. Вам нужно синхронизировать файлы между несколькими серверами?
1
22.08.2008 15:49:19

Выгрузка двоичных данных из вашей БД по проводам вызовет огромные задержки и не будет хорошо масштабироваться.

Сохраняйте пути в БД, и пусть ваш веб-сервер берет на себя нагрузку - это то, для чего он был разработан!

0
22.08.2008 16:08:52

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

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

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

  • Требовать дополнительный код для извлечения и потоковой передачи изображений
  • Задержка может быть медленнее, чем прямой доступ к файлам
  • Более тяжелая нагрузка на сервер базы данных
140
31.03.2011 22:43:38
Отсутствие отдельной стратегии резервного копирования может иметь большое значение, когда вы пишете приложения, установленные на месте (например, SharePoint). Когда вы создаете резервную копию SharePoint, все находится в БД, что делает ее очень простой.
Eric Schoonover 2.10.2008 23:40:58
Безопасность по неизвестности - это не стратегия контроля доступа!
Jon Cage 9.10.2008 10:46:25
Я не думаю, что он защищает безопасность неясностью - он говорит, что размещение изображений в БД добавляет еще один уровень безопасности. (Я думаю ... @ Конрад, не хочу вкладывать слова в рот)
AJ. 7.10.2010 09:06:26
Я выбрал хранение изображений в базе данных из-за единственного преимущества резервного копирования (или, вообще говоря, хранения всех данных в одном месте), но проблемы, о которых вы говорите, тоже верны, поэтому я кеширую изображения в файловой системе. Это лучшее из обоих миров, и я удивлен, что ни один из лучших ответов здесь не упоминает об этом.
Bart van Heukelom 1.05.2011 21:04:10
Вы случайно не используете библиотеку ImageResizing.Net для обработки кэширования образов дисков SQL->? Это самый продвинутый, масштабируемый и надежный дисковый кеш, который вы можете получить ...
Lilith River 15.08.2011 21:13:08

Нет, из-за разбиения страницы. По сути, вы определяете строки, которые могут иметь размер 1 КБ - n МБ, поэтому в вашей базе данных будет много пустых мест на страницах, что ухудшает производительность.

-1
22.08.2008 16:48:58

Файловая система, наверняка. Затем вы можете использовать все функциональные возможности ОС для работы с этими изображениями - резервные копии, веб-сервер, даже просто пакетные изменения сценариев с использованием таких инструментов, как imagemagic. Если вы храните их в БД, вам нужно написать собственный код для решения этих проблем.

0
28.08.2008 20:12:14

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

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

7
28.08.2008 21:37:10

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

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

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

Как и в большинстве случаев: «Это зависит от того, что вы делаете»

0
29.08.2008 23:04:07

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

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

0
30.08.2008 04:27:40

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

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

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

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

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

28
30.08.2008 09:50:23

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

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

2
30.08.2008 10:15:53

Хитрость в том, чтобы не стать фанатиком.

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

Нет.

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

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

31
31.08.2008 17:54:01
Я не вижу, чтобы кто-то утверждал, что файловая система работает быстрее, чем БД в 100% случаев (прочитайте ответ Марка Харрисона). Это немного соломенный Вероятно, бывают ситуации, когда предпочтительнее не пристегивать ремень безопасности, но, вообще говоря , носить ремень безопасности - хорошая идея.
Calvin 8.04.2009 16:56:49