Где хранить изображения: база данных vs файловая система(холивар)

на какую нибудь распределенную фс...

Зачем? Если вопрос в производительности, то проще по серверам раскидывать. Разложение по поддиректориям стандартный приём, глянь в кэш того же Squid-а. А логики не фиг и нужно. бери остатки от деления на 100(0x100) ID/UUID записи о файле в БД

и данные будут неконсистентны с базой? отлично.

и да, не вижу причин rm -rf * работать медленно... Во всяком случае не медленнее любой замороченной структуры с подкаталогами.

и да, не вижу причин rm -rf * работать медленно... Во всяком случае не медленнее любой замороченной структуры с подкаталогами.

А вот теперь попробуй.

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

насчет сквида - он я так понимаю строит некий btree поверх фс для более быстрого поиска. Не факт что он быстрее обычной фс будет, например той же btrfs. И да в вариантах выше совсем не это предлагалось.

обычная реализация rm -rf * по идее opendir/listdir/remove + повторение этих операций рекурсивно для каждого подкаталога. В обоих случаях работы сделать одинаково придется.

и да, я каждый день конечно же удаляю 50к файлов :)

бери остатки от деления на 100(0x100) ID/UUID записи о файле в БД

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

когда лучше использовать БД, а когда лучше фс?

ФС лучше использовать для проектов уровня «я и моя сраная собака на рыбалке», где небольшое число файлов (меньше миллиона). Как только файлов становится существенно больше и появляется иерархия директорий, это верный сигнал того, что ты пытаешься приспособить файловую систему для отображения «значения ключа на номер inode», с чем она справляется хреново. Появляется проблема «как бакапить все это говно» и, самое главное, «как быстро восстановить это говно из бакапа после падения».

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

Это что, «привет из 90-х»? До сих пор на vfat'е живешь чтоли?

Считаю, что решать, как эффективно хранить данные должен сторедж без связи с метаинформацией.

В твоём случае один фиг нужно контролировать уникальность имён файлов. А при отдаче их обратно клиенту, будешь терять информативность имени файла. Поэтому /XX/YY/ZZZZZZZZZZZZYYXX/myPhoto.jpg выглядит лучше чем ZZZZZZZZZZZZ

Появляется проблема «как бакапить все это говно» и, самое главное, «как быстро восстановить это говно из бакапа после падения».

и что же так изменило ситуацию? Так и хочется сказать «Бред сивой кобылы»

обычная реализация rm -rf * по идее opendir/listdir/remove + повторение этих операций рекурсивно для каждого подкаталога. В обоих случаях работы сделать одинаково придется.

Ты дико ошибаешься.

и да, я каждый день конечно же удаляю 50к файлов :)

Это не отменяет того, что быть далб..бом не надо, если можно всё сделать правильно.

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

Ты дико ошибаешься.

как аргументированно :)))

Это не отменяет того, что быть далб..бом не надо, если можно всё сделать правильно.

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

и что же так изменило ситуацию?

Даю тебе домашнее задание: набираем 40Gb файлами размером 100-500Kb в трехуровневой иерархии (xx/yy/zz/www.ext), затем создаем tar-архив этой директории без сжатия. А теперь замеряем время переноса этих файлов rsync'ом и время копирования tar-архива.

Перегружать твой очевидно нетренированный мозг вопросами: «а что будет, если структура директорий окажется такой большой, что не влезет в дисковый кеш?» — я не буду. Дорастешь — поймешь.

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

А в чём сильно разница?

• myfile.jpg --> /srv/bigstorage/ZZZZZZZZZZZZ
• myfile.jpg --> /srv/bigstorage/XX/YY/ZZZZZZZZYYXX/myfile.jpg

Xx и yy в базе поменялись, что ты будешь делать?

Перефразирую

• myfile.jpg --> /srv/bigstorage/ZZZZZZZZYYXX
• myfile.jpg --> /srv/bigstorage/XX/YY/ZZZZZZZZYYXX/myfile.jpg

VirRaa

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

ls можно, 20К строк сортануть и на первопне не проблема. Что до rm -rf -да, недостаток, файлы удаляются только по одному. А в каком методе нет недостатков? Найдёшь такой - закапаем всё остальное.

VirRaa

В связи с этим, считаю что доводить количество файлов до over 20K дурной тон, если можно разнести их по поддиректориям.

можно конечно и по директориям, вот только это очевидно дольше. И является дурным тоном, если только операция rm -rf не очень частая. А она как раз «не очень частая».

И да, никто не мешает сделать юзерофильное представление, что-бы удобно было твоим дельфином смотреть. Как CREATE VIEW. Просто наделай своих папок, и помести туда хардлинки.

