Хранение изображений в PostgreSQL

postgresql image

115776 просмотра

6 ответа

13106 Репутация автора

Итак, я работаю над приложением, которое будет использовать серверную часть Linux, работающую на PostgreSQL, для передачи изображений в коробку Windows с интерфейсом, написанным на C # .NET, хотя интерфейс вряд ли имеет значение. Мой вопрос:

  • Каков наилучший способ хранения изображений в Postgres?

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

Автор: akdom Источник Размещён: 10.09.2008 03:55

Ответы (6)


26 плюса

3207 Репутация автора

В базе данных есть два варианта:

  • BYTEA. Хранит данные в столбце, экспортированном как часть резервной копии. Использует стандартные функции базы данных для сохранения и извлечения. Рекомендуется для ваших нужд.
  • сгустки. Сохраняет данные извне, обычно не экспортируется как часть резервной копии. Требует специальных функций базы данных для сохранения и извлечения.

В прошлом я с большим успехом использовал столбцы bytea, храня изображения размером более 10 ГБ с тысячами строк. Функциональность PG TOAST в значительной степени сводит на нет все преимущества, которые имеют BLOB-объекты. Вы должны будете включить столбцы метаданных в любом случае для имени файла, типа контента, измерений и т. Д.

Автор: jcoby Размещён: 10.09.2008 04:09

5 плюса

1419 Репутация автора

Попробуй это . Я использую большой двоичный объект (LOB) для хранения сгенерированных документов PDF, некоторые из которых имеют размер более 10 МБ, в базе данных, и это прекрасно работает.

Автор: Mike Reedell Размещён: 10.09.2008 04:11

16 плюса

25636 Репутация автора

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

оригинал

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

//linuxserver/images/imagexxx.jpg

тогда, возможно, вы сможете быстро настроить веб-сервер и сохранить URL-адреса веб-сайтов в базе данных (а также локальный путь). Хотя базы данных могут обрабатывать изображения больших объектов и 3000 изображений (4–6 мегапикселей, при условии, что изображение составляет 500 КБ), 1,5 гигабайта не так много, файловые системы пространства гораздо лучше разработаны для хранения больших файлов, чем база данных.

Автор: Kris Erickson Размещён: 10.09.2008 04:18

51 плюса

13853 Репутация автора

Re Jcoby's ответ:

Быть «нормальным» столбцом также означает, что значение полностью считывается в память при его извлечении. Blobs, напротив, вы можете перетекать в стандартный вывод. Это помогает уменьшить объем памяти сервера. Особенно, когда вы храните 4-6 изображений MPix.

Нет проблем с резервным копированием капель. pg_dump предоставляет опцию "-b" для включения больших объектов в резервную копию.

Итак, я предпочитаю использовать pg_lo_ *, вы можете догадаться.

Ре Крис Эриксон ответ:

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

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

Автор: Ivan Krechetov Размещён: 19.09.2008 06:21

54 плюса

5921 Репутация автора

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

Нам нужно некоторое различие между «исходным изображением» и «обработанным изображением», например миниатюрой.

Как говорится в ответе Джкоби, есть два варианта, поэтому я рекомендую:

  • используйте blob (Binary Large OBject): для хранения оригинального изображения, на вашем столе. См. Ответ Ивана (нет проблем с резервным копированием больших двоичных объектов!), Дополнительные модули PostgreSQL , инструкции и т. Д.

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

  • Используйте bytea (BYTE Array): для кэширования миниатюр изображений. Кэшируйте небольшие изображения, чтобы быстро отправлять их в веб-браузер (избегая проблем с рендеризацией) и сокращайте обработку на сервере Кэшируйте также важные метаданные, такие как ширина и высота. Кэширование базы данных - самый простой способ, но проверьте свои потребности и настройки сервера (например, модули Apache): лучше хранить миниатюры в файловой системе , сравнить производительность. Помните, что это (унифицированный) веб-сервис, который можно хранить в отдельной базе данных (без резервных копий), обслуживающей множество таблиц. См. Также руководство по двоичным типам данных PostgreSQL , тесты со столбцом bytea и т. Д.

ПРИМЕЧАНИЕ 1: сегодня использование «двойных решений» (база данных + файловая система) не рекомендуется (!). Есть много преимуществ использования «только базы данных» вместо двойного. PostgreSQL обладает сопоставимой производительностью и хорошими инструментами для экспорта / импорта / ввода / вывода.

ПРИМЕЧАНИЕ 2. Помните, что PostgreSQL имеет только bytea , но не имеет BLOB- объекта Oracle по умолчанию : «Стандарт SQL определяет (...) BLOB. Формат ввода отличается от bytea, но предоставляемые функции и операторы в основном одинаковы», Manual .


РЕДАКТИРОВАТЬ 2014 : Я не изменил исходный текст выше сегодня (мой ответ был 22 апреля '12, теперь с 14 голосами), я открываю ответ для ваших изменений (см. «Режим Wiki», вы можете редактировать!), Для корректуры и для обновлений .
Вопрос стабильный (ответ @ Ivans '08 с 19 голосами), пожалуйста, помогите улучшить этот текст.

Автор: Peter Krauss Размещён: 22.04.2012 11:51

20 плюса

1515 Репутация автора

Быстрое обновление до середины 2015 года:

Вы можете использовать интерфейс Postgres Foreign Data , чтобы хранить файлы в более подходящей базе данных. Например, поместите файлы в GridFS, которая является частью MongoDB. Затем используйте https://github.com/EnterpriseDB/mongo_fdw для доступа к нему в Postgres.

Это имеет то преимущество, что вы можете получить доступ / читать / писать / резервировать его в Postrgres и MongoDB, в зависимости от того, что дает вам больше гибкости.

Существуют также сторонние оболочки данных для файловых систем: https://wiki.postgresql.org/wiki/Foreign_data_wrappers#File_Wrappers

В качестве примера вы можете использовать этот: https://multicorn.readthedocs.org/en/latest/foreign-data-wrappers/fsfdw.html (краткий пример использования см. Здесь)

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

Автор: Kenyakorn Ketsombut Размещён: 01.06.2015 05:09
Вопросы из категории :
32x32