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

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

Что вы думаете о плюсах / минусах?

415
задан 04.10.2019, 17:08

46 ответов

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

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

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

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

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

7
ответ дан 04.10.2019, 17:08
  • 1
    Когда контакт с репликацией, хранение изображений в базе данных являются намного превосходящим IMO. – Beep beep 04.10.2019, 17:09
  • 2
    .NET 4.5 зафиксировала это. – Fabian Vilers 10.10.2019, 16:13

Мы реализовали систему графического представления документов, которая хранит все, что это - изображения в полях блоба SQL2005. Существует несколько сотен ГБ в данный момент, и мы видим превосходное время отклика и минимальное снижение производительности. Кроме того, соответствие установленным требованиям франка, у нас есть слой промежуточного программного обеспечения, который архивирует недавно отправленные документы оптической системе устройства автоматической смены дисков, которая представляет их как стандартную файловую систему NTFS.

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

  1. Простота Репликации и Резервного копирования
  2. Способность легко реализовать систему управления версиями документа
13
ответ дан 04.10.2019, 17:09

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

11
ответ дан 04.10.2019, 17:09

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

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

10
ответ дан 04.10.2019, 17:10
  • 1
    +1 Это также позволяет, Вы для хранения исходного изображения, поставляя кэшировали/оптимизировали версию, позволяя размеру/сжатию быть измененными позже – Deebster 04.10.2019, 17:11

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

Профессионалы:

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

Недостатки:

  • mysqldump теперь занимает looooong время, потому что существует 500 МБ данных файла в одной из таблиц.
  • Полный не очень память/CPU, эффективная, когда по сравнению с файловой системой

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

7
ответ дан 04.10.2019, 17:11
  • 1
    Если Ваш Дельфи (2009 +, по крайней мере) установлен правильно, просто назовите rsvars.bat от своего пакетного файла, и это установит необходимую среду сборки Дельфи (что пакетный файл находится в папке мусорного ведра Дельфи, который обычно находится в пути в регулярной установке), – ciuly 09.10.2019, 20:44

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

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

7
ответ дан 04.10.2019, 17:11
  • 1
    Да, XE Дельфи создает объект Командной строки Studio RAD в меню "Пуск". Той командной строке установили переменные среды. Но I' m не на самом деле ввод вещей в окно командной строки. I' m выполнение пакетного файла из моего текстового редактора, таким образом, пакетный файл должен настроить среду. – Jan Goyvaerts 09.10.2019, 20:44

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

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

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

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

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

7
ответ дан 04.10.2019, 17:12
  • 1
    Нет ли никакой " Команда Studio RAD Prompt" в XE Дельфи? – ulrichb 09.10.2019, 20:44

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

17
ответ дан 04.10.2019, 17:13
  • 1
    Я don' t думают так - это хранило изображения в базе данных как база данных. База данных настойчиво настраивалась - я помню несколько обсуждений относительно размера изображений, изменяющихся, поскольку поля были добавлены и удалены. Все было выровненной границей. – graham.reeds 04.10.2019, 17:13
  • 2
    Я видел демонстрацию Oracle, где можение на самом деле монтирует файловую систему к базе данных или чему-то как этот. Вы знаете, является ли это тем, что Вы сделали? (Извините, я невежествен с Oracle поэтому, возможно, я говорю мусор.) – Stu Thompson 04.10.2019, 17:13
  • 3
    Абсолютно. По-видимому, база данных намного больше теперь. Наличие данных в базе данных означает, что тиражирование базы данных на различных сайтах намного легче также. – graham.reeds 04.10.2019, 17:14
  • 4
    и...? действительно ли это была хорошая идея? – paul 04.10.2019, 17:14
  • 5
    Я попробовал это, но it' s не действительно уведенный тогда. Можно все еще развернуть его с мышью. – Ben Reierson 26.11.2019, 04:06

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

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

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

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

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

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

6
ответ дан 04.10.2019, 17:13
  • 1
    сторонний доступ является ОЧЕНЬ положительной стороной – stoic 04.10.2019, 17:14
  • 2
    Установка GridViewColumn' s ширина к 0 эффективно скроет его. – Enrico Campidoglio 26.11.2019, 04:07

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

