Как лучше хранить много файлов — в базе данных или в виде файлов?

Question

[Fahrain]

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

Отсюда вопросы:

— где лучше хранить все эти файлы — в виде Blob/text в MySql или же в виде отдельных файлов на диске? Сами файлы напрямую клиентам отдаваться не будут — сначала они обрабатываются специальным php скриптом и только потом результат обработки отдается. Для каждого клиента результат может быть разным (а может быть и таким же)

— как лучше все это потом бэкапить? Есть подозрение что все эти тысячи файлов бэкапить будет тяжко, если не хранить их в базе данных…

Answer 1

[edogs]

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

В 99% случаев файлы лучше, т.к. к ним есть прямой и очевидный доступ без всяких баз, а база в любом случае прослойка.

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

По скорости/нагрузке, безусловно если это один сервер, то файлы будут побыстрее (только бейте на папки, не пихайте больше 1000 в одну в любом случае), но если у Вас несколько серверов, то отдельный сервак с базой под файлы может иметь определённые преимущества, доступ к базе по сети чуть более очевиден (хотя если у Вас есть админ, то не принципиально).

Файлы при прочих равных однозначно лучше попадают в кэш, с другой стороны засирание кэша базой проще контроллировать.

Comments

[Zelgadis]

Не совсем. На БД проще сделать HA и репликацию — абстракция от файлов же. Если делать на файлах то надо думать как сделать их доступными (если надо) и реплицию. Однако, если принять во внимание, что ФС это тоже БД то различия почти минимальны.

Может автору лучше вообще сам себе Amazon S3 сделать? или Luwak + Riak или CouchDB или Riak CS.

Answer 2

[Виталий Желтяков]

Единственное преимущество хранения файлов в БД, на которое нужно обратить внимание — это конкурентный доступ. То есть СУБД корректно обрабатывает одновременный доступ на изменение к одной и той же записи. Если конкурентный доступ маловероятен, то лучше использовать файлы.

Преимущество файлов:
— Бэкапить файлы не намного дольше, но восстанавливать можно по отдельным файлам, а не заливать весь дамп.
— Обращение к файлам и считывание быстрее, чем получение записи из БД (даже если используются сокеты).
— Кэширование файлов осуществляет автоматически ОС и сервер (можно использовать и опкэшер для контроля). А у СУБД кэширование больших файлов вызывает потерю производительности из-за вытеснения простых запросов из кэша.
— Количество файлов может быть очень большим без потери мощности сервера. У меня один раз хранилось около 12000 файлов в одной директории и ничего — сервер считывал без всяких задержек. Конечно вручную открыть эту папку было проблемно.
— Sphinx — свободно ищет по файлам.

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

Answer 3

[Сергей]

Когда у меня встала задача хранить 2млн HTML файлов, много чего перепробовал. Только у меня архив один раз формировался а потом в режиме read-only раздавался с помощью веб-сервера Tornado.

Остановился на SQLite + gzip. Т.е. создал таблицу с полями (name, blob) и каждый HTML сжимал в gzip.
В SQLite отключил синхронную запись для ускорения заполнения.
Успел попробовать bsd btree, bsd hash, gdbm, json-lines, csv ну и просто иерархия файлов на диске. Хотел попробовать tokyo cabinet, но не нашел драйверов для Python.
bsd btree в принципе сравнима с SQLite по скорости, но занимает больше места на диске и менее гибкое. json-lines занимает гораздо больше места, csv (и json тоже) нельзя упаковать в gzip и не поддерживает доступ по ключу.

Просто набор файлов на ФС — крайне неудобно для бэкапов и трудно с ними работать, например рекурсивное удаление занимает несколько часов.

gzip vs не gzip — однозначно gzip! Мало того, что «сжать в gzip и записать на диск» — быстрее чем просто «записать на диск», так ещё и место сэкономите.

Answer 4

[Vampiro]

— Странно, весь интернет хранит файлы на дисках и ничего. Если есть вариант, что MySQL будет хранить их не_на_диске, а где-то в другом месте, то, возможно, будет некий бонус. В остальном это лишние накладные расходы при каждом запросе.
— Никогда небыло проблемы с бекапом файлов. Есть туева хуча готовых утилит. И, кроме того, если вы планируете бекапить базу не методом бекапа её файлов, а поднимая слейв, то это еще больший гемор.

Comments

[Fahrain]

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

[Vampiro]

