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

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

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

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

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

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

Ответ 1

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

Как клиенты идут с кешированием изображений из БД и из файловой системы?

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

Если вы находитесь на MSSQL, убедитесь, что капли хранятся в отдельном файле данных. Не в PRIMARY, как все остальное.

Ответ 5

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

БД оптимизирована для задержек, транзакций и т.д.

Хранение изображений оптимизировано с учетом задержки чтения, стоимости хранения и т.д.

Магазин BLOB-объектов идеально подходит для хранения миллионов изображений. Я работаю над SeaweedFS. Он был основан на дизайне Facebook для хранения своих пользовательских фотографий.