Хранение файлов в БД – зло?
Сегодня я бы хотел рассмотреть один из вопросов поднятых недавно на форуме. Почему же так плохо хранить файлы в базе данных? Сейчас я постараюсь разложить все по полочкам, на примере MySQL(полагаю актуально и для других БД в той или иной мере), дабы больше такого желания не возникало)
Итак, BLOB (Binary Large Object – большой бинарный объект), который используется для хранения двоичных данных, таких как, картинки, архивы, программы и т.д.
Но почему, же использовать данный тип не желательно на практике? А все очень просто:
1) Быстрое раздутие БД – ведет к снижению производительности.
2) Большие объемы транзакций, что допускает длительные блокировки таблиц при вставках/обновлениях, особенно актуально при типах таблиц myISAM.
3) Более серьезные аппаратные требования к серверу баз данных.
4) Более дорогой шардинг в случае роста числа хранимых файлов.
5) Необходимость наличия отдельного обработчика, который бы реализовывал отдачу файлов, а именно отправлял нужные HTTP-заголовки в зависимости от типа хранимого файла.
По большей части это основные моменты, которые необходимо учитывать при принятии решения относительно хранения файлов в БД. Но решать, конечно, вам.
Надеюсь, данная заметка была для вас полезна =)
Loading ...
15 комментария к “Хранение файлов в БД – зло?”
Я в этом вообще не секу, но прочитал с интересом
Согласен на все 245.87%, нет файлам в базе =)Вообще наблюдается тенденция повышенного внимания к NOSQL системам, а файлы предназначенные для отдачи пользователям напрямую, стараются раздавать через легкие веб-сервера (nginx, lighttpd) etc.
Рад, что вам понравилось, буду стараться еще больше писать полезные и интересные посты =)
Так это на всех курсах по Mysql всегда говорят, что картинкам в Базе не место.
NatlieSEO :
Далеко не все имеют возможность посещать курсы.
С картинками понятно. А как насчет статей?
tigra60 :
А что с ними? Не совсем понятен вопрос.
Было дело… хранил файлы в базе. То же нормально работает.
Есть недочёты по скорости и всё такое… но нормально.
Тут компромис:
- базе долго
- в файле – нагрузка на io
В любом случае использовать кеширование nginx для статики.
Ну и потом важный вопрос: зачем файлы в базе?
Если это лого для дальнейшей массовой рассылки – то можно и в базе, а если аватара юзера, то на харде самое место.
Аокажи человека который станет пихать в БД файлы?
Вода течет по наименьшему сопротивлению.
ФАйл проще залить на хостинг нежели в Бд поэтому даже говнокодеры не станут такого делать.
Для чего тогда эту возможность ввели, если хранить в базе не эффективно?
По отношению к крупным проектам вопрос очень актуален – выскоие нагрузки на сервер, вероятность краха базы и так далее. но для небольших сайтов и блогов базы вполне удобны – легко разворачивать на любом хостинге при переносе сайта
Хранение бинарников в отдельных от базы файлах приводит к проблеме консистентности данных. Манипулируя записями о файлах(документах, картинках и т.д. нужно выполнять синхронные манипулиции с (нетранзакционной) файловой системой и наоборот. А если файл в БД прибили а на диске нет? Или наоборот с диска кто то удалил а в БД запись осталась. А как бакапировать и восстанавливать или переносить на другой сервер? А как быть с распределенной БД?
Хранение файлов в блобах обеспечивает консистентность данных средствами самой БД.
А для того чтобы объем не сказывался на быстродействии – просто вынести блобы в отдельную таблицу, точнее разделить таблицу с записями о файлах на две в отношении один к одному – поля с атрибутами для различных манипуляций и сам блоб (с полем ключа) и обращатся к нему только при выборке бинарных данных. В Mysql таблицы - отдельные файлы размер блобов на быстродействии не скажется. В других БД можно выносить таблицы с блобами в отдельные tablespace файлы который можно разместить вообще на другом винчестере.
Единственный минус, что касается картинок для вэба, это то что картинки апач будет читать не прямо с диска а из БД посредством выполнения php скрипта, что создаст дополнительную нагрузку на проц, что, правда, компенсируется более быстрым доступом к самому файлу, потому как БД более оптимизированны для поиска данных чем файловая системма.
Наиболее удобный вариант, конечно поля типа FILESTREAM как в MSSQL2005. С одной стороны запись с транзакционной таблице а с другой стороны фактически на файловой системе в оптимизированных для поиска и выборке структурах.
@ leon:
а попробуйте хранить в БД большие архивы или фильмы? Думаю, что на долго БД не хватит либо обслуживание такой БД выльется в копеечку=)
На самом деле существует очень немного ситуаций, когда хранение файлов в БД рентабельно.
Я представляю, если хостер ограничивает размер файла БД на вход, сколько кусков нужно будет сделать, при переносе базы. Не вижу ни какой гибкости. Я лучше напишу скрипт, который сделает дамп, запишет в архив файлы сайта и БД. Конечно я представляю случаи, когда файлам лучше храниться в БД, но это когда иначе сделать будет более затратно, полагаю такие случаи – исключения из правил.
Если хранить файлы в БД, то все равно некоторые будут храниться и в файловой системе (причем база тоже пишется на диск, так, что фактически файлы на диске). Думаю, это какой-то компромисс.
Хранение больших изображений таки влетает в копеечку. Естественно лучше применить другие сервизы, например мировой журнал.