Хранение большого кол-ва файлов: БД или диск?

Question

[VMConsult]

Приветствую всех!

Есть ~ 2 млн. файлов JPG, их нужно хорошо хранить, чтобы быстро и удобно. Нагрузка в пиках (2000 ранд. запросов/сек.)

1. Хранить на диске в разных папках md5 (linux, ext4)
2. Хранить в БД (key => value) (innodb, mysql)

Как будет быстрее и надежнее? или нет принципиальной разницы? я склоняюсь запихнуть все в базу.

Comments

[ShamblerR]

будет быстрей всего хранить их в 1 файле, тобиш как у цукерберга
файловая система ext4 создаем файл в размер диска, форматируем его (файл) под ext2 получаем все приемущества ext4 и ext2 при том обращение физически к файлу идет всего лишь к 1, поиск внутри файла идет значительно быстрей. Таким образом повышается скорость доступа к файлам, да и копировать их и бэкапить становится куда проще.
Все что остается тебе это смонтировать фаловую систему в папку.

[ShamblerR]

ShamblerR: да и ssd действительно при обращениях к фаулу работают в 50000 раз быстрее, поскольку физичеки не обладают головками!

[ShamblerR]

Mika Wow: фейсбук так работает.
Пример форматирования файла под файловую систему вам часто встречался и вы даже знаете програму которая с этими образами работает например демонтулс. В общем любая iso это и есть такой файл.

Answer 1

[BloodySucker]

БД куда медленее.
Советую вообще jfs, а не ext4.
JFS куда выше производительность выдает, а на мелких файлах и подавно.

Comments

[bobrovskyserg]

По JFS нельзя ли пруф? Сколь помню, JFS мало грузит проц - но и что с того? RaiserFS как раз грузит проц, но хороша именно на мелких файлах.

[BloodySucker]

bobrovskyserg: по JFS только личный опыт.
Intel Dual-Core 2.93GHz (mmx, sse, sse2, sse3 ssse3)
HDD

ext4 в среднем справляется с созданием файлов с random, 0 или полностью 1 или какими-то статическими данными (копирование) на 20% медленее, чем JFS.

[neol]

BloodySucker: А давно используете JFS? Какое ядро, дисковая система, параметры монтирования? По тестам в интернетиках и личным экспериментам (мягко говоря не сильно свежим), JFS производительностью совсем не блещет.

[BloodySucker]

neol: 4.0.4, gpt, noatime

Answer 2

[Сергей]

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

Comments

[mureevms]

Перефразирую. Если файлы умещаются в памяти, то имеет смысл использовать БД, иначе в файлы

[Сергей]

БД слишком тяжелая штука для такого дела. А так да, все верно.

[Максим Мосейчук]

Сергей: не обязательно использовать реляционные БД. NoSQL, или вообще какой-нибудь Redis отлично подойдут.

Answer 3

[Melkij]

Если по файлам не надо искать, а только читать по известному пути - то БД будет только лишним слоем абстракции. И если только не ставить оракл - то ещё будет бесполезно дублировать кэш операционной системы.
Просто размазать по директориям будет проще и вполне достаточно.
А если надо искать что-то по метаданным - то обычно метаданные пишутся в БД, а сами файлы всё равно лежат на диске, а не в БД.

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

Comments

[Дима Петрук]

вероятно facebook использует такую схему
https://www.facebook.com/notes/facebook-engineerin...

Answer 4

[Пума Тайланд]

Мудаки те кто запихивает картинки в базу. Раскидайте в трехуровневую иерархию папок их и даже на ext4 оно будет шустро бегать

Answer 5

[Константин Самилко]

Это не много.
1.В БД ты можешь хранить сам путь до них, если хочется возможности сортировки по каким-то параметрам и если планируется отдавать их через какое-то api или тип того.
2. Храните на диске. Но перед этим поставьте нечто, что будет кешировать (самые частые картинки) отданный материал nginx или squid. По файловой системе - озаботьтесь большим кол-вом inode и сортировкой файлов по папкам, а не одной кучей в одной папке.
Если планируется рост изображений, смотрите в сторону кластерных фс, чтобы не было узких мест, но с вашими размерами, хватит и одного диска.