Хранение небольшого количества изображений: blob или fs?

Question

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

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

Что вы думаете о DB BLOB и файловой системе для этого сценария? Как клиенты работают с кэшированием изображений из БД и файловой системы?

Если большие двоичные объекты, хранящиеся в БД, - это то, что мне нужно знать - что мне нужно знать о , где , где их хранить? Поскольку я полагаю, что большинство моих пользователей не будут загружать изображение, я должен создать таблицу user_pics для (внешнего) соединения с обычной таблицей users при необходимости?

---

Edit: я снова открываю этот вопрос, потому что это не дубликат тех двух, с которыми вы связаны. Этот вопрос конкретно о плюсах / минусах использования БД или ФС для МАЛЕНЬКОГО числа изображений. Как я уже говорил выше, другой вопрос адресован людям, которым необходимо хранить тысячи и тысячи больших изображений.

Answer 1

Чтобы ответить на части вашего вопроса:

Как клиенты работают с кэшированием образов из БД по сравнению с файловой системой?

Для базы данных: иметь поле last_modified в вашей базе данных. Используйте заголовок Last-Modified HTTP, чтобы браузер клиента мог правильно кэшироваться. Обязательно отправляйте соответствующие ответы, когда браузер запрашивает изображение «если новее» (не может вспомнить, как оно называется; какой-то заголовок HTTP-запроса).

Для файловой системы: сделать то же самое, но с измененным временем файла.

Если большие двоичные объекты, хранящиеся в БД, - это путь - я должен знать что-нибудь о том, где их хранить? Поскольку я полагаю, что большинство моих пользователей не будут загружать изображение, следует ли мне создавать таблицу user_pics для (внешнего) соединения с таблицей обычных пользователей, когда это необходимо?

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

Answer 2

Однажды я столкнулся с подобным вопросом с небольшой DMS для PDF-файлов. Сценарий отличался от вашего: максимум 100 файлов размером до 10 МБ каждый - не то, что вы ожидаете от фотографий профиля. Но ответ, который дал мне друг, относится и к вашему делу:

Используйте каждую систему хранения для того, для чего она предназначена.

Сохранение данных в базе данных . Храните файлы в файловой системе .

Это не окончательный ответ (*), но хорошее правило для начинающих.

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

(*) Я знаю, я знаю, 42 ...

Answer 3

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

Answer 4

Я бы сохранил их в базе данных:

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

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

Answer 5

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

В Linux у вас есть больше возможностей. Здесь вы должны рассмотреть возможность перемещения больших файлов в файловую систему и просто сохранить имя в БД. Если вы используете современную файловую систему, такую ​​как Ext3 или ReiseFS, вы даже можете создать множество небольших файлов с довольно хорошей производительностью.

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

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

Answer 6

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

Если вы используете MSSQL, убедитесь, что BLOB-объекты хранятся в отдельном файле данных. Не в ПЕРВИЧНОМ, как все остальное.

Answer 7

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