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

голоса
415

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

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

Задан 06/08/2008 в 18:38
источник пользователем
На других языках...                            


56 ответов

голоса
350

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

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

  • хранение базы данных, как правило, дороже, чем хранение файловой системы
  • вы можете супер-ускорение доступа к файловой системе со стандартным с полками продуктов
    • например, многие веб - сервера используют операционную систему SendFile () системный вызов асинхронно отправить файл непосредственно из файловой системы к сетевому интерфейсу. Изображения , хранящиеся в базе данных не выигрывают от этой оптимизации.
  • такие вещи, как веб-серверы, и т.д., не требуют специального кодирования или обработки для доступа к изображениям в файловой системе
  • базы данных победят, где целостность транзакций между изображением и метаданными имеют важное значение.
    • она более сложна в управлении целостностью между метаданными БД и данными файловой системы
    • это трудно (в контексте веб-приложения), чтобы гарантировать данные были записаны на диск в файловой системе
Ответил 06/08/2008 в 18:40
источник пользователем

голоса
140

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

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

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

  • Требуется дополнительный код для извлечения и потока изображений
  • Задержка может быть медленнее, чем прямой доступ к файлам
  • Тяжелее нагрузка на сервер базы данных
Ответил 22/08/2008 в 17:33
источник пользователем

голоса
99

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

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

Ответил 20/08/2008 в 19:35
источник пользователем

голоса
56

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

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

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

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

Из статьи MSDN:

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

Ответил 06/08/2008 в 21:15
источник пользователем

голоса
39

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

Ответил 06/08/2008 в 19:07
источник пользователем

голоса
35

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

Ответил 06/08/2008 в 18:59
источник пользователем

голоса
31

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

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

Нет.

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

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

Ответил 31/08/2008 в 18:54
источник пользователем

голоса
30

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

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

Ответил 19/02/2009 в 22:28
источник пользователем

голоса
28

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

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

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

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

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

Ответил 30/08/2008 в 10:50
источник пользователем

голоса
27

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

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

Ответил 06/08/2008 в 19:46
источник пользователем

голоса
26

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

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

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

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

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

Ответил 16/09/2008 в 21:28
источник пользователем

голоса
25

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

После того, как общее решение этой проблемы является хэш их в сбалансированное дерево подкаталогов.

Ответил 20/08/2008 в 19:25
источник пользователем

голоса
22

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

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

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

Ответил 28/11/2008 в 07:33
источник пользователем

голоса
20

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

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

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

Ответил 08/04/2009 в 17:35
источник пользователем

голоса
17

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

Ответил 06/08/2008 в 19:37
источник пользователем

голоса
14

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

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

Ответил 06/08/2008 в 18:42
источник пользователем

голоса
13

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

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

  1. Простота репликации и резервного копирования
  2. Возможность легко внедрить систему контроля версий документов
Ответил 26/10/2008 в 18:55
источник пользователем

голоса
11

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

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

Храните ваши файлы на платные услуги онлайн как

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

Эта нить объясняет , почему вы должны использовать 3rd поставщика сторона хостинга.

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

Ответил 18/05/2009 в 14:18
источник пользователем

голоса
11

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

Ответил 06/08/2008 в 18:52
источник пользователем

голоса
10

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

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

Ответил 02/09/2008 в 15:01
источник пользователем

голоса
7

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

Плюсы:

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

Минусы:

  • туздЫшпр в настоящее время занимает looooong времени, потому что есть 500MB файлы данных в одной из таблиц.
  • В целом не очень память / процессор эффективнее по сравнению с файловой системой

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

Ответил 08/12/2008 в 05:31
источник пользователем

голоса
7

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

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

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

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

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

Ответил 05/09/2008 в 11:54
источник пользователем

голоса
7

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

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

Ответил 28/08/2008 в 22:37
источник пользователем

голоса
7

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

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

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

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

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

Ответил 20/08/2008 в 19:42
источник пользователем

голоса
6

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

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

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

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

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

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

Ответил 02/09/2008 в 08:20
источник пользователем

голоса
4

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

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

Ответил 16/12/2009 в 15:29
источник пользователем

голоса
4

Я когда-то работал над приложением для обработки изображений. Мы хранятся загруженные изображения в каталоге, который был чем-то вроде / изображений / [текущая дата] / [номер документа]. Но мы также извлекаются метаданные (EXIF данных) из изображений и хранить, что в базе данных, а также с отметкой времени и тому подобное.

Ответил 20/08/2008 в 19:51
источник пользователем

голоса
3

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

+ VES:

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

-ves:

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

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

Ответил 18/05/2009 в 07:36
источник пользователем

голоса
3

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

Ответил 06/08/2008 в 22:19
источник пользователем

голоса
3

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

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

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

Ответил 06/08/2008 в 18:51
источник пользователем

голоса
2

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

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

Ответил 30/08/2008 в 11:15
источник пользователем

голоса
1

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

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

Вы можете посмотреть на WKT растр , который представляет собой проект , направленный на разработку растровый поддержку в PostGIS , которая в свою очередь , служит в качестве геопространственных расширения для PostgreSQL системы баз данных. Идея WKT Растр не только определить формат для растрового сериализации и хранения ( с использованием системы PostgreSQL), но, что гораздо важнее хранения, чтобы указать базу данных на стороне обработки изображения эффективной , доступной из SQL. Короче говоря, идея заключается в том , чтобы переместить операционный вес от клиента базы данных учетных записей, поэтому размещаются как можно ближе к хранению себя как можно. WKT растр, а PostGIS, является посвящает применение конкретной области, ГИС .

Для более полного обзора, проверьте веб - сайт и презентации (PDF) системы.

Ответил 03/02/2010 в 21:39
источник пользователем

