Мысли вслух. Предостережение от наступления на грабли.

Спасибо, дядя. Тоже часто md5-измом страдаю.

Теперь, вот, придётся переделывать на логику YYYY/MM или даже YYYY/MM/DD.

Вот нет чтобы сразу нормально сделать. Зря что ли отцы-основатели твердили про человекочитаемые данные.

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

Можно:

а) выделить раздел, делать бэкап посекторно всего раздела
б) бэкапить файлы инкрементально каким-нибудь рсинком
в) закинуть всё в скулайт
г) использовать key-value storage

посмотри cassandra, hbase, elliptics

https://github.com/reverbrain
https://github.com/lmovsesjan/elliptics-fastcgi

их пробовал Reset. пилит это поделие (elliptics) какой-то человек из Яндекса

На линуксе такая магия работает, не в курсе?

Не знаю. Я удаляю файлы только выборочно, при чистке кешей по устареванию. И там — да, сперва проходишь по файлам, потом грохаешь пустые каталоги :) Очистка моих типовых 7..10Гб кешей длится около часа. Надо отдельной cron-задачей пускать, а то общий скрипт ночной работы сильно затягивается. Сегодня заметил, что при запуске в 4 часа ночи он заканчивает работу к 9 утра (там много ещё тяжёлых подобных задач, идущих с низким приоритетом). Из-за этого дамп БД, который на 10 минут кладёт форумы, выполняется не в 5..6 утра, как планировалось (когда народа почти нет), а в 8:45..9:00, когда народ уже просыпается :)

выделить раздел, делать бэкап посекторно всего раздела

Не катит. Раздел постоянно меняется.

бэкапить файлы инкрементально каким-нибудь рсинком

Вот описанная выше проблема, как раз, с rsync'ом :) Скажем, я запустил процесс ещё до того, как открыл эту тему. Длится он до сих пор…

закинуть всё в скулайт
использовать key-value storage

85Гб? И дёргать sqlite/key-value по каждому статическому запросу, отдавая гигабайты через скрипты? :D

посмотри cassandra, hbase, elliptics

А смысл вводить ещё одну прослойку до ФС?

Суть, как раз, в быстрой отдаче статики. Вопрос бэкапа тут вторичен.

я бы по возможности потестил в этой ситуации ZFS и бекап через снапшоты.

ZFS под Linux… fuse под высокой нагрузкой… это слишком тонкое извращение для меня :)

В любом случае это всё попытки обойти изначально неудачное архитектурное решение. Пост именно об этом :)

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

под фрю конечно же!

под фрю конечно же!

Ню-ню :)

я серьезно, в девятке ZFS работает шикарно.

Я не про ZFS. Я про саму Фрю :)

получасовую
несколько сот тысяч

Может я не понимаю чего-то, но что не так?

кидаем в пару подкаталогов по первым двум символам

плохая затея. Не хочу лезть в матан, но если у мд5 частотное распределение в первых символах более-менее равномерное, то с таким подходом у тебя практически на каждый файл получится отдельный подкаталог. В итоге вместо горы файлов имеешь такую же гору каталогов, да еще и +2 лишних инода на файл в придачу.
Тут нужна золотая середина, при которой в каталоге лежит вменяемое число файлов, при котором ФС еще не встает раком. Думаю в районе 10к можно попробовать для начала. А уж по каким признакам распределять, так это конкретный случай смотреть нужно, по каким признакам файл нужно искать в этой свалке.

ФС и винты тогда были неторопливые, так что надо раскидывать по подкаталогам

когда будут миллионы ext3/ext4 ляжет

Решение очевидно — делаем md5 от уникальных атрибутов файла (скажем, имя, время загрузки, pid загрузки) и кидаем в пару подкаталогов по первым двум символам. Типа ./f4/0e/f40e7bff300851a3554dda25e28af470.jpg

Решение совсем не очевидное, разве что, где-то ведется база соответствий таких файлов «f40e7bff300851a3554dda25e28af470.jpg» с их исходными метаданными, но тогда и дата создания файла там же должна бы храниться

Может я не понимаю чего-то, но что не так?

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

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

то с таким подходом у тебя практически на каждый файл получится отдельный подкаталог

Именно так изначально и задумывалось.

В итоге вместо горы файлов имеешь такую же гору каталогов, да еще и +2 лишних инода на файл в придачу.

И проблемы в этом не было, пока не потребовалось сканировать каталоги :) Т.е. пока идёт работа прочитать/записать — всё прекрасно. Как только начинаем сканировать — начинается ад.

разве что, где-то ведется база соответствий таких файлов

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

Проще сразу делать прямо.

конечно проще, только решишь проблему бэкапа, вылезет другая проблема. Надо линками (если базой нельзя пользоваться) создавать разные структуры (иерархии по дате, по имени, по mime-типу, ...) лишь бы inodе-ов хватило