4
ответ дан 04.10.2019, 17:14
  • 1
    Я просто понял, что это только скрывает заголовок столбца и that' s, вероятно, не, что Вы хотели сделать. Я can' t находят любой способ скрыть целый столбец только с xaml кроме просто создания второго gridview. – Ben Reierson 26.11.2019, 04:07

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

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

14
ответ дан 04.10.2019, 17:15
  • 1
    Не, что OP, относительно которого попросили, но хороший для знания. (Лично I' d нравится делать столбцы действительно тонкими так it' s все еще возможный изменить размеры столбцов) – Qwertie 26.11.2019, 04:09

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

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

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

22
ответ дан 04.10.2019, 17:15
  • 1
    Вы don' t нужны одновременные обновления для имения проблем - это может быть чтение и запись. В нашем случае это, как почти гарантируют, произойдет. – Draemon 04.10.2019, 17:16
  • 2
    Какова вероятность наличия двух одновременных обновлений конкретного изображения? – Arafangion 04.10.2019, 17:16
  • 3
    Хороший. Скрывает заголовок только, оставляя ячейки видимыми. – bohdan_trotsenko 26.11.2019, 04:09

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

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

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

3
ответ дан 04.10.2019, 17:16
  • 1
    Я думаю you' право ре. Один способ избежать этого состоит в том, чтобы использовать ConditionalWeakTable вместо Словаря: msdn.microsoft.com/en-us/library/dd287757%28v=vs.100%29.aspx . Другая опция состоит в том, чтобы создать второе приложенное свойство для хранения исходной ширины. – surfen 26.11.2019, 04:09

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

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

25
ответ дан 04.10.2019, 17:17
  • 1
    @Seun Osewa: база данных составляет до 28 ГБ теперь с записями на 5,4 М. Я закончил тем, что имел необходимость разделить таблицу базы данных, таким образом, у меня есть несколько файлов для поддержки, которые составляют приблизительно 5 ГБ в размере. Переходить человека отображает на Amazon S3 теперь, таким образом, я только должен сохранить имя файла в DB (и Amazon может сделать резервные копии), – Richard 04.10.2019, 17:17
  • 2
    @Seun Osewa: каждая файловая система имеет ограничения... и если Вы знаете о том, который не имеет никаких проблем при хранении миллионов записей в том же каталоге, сообщите мне! – Guillaume 04.10.2019, 17:17
  • 3
    У меня было приложение с миллионами файлов в одном каталоге (сервер рабочий RHEL 4) - для ровного списка содержания каталога (передающий по каналу в файл) занял дни и создал выходной файл 100' s МБ в размере. Теперь они находятся в базе данных, у меня есть единственный файл, который я могу переместить или скопировать довольно легко. – Richard 04.10.2019, 17:18
  • 4
    It' s лучше для использования файловой системы, которая не имеет никакой проблемы с большими каталогами – Seun Osewa 04.10.2019, 17:18
  • 5
    Вы думали бы так, но проблемы на самом деле незначительны; у меня есть приложение с миллионами файлов в одном каталоге, к которому получают доступ сотни пользователей, без проблемы. It' s не умный, но это работает. Самая большая проблема - то, при использовании Проводника для просмотра каталога, Вы наблюдаете фонарь навсегда. – SqlACID 04.10.2019, 17:19
  • 6
    Разве это не пропустит память? Вы храните само управление в статическом словаре... – Rashack 26.11.2019, 04:10

Вот интересный отчет о теме.

К BLOB или Не К BLOB: устройство хранения данных Большого объекта в Базе данных или Файловой системе

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

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

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

26
ответ дан 04.10.2019, 17:17

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

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

27
ответ дан 04.10.2019, 17:18
  • 1
    Я утверждал бы, что база данных лучше для файлов, которые часто редактируются, так как непротиворечивость может быть проблемой в этом случае. – Seun Osewa 04.10.2019, 17:19
  • 2
    Работы как очарование. Спасибо! – Olwaro 26.11.2019, 04:09

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

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

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

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

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

28
ответ дан 04.10.2019, 17:19
  • 1
    Это решение не работает на меня. Когда я отладил, я узнал, что метод, UpdateListView называют первым и значение свойства IsVisible, добираются впоследствии. Я предполагаю, что это - причина в моем случае, но мне don' t знают почему? Кто-либо мог объяснить, почему это может произойти? – Pegieo 26.11.2019, 04:09

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

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