голоса
1

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

  • Резервное копирование и восстановление. Как вы храните изображения в синхронизации.
  • производительность файловой системы. Зависит от того, что вы делаете, и файловая система, но вы можете реализовать механизм хэширования, так что у вас нет ни одного каталога с миллиардами файлов.
  • Репликация. Нужно ли вам сохранить файлы в синхронизации между несколькими серверами?
Ответил 22/08/2008 в 16:49
источник пользователем

голоса
1

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

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

Ответил 20/08/2008 в 19:49
источник пользователем

голоса
1

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

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

Ответил 06/08/2008 в 18:41
источник пользователем

голоса
1

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

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

Ответил 06/08/2008 в 18:40
источник пользователем

голоса
0

Я пойду как для решения, я имею в виду ... Я буду развивать LITLE компонент (EJB), которые хранят изображения в БД плюс путь этого образа в сервер. Эта БД будет обновляться, только если у нас есть новое изображение или исходное изображение он обновляется. Тогда я буду хранить путь в бизнес БД.

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

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

Ответил 26/01/2012 в 17:05
источник пользователем

голоса
0

Если вы находитесь на Teradata, то Teradata Developer Exchange имеет подробную статью о загрузке и извлечении LOBs и сгустков ..

http://developer.teradata.com/applications/articles/large-objects-part-1-loading

Ответил 27/09/2011 в 12:34
источник пользователем

голоса
0

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

Я имел приложение с большим количеством маленьких миниатюр (2Kb каждый). Когда я положил их на файловой системе, каждый из них потребляется 8Kb, из-за размера блока в файловой системе в. Увеличение 400% в космосе!

Смотрите этот пост для получения дополнительной информации о размере блока: Каков размер блока файловой системы iPhone?

Ответил 17/05/2011 в 10:15
источник пользователем

голоса
0

Я работал со многими цифровыми системами хранения данных и все они хранят цифровые объекты в файловой системе. Они, как правило, используют отраслевой подход, так что будет архив дерево в файловой системе, часто начиная с года ввода, например, 2009, подкаталог будет месяц, например, 8 за август, в следующий каталог будет день, например, 11, а иногда они будут использовать час, а файл будет называться с записями настойчивый ID. Использование BLOBS имеет свои преимущества, и я слышал об этом время часто используется в ИТ-части химической промышленности для хранения тысяч или миллионы фотографий и диаграмм. Это может обеспечить более детальную безопасность, единый метод резервного копирования, потенциально лучшую целостность данных и улучшенный поиск среди средств массовой информации, Oracle имеет много возможностей для этого в рамках пакета они привыкли называть Intermedia (я думаю, что это называется что-то еще сейчас). Файловая система также может иметь зернистые защиты, обеспечиваемые через систему, такие как XACML или другой объект безопасности типа XML. См D Пространство Fedora хранилища объектов для примеров.

Ответил 11/08/2009 в 12:27
источник пользователем

голоса
0

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

  • Перемещение изображения на другой раздел или на сервер только путем обновления глобальной конфигурации.
  • Найти запись, соответствующий изображению путем поиска по его первичному ключу.
  • Ваши изображения для инструментов, доступные для обработки как ImageMagick.
  • В веб-приложениях ваши изображения могут быть обработаны с помощью вашего веб-сервера непосредственно (экономия обработки).
  • CMS инструменты и веб-языки, такие как Coldfusion могут обрабатывать загрузки изначально.
Ответил 18/05/2009 в 14:36
источник пользователем

голоса
0

База данных

Файловая система для файлов

Ответил 02/03/2009 в 08:14
источник пользователем

голоса
0

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

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

Ответил 09/12/2008 в 20:51
источник пользователем

голоса
0

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

Ответил 02/09/2008 в 20:33
источник пользователем

голоса
0

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

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

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

Ответил 02/09/2008 в 17:15
источник пользователем

голоса
0

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

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

Ответил 30/08/2008 в 05:27
источник пользователем

голоса
0

Одна вещь, которую вы должны иметь в виду, размер набора данных. Я считаю, что Dillie-O был единственным, кто даже отдаленно попал в точку.

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

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

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

Ответил 30/08/2008 в 00:04
источник пользователем

голоса
0

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

Ответил 28/08/2008 в 21:12
источник пользователем

голоса
0

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

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

Ответил 22/08/2008 в 17:08
источник пользователем

голоса
0

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

Ответил 20/08/2008 в 19:15
источник пользователем

голоса
-1

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

Ответил 04/11/2008 в 21:30
источник пользователем

голоса
-1

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

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

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

Ответил 03/10/2008 в 00:33
источник пользователем

голоса
-1

В моем маленьком приложении у меня есть по крайней мере миллион файлов весом около 200GB на последнем счете. Все файлы сидят в файловой системе XFS, установленной на сервере Linux через ISCSI. Дорожки сохраняются в базе данных. использовать какое-то разумная именовании для путей файлов и имен файлов.

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

Ответил 15/09/2008 в 20:27
источник пользователем

голоса
-1

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

(Есть несколько других факторов, а также: Navision будет отображаться только ВМР, поэтому, когда я изменить его, я также конвертировать в BMP для хранения, а база данных реплицируется на удаленных объектах, где это полезно, чтобы иметь возможность отображать изображение печати. осуществляется только в головном офисе, так что я не нужно копировать исходный файл.)

Ответил 08/09/2008 в 20:51
источник пользователем

голоса
-1

Нет, из-за разбиения страниц. Вы по существу определения строк, которые могут быть 1KB - п MB так что ваша база данных будет иметь много пустых пространств в своих страницах, которая плохо сказывается на производительности.

Ответил 22/08/2008 в 17:48
источник пользователем

голоса
-1

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

Ответил 06/08/2008 в 22:45
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more