LINUX.ORG.RU
ФорумTalks

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

 , ,


3

4

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

Тогда в расчёте на сотню символов в каталоге получаем среднюю вместимость 256*256*100 = 7млн. Дофига, 640к хватит для всех.

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

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

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

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

★★★★★

Последнее исправление: KRoN73 (всего исправлений: 1)

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

r_asian ★☆☆
()

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

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

geekless ★★
()
Последнее исправление: geekless (всего исправлений: 1)

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

stevejobs ★★★★☆
()

Можно:

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

Reaper ★★
()
Ответ на: комментарий от stevejobs

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Reaper

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

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

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

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от pacify

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Komintern

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Komintern

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

KRoN73 ★★★★★
() автор топика

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

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

nu11 ★★★★★
()

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

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

Reset ★★★★★
()

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

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

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от Valdor

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от nu11

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

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от sdio

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

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

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

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

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

KRoN73 ★★★★★
() автор топика

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от mv

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

KRoN73 ★★★★★
() автор топика

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

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

sdio ★★★★★
()
Ответ на: комментарий от stevejobs

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

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

Harald ★★★★★
()
Ответ на: комментарий от Harald

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

del /f/s/q directory_name > nul
rmdir /s/q directory_name
Работает в разы быстрее, чем просто рекурсивное удаление каталога. Она сначала рекурсивно удаляет все файлы (сохраняя всю структуру каталогов - остается пустой скелет, каталоги есть, файлов в них нет), и только потом уже рекурсивно удаляет сами каталоги. И особенно быстро это по сравнению с удалением из Проводника.

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

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

Harald ★★★★★
()
Ответ на: комментарий от Deleted

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

Deleted
()
Ответ на: комментарий от AnDoR

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

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

KRoN73 ★★★★★
() автор топика

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

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

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

swwwfactory ★★
()

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

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

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

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

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

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

drBatty ★★
()
Ответ на: комментарий от stevejobs

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

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

drBatty ★★
()
Ответ на: комментарий от KRoN73

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

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

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

drBatty ★★
()
Ответ на: комментарий от KRoN73

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

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

drBatty ★★
()
Ответ на: комментарий от nu11

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

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

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

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

drBatty ★★
()
Ответ на: комментарий от Reset

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

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

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.