Надо линками (если базой нельзя пользоваться) создавать разные структуры (иерархии по дате, по имени, по mime-типу, ...)

Зачем? Этого и в исходном варианте не было, а если зачем-то будет нужно, то исходный вариант не помощник.

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

Интуитивно кажется, что будет не очень, но интересны реальные цифры

Достаточно сказать, что lighttpd/nginx непосредственно с диска могут отдавать 17..22 тыс. мелких файлов в секунду. Никакая из скриптовых обёрток не выдаст и трети этой скорости без обращения к БД и едва ли десятую часть этой скорости с обращением :) Это не считая вопросов загрузки процессора, памяти…

lvm snapshot

lvm snapshot

И тягать потом 85Гб при каждом бэкапе? o_O

Нет, снапшоты инкрементальные.

Хм. Тогда можно подумать. Но всё равно вариант с rsync на нормальной организации предпочтительнее :)

Я не понял смысла этой темы. Предостережение от неправильного дизайна? Ну это даже К.О. плачет от очевидности.

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

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

эмм, оно везде только так и работает, каталог нельзя удалить, пока он непустой

нед. Вот такая команда:

del /f/s/q directory_name > nul
rmdir /s/q directory_name

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

когда будут миллионы ext3/ext4 ляжет

Это у тебя как обычно теория или всё же практика? :)

практика

У меня почему-то практика показывает, что не ложится :)

Запись начинает падать до десятков файлов в секунду. По мне это ложится. Нормально работают с миллионами файлов только btrfs и zfs (под FreeBSD).

А, а я уж думал, что ты вспомнил древний баг ext2 ;) У ext4 всё гораздо лучше. чем у ext3.

Не лучше. Там основной затык в записи журнала.

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

reiserfs смотрит на эту фразу с удивлением.

тесты проводил?

reiserfs смотрит на эту фразу с удивлением.

По-моему, назрела новая серия тестов. Есть у меня подозрение, что сегодня ext4 работает не так радужно, как пару лет назад.

т.е. новый вариант хэширования каталогов будет выглядеть так:
YYYY/MM/DD/f40e7bff300851a3554dda25e28af470.jpg

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

Узкое место в том, чтоб в «интервале хэширования» не было миллиона аттачей. В этом случае придется комбинировать со старой схемой или по часам:
YYYY/MM/DD/f4/0e/f40e7bff300851a3554dda25e28af470.jpg
YYYY/MM/DD/HH/f40e7bff300851a3554dda25e28af470.jpg

Решение очевидно — делаем md5 от уникальных атрибутов файла (скажем, имя, время загрузки, pid загрузки) и кидаем в пару подкаталогов по первым двум символам. Типа ./f4/0e/f40e7bff300851a3554dda25e28af470.jpg

глупо. ФС (EXT*) и сама точно так и делает - составляет дерево хешей. Зачем ты делаешь масляное масло? Или речь про FAT?

Так оно и есть, блин. Вот только бэкап такой хрени с боевой машины вылился в получасовую операцию. Если не больше. При 100% загрузке io.

считать хеш от хеша действительно глупо. Особенно тормозную md5.

Такие, вот, грабли…

дурная голова ногам покоя не даёт.

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

в линуксе только так и можно - сначала файлы, а потом каталоги. Удалить можно только каталог без файлов. А вот что касается - сначала все файлы, а потом все каталоги, то разница не должна быть больше 10%, причём не очевидно, в какую сторону. Попробуй...

Не катит. Раздел постоянно меняется.

Из-за этого дамп БД, который на 10 минут кладёт форумы

возможно дамп раздела положит форумы на 1 минуту, что таки лучше 10 минут.

А смысл вводить ещё одну прослойку до ФС?

тебе намекают, что прослойка от профессионала возможно будет более удачнее твоей на баше с md5.

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

именно так. у него будет 256 каталогов (0x00..0xFF), в каждом 256 подкаталогов, и в каждом 1.5 файла(точнее 1.5258789062 на каждые 100 000 файлов).

Тут нужна золотая середина

еслиб ты полез в матан, то тут действительно нужна середина, и для M ступенчатой структуры из N эл-ов нужно ровно N**(1/M) элементов в каждой ступени. Т.е. для 64К эл-ов и 2х ступеней надо 256 каталогов с 256ю фалами. Вот только, создатели ФС сам знают матан, и всё это УЖЕ сделали. Единственное, это пригодится для быстрого УДАЛЕНИЯ любого файла. Ибо время удаления/создания пропорционально размеру каталога. В двухступенчатой системе оно очевидно в sqrt(N) раз меньше.

когда будут миллионы ext3/ext4 ляжет

не ляжет. УМВР.