30
ответ дан 04.10.2019, 17:19
  • 1
    На самом деле, нет, Вы можете. Пока файлы изображений никогда не удаляются, изменяются или перезаписываются когда-то созданные, все файлы изображений синхронизируются прежде, чем попытаться фиксировать транзакции, нет никакого повреждения файловой системы, можно быть уверены, что файлы изображений и метаданные находятся в синхронизации. Для некоторых приложений те - слишком многие IFS, я предполагаю. – Seun Osewa 04.10.2019, 17:20
  • 2
    Я пошел бы еще больше и сказал бы, что с файловой системой Журналирования и некоторой дополнительной логикой программы, соответствие ACID может быть достигнуто. Шаги были бы записью запись дб, записать файл. Если файл фиксирует, фиксируйте транзакцию дб. – Andrew Neely 04.10.2019, 17:20
  • 3
    Это - лучшее решение I' ve, найденный до сих пор, и I' ve удалось заставить его работать с динамическим изменением свойства Visibile. См. мой ответ. It' s особенно полезный, если Вы хотите скрыть и более поздним шоу по умолчанию столбец при необходимости. – surfen 26.11.2019, 04:10

Прием здесь не должен становиться зилотом.

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

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

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

31
ответ дан 04.10.2019, 17:20
  • 1
    Я don' t видят, что любой утверждает, что файловая система быстрее, чем DB 100% времени (чтение Mark Harrison' s ответ). That' s что-то вроде strawman. Существуют, вероятно, ситуации в который it' s предпочтительный для не износа ремня безопасности, но вообще говоря, , нося ремень безопасности хорошая идея. – Calvin 04.10.2019, 17:20
  • 2
    моя реализация ожидает, что видимость столбца будет статична для загрузки - если Вы будете ожидать, что это изменится, однако, Вы, возможно, должны зафиксировать UpdateListView (), чтобы сделать что-то еще, чтобы скрыть и показать столбец (Width=0). – Ben McMillan 26.11.2019, 04:10

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

35
ответ дан 04.10.2019, 17:20
  • 1
    +1: UML не является заменой для кода. Можно попытаться добраться до " программирование с pictures" уровень детализации, но это doesn' t справка. – S.Lott 11.02.2009, 15:08
  • 2
    @Marijn: That' s, только если Вы подвергаете изображения миру. – Seun Osewa 04.10.2019, 17:21
  • 3
    Очень хороший действительно. Ваши пользователи могут теперь легко увеличить Ваше имя файла для доступа к другим файлам... – Marijn Huizendveld 04.10.2019, 17:21
  • 4
    ошеломите хорошие взгляды, я никогда не думал об этом. – Adam Ramadhan 04.10.2019, 17:22
  • 5
    @Osewa, How' s это? Да, для прямого доступа к файлу конечному пользователю был бы нужен доступ к папке. У Вас мог быть процесс для обслуживания файла через FTP, основанный на запросе, и безопасность будет на одном уровне с SQL-сервером. – Andrew Neely 04.10.2019, 17:22
  • 6
    Мы сделали что-то очень похожее на наши изображенные документы (наш первичный ключ является составным ключом трех объектов.), но мы добавили дату и время, документ был отсканирован так, чтобы у нас могло быть несколько версий в том же каталоге. – Andrew Neely 04.10.2019, 17:22

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

39
ответ дан 04.10.2019, 17:21

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

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

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

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

Из Статьи MSDN:

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

56
ответ дан 04.10.2019, 17:22
  • 1
    UML является несущественным; it' s просто нотация для коммуникации. Поля и стрелки достаточно. Реальный вопрос: " Как я могу сделать лучший дизайн? " ответ: Практика и извлекает уроки из Ваших плохих проектов; изучите хорошие проекты и эмулируйте их. – duffymo 15.11.2011, 15:22
  • 2
    Однако, добавленная задержка между DB и веб-сервером... И веб-сервер должен будет загрузить его в память для потоковой передачи его клиенту вместо способности передать его потоком от диска, если you' ре с помощью кэширования диска. – Lilith River 04.10.2019, 17:22
  • 3
    Кроме того, SQL-сервер позволяет блобам FileStream быть доступом непосредственно прочь диска, так, чтобы можно было постараться не связывать соединение с БД – John Gietzen 04.10.2019, 17:22
  • 4
    +1 для FileStream. Это на самом деле хранит блобы как файлы на диске, но управляет ими транзакционно. – John Gietzen 04.10.2019, 17:23

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

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