p.s.
посмотрите в сторону разбития этого табуна файлов на папки. Многие хостеры решают эту проблему создавая три папки по первым трем буквам в наименовании файла. Например, файл readme хранится в папке /temp/r/e/a/readme
Вы, кроме того, можете сделать папки для версий, и так далее.

БД все-равно сделает это (сохранит на диск).

Answer 5

[Vampiro]

:) Думаете, если 4гб фильм затискать в мускуль, его потом будет быстрее/поще скачать? С чего бы это? В базе он будет занимать больше места. Соответственно, объем бекапа также будет больше. И скачать его будет сложнее.

В целом, поиск измененных файлов и инкрементный бекап на файлах реализуется проще, чем выборка из Mysql, архивация дампа и скачивание.

Comments

[Fahrain]

файлы — html, размером порядка 1-2 мб максимум. Возможно даже пожатые gzip, я пока еще не решил

[Сергей Протько]

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

Answer 6

[serso]

На самом деле разница небольшая.
Скажу лишь о плюсах базы:
1. Файлы хранящиеся в базе не подвержены заражению вирусами
2. Полный программный контроль над файлами (отдача файлов по привилегии и т.д.)
3. (Oracle) Полнотекстовый поиск (например, в xml)

Comments

[serso]

4. Предполагаю, что повторное использование файла будет быстрее в БД (файл уже будет в памяти, не нужно заново открывать и считывать файл)

[Максим Обухов]

1. заражение вирусами это вообще непонятно из какой области аргумент, т.к. сами базы (например mysql) есть файлы, и вирусу который стирает всё равно, что стирать, например
2. про какие привилегии речь? привилегии СУБД? если привилегии будут определяться скриптом то без разницы где они лежат физически
4. в случае файловой системы часто используемый файл тоже будет закеширован в оперативку

Answer 7

[Алексей Гусейнов]

Если у вас html'ки, то есть текстовые фалйы, да еще если меняются не вильно отверсии к версии, то стоит рассмотреть хранение в файловой системе, а хранение старых версий в git.
Если же файлы меняются сильно, то я бы использовал ФС.

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

Но MySQL точно не для этого.

Answer 8

[Fahrain]

А магическое число в 1000 файлов на папку чем-то обосновано?

Comments

[edogs]

Отчасти.
Во-первых, эмпирически 1-3 тысячи файлов еще нормально, больше уже непропорциональные задержки (хотя с некоторыми ФС такой проблемы нет).
Во-вторых, фтп клиенты некоторые имеют именно такое ограничение на листинг.
В-третьих, бить-то как-то надо. А бить удобно «порядками» — по 10, по 100, по 1000, по 10000, по 100000 — что бы и наглядность сохранялась и логика, а тут именно 1000 оказывается оптимальным числом.

[DMakeev]

Я обычно бью не по количеству а по первым двум символам md5-хэша от имени или содержимого файла. Имеем равномерное распределение по 256 директориям. Если файлов планируется больше 100k, то имеет смысл ввести поддиректории из 3 и 4 символов, тогда нормально раскладывается порядка 50M файлов.

Answer 9

[artyomst]

как вариант — gridFS

Answer 10

[vsespb]

Согласен что лучше не хранить их в базе.

Кроме того что перечислили хочу заметить, что:

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

— если у вас файлы на диске а метаинформация о них в БД, тут нужно быть осторожным, нет транзакционной целостности. (некоторые люди даже предпочитают не смешивать БД и диск и хранить все данные только на диске, но это каждый конкретный случай нужно рассматривать отдельно)

Answer 11

[Fahrain]

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

Comments

[Сергей Федотов]

Кстати, файловая система — это тоже в некотором роде база данных.

Answer 12

[DMakeev]

«рекурсивное удаление занимает несколько часов» — по FTP удаляли?

Comments

[Сергей]

Если это ко мне вопрос, то нет. Простым rm -r. Что-то около 2млн файлов в иерархических директориях (точных цифр сейчас уже не вспомню).
В любом случае, SQLite файл удаляется / бэкапится моментально по сравнению с rm -r.

Answer 13

[Владислав Золотухин]

Все зависит от задач и от файловой системы на сервере. Так, в некоторых случаях ядро линукс для ext2 и ext3 имеет ограничение на количество директорий, а именно не более 32000 (''EXT2_LINK_MAX''' и '''EXT3_LINK_MAX''). Соотвественно, если Ваша система предназначена для использования на различных операционных системах и Вы не можете предвидеть на что ее будут устанавливать, советую хранить файлы в самой БД. Кроме того, это позволит избежать лишних проблем с мандатным доступом.