Хранить большое количество изображений в базе данных?Хороший опыт?

Question

Я пишу приложение, которое будет хранить большое количество файлов изображений (и, возможно, видео). После загрузки они будут немедленно отправлены в какое-то облачное хранилище, обслуживающее CDN, для фактического предоставления публике. Идея состоит в том, чтобы хранить изображения в надежном резервном хранилище. Я бы ожидал порядка 200 000 объектов размером до 10 КБ каждый и, возможно, меньше видеофайлов на несколько МБ.

По умолчанию я бы отправился в Postgres, который в документации предполагает, что будет в порядке.

• Это разумная идея?
• Сделает ли резервное копирование базы данных полным кошмаром? Опыт?
• Есть проблемы с надежностью?
• Повлияет ли это на производительность других частей БД? Имейте в виду, что БД будет поражен только один или два раза для каждого изображения.

Answer 1

У меня есть опыт хранения изображений в базе данных таким способом в Oracle и MySQL.Производительность и надежность не являются проблемой.Резервное копирование есть.Ваша резервная копия станет очень большой.Поскольку резервное копирование требует много времени и средств, это может быть хорошей идеей для экономии места.Если это означает, что вы можете уменьшить свою базу данных на 80%, просто удалив изображения из базы данных, было бы неплохо хранить их в другом месте.Резервное копирование отдельных файлов более эффективно, поскольку вы можете легко создавать инкрементные резервные копии, содержащие только новые и измененные изображения.

Answer 2

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

Есть 3 аспекта или архитектурные соображения, которые могут помочь нам в нашем решении:

1. Унифицировать решение или нет? Сегодня, когда мы видим, что объем изображения (размеры и количество изображений) растут и растут, во всех приложениях «унифицированные решения» являются целью.Пример: Викимедиа - это унифицированное и специализированное решение для Википедии.
2. Прямое или косвенное хранение? Как старые "двойные решения", которые не сохраняют изображение в таблице SQLнекоторые решения могут использовать внешнюю базу данных или внешний указатель данных ... В PostgreSQL BLOB-типы данных имеют косвенное хранилище (создает отдельную резервную копию), а тип данных BYTEA является прямым (резервное копирование с таблицами).Выбор требует технических и эксплуатационных соображений.
3. Оригинальные или обработанные изображения? Нам нужно некоторое различие между «исходным изображением» и «обработанным изображением», например, миниатюрами, которые нуждаются в хранилище базы данных (для кэширования!), но не требуется резервное копирование.

Я рекомендую:

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

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

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

Answer 3

Мой опыт ограничен SQL-сервером, но у меня есть несколько миллионов PDF-файлов размером более 10 КБ в базе данных, которые все еще работают довольно хорошо. Конечно индексы обязательны. Полное резервное копирование базы данных занимает больше времени, чем ожидалось с таким количеством данных. Опять же, это для сервера MS-SQL!