99
ответ дан 04.10.2019, 17:22
  • 1
    @duffymo, Как я могу сделать лучший дизайн с uml? – uzay95 08.08.2011, 13:43
  • 2
    ext3' s dir_index помогает много. – Seun Osewa 04.10.2019, 17:23

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

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

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

  • , Требуют, чтобы дополнительный код извлек и передал изображения потоком
  • , Задержка может быть медленнее, чем доступ файла прямого доступа
  • Более тяжелая нагрузка на сервер базы данных
140
ответ дан 04.10.2019, 17:23
  • 1
    UML не является тем же как техническими рисунками. Некоторые люди думают, что они должны быть; я думаю they' ре неправильно. – duffymo 11.02.2009, 15:21
  • 2
    Вы, случайно, с помощью ImageResizing. Сеть библиотека для обработки SQL-> кэширование образа диска? It' s самый усовершенствованный, масштабируемый, и устойчивый дисковый кэш можно добраться... – Lilith River 04.10.2019, 17:24
  • 3
    Я выбрал изображения хранения в базе данных из-за единственного резервного преимущества (или в более общем плане разговор, имея все данные в одном месте), но проблемы, которые Вы упоминаете, верны также, который является, почему я кэширую изображения в файловой системе. It' s лучший из обоих миров и I' m удивил, ни один из главных ответов здесь не упоминает его. – Bart van Heukelom 04.10.2019, 17:24
  • 4
    Я don' t думают he' s защита безопасности с помощью мрака - he' s говорящий, что помещение изображений в DB добавляет другой уровень безопасности. (Я думаю... @Conrad, don' t хотят поместить слова в Ваш рот), – AJ. 04.10.2019, 17:24
  • 5
    Безопасность с помощью мрака не является действительно стратегией управления доступом! – Jon Cage 04.10.2019, 17:25
  • 6
    Наличие отдельной стратегии резервного копирования может быть грандиозным предприятием, когда Вы пишете приложения, которые установлены по предпосылке (как SharePoint). При создании резервного копирования SharePoint, все находится в DB, который делает его очень легким. – Eric Schoonover 04.10.2019, 17:25

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

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

2
ответ дан 04.10.2019, 17:24

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

3
ответ дан 04.10.2019, 17:25

При планировании общедоступного веб-сайта направления тогда, Вы не должны идти ни с одной опцией. Ваш должен использовать Сеть доставки контента (CDN). Существует цена, масштабируемость и преимущества скорости для CDN при обеспечении большой суммы статического содержания по Интернету.

-1
ответ дан 04.10.2019, 17:25
  • 1
    Попробуйте что-то как WebClient. DownloadString (" yoursite/" ) в цикле... в нескольких потоках =) – Denis Parchenko 08.10.2019, 01:11

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

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

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

-1
ответ дан 04.10.2019, 17:26
  • 1
    @Cray: Я посмотрю вовремя - извините не имеют времени теперь, но требуемый для ответа в случае, если оно разблокировало Вас. Основной момент моего сообщения должен сказать " это исключение предполагает помещение дублирующегося набора или Привязки в ядро так или иначе, возможно, путем инициализации дважды в тот же kernel" неважно, где Вы получили код и независимо от того, представляет ли Ваш вопрос точное отражение Вашего фактического кода, который перестал работать. (Я сделал нуль с RTM NI2, но партии с различными пред2 сборками), – Ruben Bartelink 08.10.2019, 01:09

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

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

-1
ответ дан 04.10.2019, 17:27

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

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

-1
ответ дан 04.10.2019, 17:27
  • 1
    Потрясающий! Это - большие новости. Контакт с ним самостоятельно. Спасибо за предоставление этого ответа, Steve! – John Nelson 08.10.2019, 01:10

Теги

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