мало - фс, много - бд. /thread

мало это сколько примерно? иммет ли значение сам размер файла?

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

ФС, только ФС!

Всё зависит от объёмов и частоты использования. Но вполне нормально хранить изображения на отдельном файловом(-ых) сервере(-ах), а в БД только URL-ы

Больше задайся вопросом как хранить превьюшки и как их генерить.

Ты упорот или «много» у тебя - меньше миллиона.

ТСу: Только ФС.

Gridfs в mongodb же!

А что не HDFS сразу?

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

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

Только ФС. В базе - только линки.

Хранить файлы в базе — это диагноз

кстати, а при хранении большого числа файлов (тоже картинок) на ext4 в одной директории стоит ли ждать проблем? поделитесь опытом вообще как лучше организовать

Gridfs в mongodb же!

посмотрел. плюсую.

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

Где же тут холивар, если очевидно, что ФС.

кстати, а при хранении большого числа файлов (тоже картинок) на ext4 в одной директории стоит ли ждать проблем

Стоит.

А если я создам сайт с ололоФС, плюсанешь?

У меня /var/files/$id

А если я создам сайт с ололоФС, плюсанешь?

по результатам будет видно.

можно подробнее?

можно подробнее?

При большом количестве файлов в директории у тебя начнётся дикий тупняк. Большое количество - over 20k файлов. В связи с этим лучше генерировать поддиректории, на основе, например, user_id и прочих связанных с файлом ключей.

Я вообще на дропбоксе храню, потому что хостинг всего 100MB

как хранить превьюшки и как их генерить.

суффикс/префикс + mogrify -resize 32x32! :3

Ну ты же посмотришь на сайте, прочитаешь Getting Started, потом посоветуешь на ЛОРе. Я хорошо напишу странички, те боись.

спасибо, учту

А вот если похрен на производительность, то наверное в БД проще всего? Вопрос ко всем причатсным. Для нагруженных проектов понятно - хранить в ФС, отдавать nginx-ом.

А вот если похрен на производительность, то наверное в БД проще всего?

На БД ты линк прямой не дашь. Нужно делать обёртку, которая достанет из БД эту картинку, и отдаст ещё нужным типом.

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

Я вообще на дропбоксе храню, потому что хостинг всего 100MB

Превысишь чуть-чуть норму трафика и прикроют.

что ты посмотрел? Ты запусти монго, а потом когда у тебя объем под 10 Т будет скажи как оно работает.

В линупсе есть XFS и sendfile если чо.

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

А если веб приложение на нескольких машинах тогда NFS или что лучше?

xorik

Хранить файлы в базе — это диагноз

...или Шиндошс...

VirRaa

При большом количестве файлов в директории у тебя начнётся дикий тупняк. Большое количество - over 20k файлов.

шиндошс сервер? у меня Over1M, тупняков не вижу (конечно при редкой вставке/удалении, при частой 100К макс)

шиндошс сервер?

Да, бл.ть, на ext4. Очевидно же.

VirRaa

Да, бл.ть, на ext4. Очевидно же.

а с чего на 20к тупит тогда?

psp13

А если веб приложение на нескольких машинах тогда NFS или что лучше?

есть какие-то распределённые ФС. погуглите.

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

у нас че, какой-то сервер научился напрямую стримить из БД? Или вытаскивание через Ж с соответсвующими застратами на IPC?

база данных vs файловая система

Файловая система есть специализированная БД для блобов, с ограниченными возможностями: поиск только по явно заданному имени, малый набор хранимых данных(если не считать xattrs), и почти ничего сверх этого. Если тебе достаточно - пользуйся, нет - бери более навороченную.

а с чего на 20к тупит тогда?

Может именно на 20к и не тупит. Хотя я сомневаюсь, что в директории с таким кол-вом файлов можно уютно выполнить ls иди rm -rf *. В связи с этим, считаю что доводить количество файлов до over 20K дурной тон, если можно разнести их по поддиректориям.

При большом количестве файлов в директории у тебя начнётся дикий тупняк. Большое количество - over 20k файлов. В связи с этим лучше генерировать поддиректории, на основе, например, user_id и прочих связанных с файлом ключей.

Можно извратиться и так :)

http://api.yandex.ru/fotki/doc/concepts/About.xml

curl http://api-fotki.yandex.ru/api/users/alekna/photos/

похоже ls тупит из-за того, что оно делает stat для каждого файла, чтобы получить инфу (особенно если ls это алиас на ls --color). Простое получение содержимого файла по имени не должно тупить...

похоже ls тупит из-за того, что оно делает stat для каждого файла, чтобы получить инфу (особенно если ls это алиас на ls --color). Простое получение содержимого файла по имени не должно тупить...

И что мне легче, оставить алиас, или же не держать >20К файлов в директории?

В постгресе можно использовать Large Objects http://www.postgresql.org/docs/8.1/static/largeobjects.html

Вполне неплохо, но вот размер базы растёт очень уж быстро.

Может именно на 20к и не тупит. Хотя я сомневаюсь, что в директории с таким кол-вом файлов можно уютно выполнить ls иди rm -rf *. В связи с этим, считаю что доводить количество файлов до over 20K дурной тон, если можно разнести их по поддиректориям.

+1. Всё равно чаще в месте с изображениями хранится и мета информация, которую надо хранить в БД. Следовательно, есть ID/UUID и итоговый URL файла может быть http://img01.myserv.org/XX/YY/ZZZZZZZZZZZZYYXX/myPhoto.jpg

а зачем делать ls в папке с >20к файлами? ума не приложу если честно. Все выше написал только чтобы пояснить почему происходят тупняки.

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

Хорошо, а rm -rf *?