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

Question

Когда вы сохраняете свои изображения (если у вас их много), вы сохраняете их как капли в базе данных или как файлы? Почему?

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

Answer 1

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

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

Answer 2

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

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

Answer 3

Я пытался использовать БД (SQL Server и MySQL) для хранения средних (<5 МБ) файлов, и я получил массу проблем. </p>

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

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

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

4) У некоторых веб-интерфейсов (ruby ActiveRecord) очень большие проблемы с BLOB-объектами.

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

Answer 4

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

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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