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

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

415
задан 8 revs, 5 users 57% 28 November 2008 в 05:41
поделиться

53 ответа

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

Профессионалы: Хранилища все в одном, легкий доступ к файлам данных, легким Недостаткам baskup: производительность базы данных Уменьшений, много расщеплений страницы, возможного повреждения базы данных

1
ответ дан GateKiller 28 November 2008 в 05:41
поделиться

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

существует несколько проблем:

  • устройство хранения данных базы данных является обычно более дорогим, чем устройство хранения данных файловой системы
  • , можно суперускорить доступ к файловой системе со стандартом от продуктов полки
    • , например, много веб-серверов используют операционную систему sendfile () системный вызов для асинхронной отправки файла непосредственно с файловой системы на сетевой интерфейс. Изображения, сохраненные в базе данных, не извлекают выгоду из этой оптимизации.
  • вещи как веб-серверы, и т.д., не нуждаются ни в каком специальном кодировании или обработке для доступа к изображениям в файловой системе
  • , базы данных побеждают, где целостность транзакций между изображением и метаданными важна.
    • это более сложно для управления целостностью между метаданными дб и данными файловой системы
    • , трудно (в контексте веб-приложения) гарантировать, что данные были сброшены к диску в файловой системе
350
ответ дан 6 revs, 4 users 64% 28 November 2008 в 05:41
поделиться

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

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

1
ответ дан 2 revs 28 November 2008 в 05:41
поделиться

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

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

1
ответ дан hometoast 28 November 2008 в 05:41
поделиться

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

  • Резервное копирование и восстановление. Как Вы сохраняете изображения в синхронизации.
  • производительность Файловой системы. Зависит от того, что Вы делаете и файловая система, но можно хотеть реализовать механизм хеширования так, чтобы у Вас не было единственного каталога с миллиардами файлов.
  • Репликация. Необходимо ли сохранить файлы в синхронизации между несколькими серверами?
1
ответ дан Brian Lyttle 28 November 2008 в 05:41
поделиться

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

0
ответ дан Gabriel Isenberg 28 November 2008 в 05:41
поделиться

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

пути Хранилища в DB и позволяют Вашему веб-серверу взять загрузку - это - то, для чего это было разработано!

0
ответ дан James Marshall 28 November 2008 в 05:41
поделиться

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

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

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

0
ответ дан Tim Howland 28 November 2008 в 05:41
поделиться

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

0
ответ дан Tammen Bruccoleri 28 November 2008 в 05:41
поделиться

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

-1
ответ дан Chris Miller 28 November 2008 в 05:41
поделиться

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

-1
ответ дан Quibblesome 28 November 2008 в 05:41
поделиться

В моем небольшом приложении у меня есть по крайней мере миллион файлов, взвешивающихся приблизительно в 200 ГБ, наконец рассчитывают. Все файлы находятся в файловой системе XFS, смонтированной на сервере Linux по iscsi. Пути хранятся в базе данных. используйте некоторое интеллектуальное соглашение о присвоении имен для своих путей к файлам и имен файлов.

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

-1
ответ дан siculars 28 November 2008 в 05:41
поделиться

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

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

-1
ответ дан Randy Orrison 28 November 2008 в 05:41
поделиться

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

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

Также рассматривают это при контакте с метаданными: если когда-либо необходимо обновлять атрибуты корпуса метаданных, DB является другом, поскольку можно быстро выполнить обновления с SQL. С другими системами меток у Вас нет легких инструментов манипулирования данными под рукой

-1
ответ дан David Robbins 28 November 2008 в 05:41
поделиться

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

3
ответ дан deadprogrammer 28 November 2008 в 05:41
поделиться

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

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

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

  • , Требуют, чтобы дополнительный код извлек и передал изображения потоком
  • , Задержка может быть медленнее, чем доступ файла прямого доступа
  • Более тяжелая нагрузка на сервер базы данных
140
ответ дан 2 revs, 2 users 97% 28 November 2008 в 05:41
поделиться

Хранилище файлов. У инженеров Facebook был большой разговор об этом. Каждый устраняет, должен был знать практический предел файлов в каталоге.

Иголка в стоге сена: Эффективное устройство хранения данных миллиардов фотографий

99
ответ дан jason saldo 28 November 2008 в 05:41
поделиться

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

FileStream решает большинство проблем вокруг того, чтобы хранить файлы в DB:

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

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

Из Статьи MSDN:

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

56
ответ дан 3 revs, 2 users 70% 28 November 2008 в 05:41
поделиться

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

39
ответ дан 2 revs 28 November 2008 в 05:41
поделиться

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

35
ответ дан Patrick McElhaney 28 November 2008 в 05:41
поделиться

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

, Как только общее решение этого должно хешировать их в сбалансированное дерево подкаталогов.

25
ответ дан John 28 November 2008 в 05:41
поделиться

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

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

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

3
ответ дан Jeff 28 November 2008 в 05:41
поделиться

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

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

27
ответ дан urini 28 November 2008 в 05:41
поделиться

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

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

14
ответ дан Michael Stum 28 November 2008 в 05:41
поделиться

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

4
ответ дан Thomas Owens 28 November 2008 в 05:41
поделиться

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

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

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

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

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

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

6
ответ дан 3 revs, 2 users 96% 28 November 2008 в 05:41
поделиться

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

17
ответ дан graham.reeds 28 November 2008 в 05:41
поделиться

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

IMO, Профессионалы использования базы данных для хранения изображений,

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

, Если Ваши изображения будут маленькими (говорят < 64k), и механизм устройства хранения данных Вашего дб поддерживает встроенный (в записи) БЛОБЫ, это улучшает производительность далее, поскольку никакая косвенность не требуется (Местность ссылки достигается).

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

7
ответ дан nikhilbelsare 28 November 2008 в 05:41
поделиться

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

11
ответ дан David 28 November 2008 в 05:41
поделиться

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

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

10
ответ дан a7drew 28 November 2008 в 05:41
поделиться
Другие вопросы по тегам:

Похожие вопросы: