Сохранение изображений: файлы или капли?

Ответ 1

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

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

Ответ 2

Это зависит от размера изображения.

Microsoft Research имеет интересный документ по этому вопросу

Ответ 3

Я попытался использовать db (SQL Server и MySQL) для хранения файлов с содержанием (< 5mb), и то, что у меня было, было проблемой.

1) Некоторые DB (SQL Server Express) имеют ограничения по размеру;

2) Некоторые DB (MySQL) становятся смертельно медленными;

3) Когда вам нужно отобразить список объектов, если вы случайно сделали таблицу SELECT * FROM, тонны данных будут пытаться идти вверх и вниз от db, что приводит к аварийному медленному отклику или сбою памяти;

4) Некоторые интерфейсы (ruby ActiveRecord) имеют очень большие проблемы с манипуляциями с блоками.

Просто используйте файлы. Не храните их все в одном каталоге, используйте некоторую технику, чтобы разместить их на нескольких серверах (например, вы могли бы использовать последние два символа GUID или последние две цифры идентификатора int), а затем сохранить путь на db.

Ответ 4

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

Это обеспечивает лучшее из обоих миров:

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

Blobs могут быть тяжелыми на db/scripts, почему бы просто не хранить пути. Единственная причина, по которой мы когда-либо использовали blob-ы, - это то, что нужно объединить реплицированную или супер жесткую защиту для активов (как в cant pull-изображении, если вы не вошли в систему или что-то в этом роде)

Ответ 10

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

Использование файловой системы здесь выгодно, потому что  1. это дешевле  2. Использование CDN для быстрого доступа

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