VirRaa

Это не отменяет того, что быть далб..бом не надо, если можно всё сделать правильно.

это не отменяет того, что твой вариант правильный только в устаревших FS типа FAT & NTFS. Время доступа к произвольному файлу в EXT пропорционально O(log(N)), и если впихнуть туда каталоги, то будет только хуже и сложнее. Там и так дерево, и ваша надстройка, дерево над деревом будет только тормозить. Оставьте такие приёмы для FAT, которая хранит имена простым списком, и про деревья не знает.

Для всех объемных данных - фс. А БД только SQLite. И нечего тут обсуждать. Иначе - быдлокод.

moscwich

Для всех объемных данных - фс. А БД только SQLite.

ну если только SQLite, то да, там с этим хреново. Только ссылки на ФС можно.

Хранить-то фигня, вопрос как раздавать. С ФС можно очень эффективно раздавать статику nginx'ом или lighttpd. А с базы на каждый запрос к картинке надо соединяться с БД, вытаскивать ее оттуда, отдавать юзеру. Это огромный оверхед.

> Сложнее имхо придумать стуктуру хранения,

Современные веб-фреймворки это уже за тебя все давно придумали.

набираем 40Gb файлами размером 100-500Kb в трехуровневой иерархии

я правильно понимаю что одних только фотографий на 40 гиг ты планируешь положить в БД?

забавно, тебе мама в детстве разве не говорила, что так делают только мудаки?

Это огромный оверхед.

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

S3

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

myfile.jpg --> /srv/bigstorage/ZZZZZZZZYYXX

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

Тогда я где-то отчего далёк, можно ссылки для понимания

ну это больше имхо, но это простая логика: 1) каждый должен заниматься своим делом 2) не нужно все усложнять

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

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

С очень большим кол-вом файлов `man xargs`.

это уже за тебя все давно придумали.

Угу. Фреймворки-телепаты.

забавно, тебе мама в детстве разве не говорила, что так делают только мудаки?

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

И это в то время, когда я решаю хранить тексты, не помещающиеся в varchar (тексты статьи, например) в БД или выносить отдельно

Мудаки раскладывают миллионы файлов по тысячам директорий

В чем проблема, бро? Тегу img тебе один хрен надо будет конкретный URL скармливать, а значит ещё и скрипт писать, который этот блоб из БД вытащит и web-серверу отдаст.

Ты часом не пистонщик?

когда лучше использовать БД, а когда лучше фс?

всегда лучше ФС
</thread>

почему это самое херовое решение из возможных.

Почему?
Еще покажи проект, где ты разложил миллион файлов в один каталог.

А можно пруф?

Тоесть по твоему в треде есть верующие в бд которые могут удобно шардиться и бекапиться на таком объеме файлов?

а значит ещё и скрипт писать

Модуля к nginx хватит всем.

Еще покажи проект, где ты разложил миллион файлов в один каталог.

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

Я не пихаю по миллиону файлов в один каталог, и не пихаю миллионы файлов по тысячам директорий, потому что ФС для этого не предназначены.

Что правда в БД картинки держишь?
Какую БД используешь?
Ссылку на проект, я так полагаю ты не сможешь показать?

Вот смотри. Обращение к фс это сискол (open), сискол(реад), сискол(clos). Обращение к базе: сискол(socket) сискол(write) В базе: { сискол(read) сискол(read) с файловой системы) сискол(wite) ) сискол(read)

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

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

Предлагаю смотреть на ФС и БД, как на PHP и Python.

надежнее? Не надежнее ФС, на которой она находится. Статику проще с фс отдавать

не надёжнее, но удобнее - это раз.

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

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

далее индексация и оптимизация работы с памятью. в то время как ФС просто отдаёт файлы и атрибуты, задача БД - работать умнее и с учётом предпочтительных настроек.

далее, изоляция от юзерспейса. если в ФС кто-то поковыряется, то всю его индексацию придётся пересчитывать, а в БД обычный пользователь так просто не залезет и для БД скорее будут написаны специализированные средства автоматического поиска неисправностей заточенные под конкретную структуру.

---

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

А чем ФС не БД?

Подход с БД - на порядки надёжнее, чем с простой ФС.

чем надежнее? o.0

Предлагаю смотреть на ФС и БД, как на PHP и Python.

предлагаю смотреть на тебя как на говно, т.к. никогда не имел дела с объемами данных по 16Т и больше.

а ты, типа, имел, да? есть что показать? нету? а раз нету, то иди раскрывай свой унитаз где-то в другом месте.