Файловая система для авaтарок?

Question

[vgrayster]

Стоит задача хранения, сотен тысяч мелких изображений, в базе не хочу хранить. В ext3 тоже не хочу. Что посоветуете? Может есть какой демон или файлоая система которая это предназначена для этого?

Answer 1

[vgrayster]

Гугл ничего не выдает, наверное готового нету. Пока на коленке родилось следующее решение.

1) В основной базе (mysql) храним всю мета информацию + ключ для картинки. Ключом является (имя файла sqlite + id)

2) Есть куча небольших (100-200мб) файлов sqlite в которых в блобах хранятся изображения.

Так как запись идет append only и предыдущие не будет меняться — то в ежедневный бекап будет попадать только последний sqlite файл.

Что скажите? бред?

Comments

[Антон Корзунов]

самое то. Но истина вскроется в деталях

[bit]

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

[vgrayster]

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

[vgrayster]

вообщем реализовал этот велосипед, тестовая запись пошла. как несколько тыс картинок будет так попробую протестировать это решение на производительность по чтению.

Answer 2

[Антон Корзунов]

А бы я честно посоветовал бы базу, недавно копировал свои эти самые «маленькие изображения» — 600к их там — заняло день. А дел то было — толи на два, толи на три гига
Еще отчень хорошо отрабатывала tarfs — но она совсем реадонли

Comments

[vgrayster]

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

[Антон Корзунов]

100к аваторок по 15к кб == 1.5G +30% возможной фрагментации базы
за минуту перегоним. Ладно ладно — за пять минут…

После чего заходим в папку с кучей директорий и файлов и говорим — такс — у всех проверить mtile и найти чего и как по сравнению с that папкой…
И идем на обед…
Могу доказать свою правоту — попробуйте создать хотя бы 10к мелких файлов.
И попробуйте сделать — tar на нее, или просто попробуйте ее стереть

[vgrayster]

Не очень понял Ваш пост, но

1) У меня система архивирования устроена таким образом, что 90% бекапов — это инкрементальные, те в бекап кладутся только изменившиеся файлы. В случае с базой — бакап будет считать что изменилась вся база и каждый день будет бекапить полтора гига.

2) 10k файлов в одном каталоге — это самоубийство. обычно делают хеширование те 34873987.jpg -> 34/87/39/87.jpg

[Archon]

Базу можно реплицировать. Чем не бекап?

[vgrayster]

Можно и реплицировать, но при текущей схеме хранения ( я использую бакулу) я могу вернуть базу в состояние в котором она была в любой из последних 30 дней. А с реплицированием это сложнее.

[Антон Корзунов]

такс, отвечаю по порядку.
1. да никто не делает кучу файлов в одной папке. лично я делаю md5 от имени и по первым 4м буквам создаю два уровня вложености.
Но в любом случае рсинку чтобы найти изменения потребуется ОБОЙТИ ВСЕ ПАПКИ и проверить файлы. Копировать то он будет инкрементально, только во скан никто не отменял.
Кстати — если вы базу будете дампить — рсинг инкрементально перенесет только НОВЫЕ записи в sql дампе.
2.Можно и реплицировать, можно и фиксировать текущую позицию в реплике.
И в ЛЮБОЙ момент откатиться до любой из таких точек.

[bit]

Если все операции выкладки-удаления картинок логируются — обходится всего один файл — лог.

[Антон Корзунов]

так не честно — топик про другой слой обработки :)

[Wott]

А делать инкрементальный бэкап базы религия не позволяет?

[Wott]

Только обязательно надо разнести таблицу с содержимым и с мета, иначе выборки просадят базу не по детски.

[vgrayster]

Давайте обойдемся без религий. Текущая система бекапа полностью устраивает. Она не делает инкрементальный бэкап базы. Система бекапа оперирует только файлами. Хоть один байт изменился, значит нужно бекапить весь файл.

У вас есть опыт восстановления базы из архива с инкрементальным бекапом базы? Расскажие пожалуйста, что-то у меня впечатление что этот процесс совсем не тривиальный.

[Антон Корзунов]

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

Answer 3

[great_boba]

давным давно ответом на этот вопрос мог быть reiserfs

Answer 4

[fallen]

Btrfs + хранение нескольких картинок в одном файле и указанием позиции в урл или еще где. Почитайте про архитектуру facebook и контакта, там много полезной информации.

Comments

[vgrayster]

Про фейсбук читал, так как раз и используется «хранение нескольких картинок в одном файле». Интерисует какие готовые решения для этого есть?

Answer 5

[Dmitry Dedukhin]

Задумайтесь о том, что аватарки — это скорее всего много запросов на чтение.
При отдаче их из базы вы будете насиловать дисковую подсистему, в то время как при отдаче с диска _все_ аватарки (в зависимости от объема памяти сервера) могут быть закешированы системой в памяти и их отдача будет турбореактивной.

Comments

[Антон Корзунов]

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

У меня был опыт по отдаче очень большого обьема очень большого количесва файлов.
Так вот — с диска — сосет.
Из базы — летает. Разница порядка 70(!!!) процентов.
В основном потому что нет инодов, а поиск по «умному»(в отличие от инод) ключу.

[Dmitry Dedukhin]

Также как кеш нгинкса какого либо.
Если что, nginx кеширует на диске, и тогда какой смысл хранить в базе, а кешировать на диске?

Делается как модулем, так и встроеным перлом.
Делать из nginx'а запрос в базу — это то еще извращение.

Так вот — с диска — сосет.
Чем раздавали с диска? Использовало ли оно sendfile?

[vgrayster]

>Делать из nginx'а запрос в базу — это то еще извращение.

Почему? там всего один запрос вида select ***, зачем для этого лишный процесси запускать? Не очень красиво — это да, но при нагрузках дает экономию.

[Dmitry Dedukhin]

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

Answer 6

[Сергей]

Картинки нужно хранить на жёстком диске и никакая база данных тут не подойдёт т.к. создаётся неоправданная нагрузка на сервер. А вот насчёт как именно хранить, я бы рекомендовал разбивать на подпапки по id-фото таким образом: если фоток < 100k, то достаточно /ff/32123e21.jpg. Если > 100k && < 2m, то /ff/ff/321312312.jpg, ну и c /ff/ff/ff/321312312.jpg можно сразу в космос…

Comments

[vgrayster]

А почему facebook перешел на хранение много картинок в одном файле?

[Сергей]

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

И вообще в чём проблема в файлах хранить, можете пояснить? Если вас уж так тянет на изврат, то попробуйте Amazon S3 — там уж точно никаких ограничений и проблем с доступом не будет.

[Dmitry Dedukhin]

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

[bit]

Одна из возможных причин — экономия места на диске. Место под файл выделяется блоками. Последний блок, где «хвостик» файла — часто полупустой. Много мелких файлов — много таких полупустых блоков. Жаба душит столько места терять :)
Если у вас есть файловое хранилище с кучей мелких файлов — проведите эксперимент — подсчитайте их общую «массу» и сравните с показаниями системы о занимаемом месте на диске. Чем мельче файлы, тем больше разница. Мелкие аватарки в этом плане — самые прожры.

[Сергей]

Какой ужас! Это в наше то время, когда терабайтный жёсткий диск стоит не дороже $100…

[vgrayster]

>Рискну предположить, что они для экономии дискового пространства используют файловые системы с

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

У меня есть опыт хранения 50k картинок, при общем весе в 11гигов, места на диске они занимают несколько больше. Поэтому сейчас, когда у меня каждые 20 дней будет прибавляться 10 тыс картинок вопрос места на диске меня тоже волнует.

[Сергей]

А можно узнать сколько получается экономить при таком подходе, в процентном соотношении?

[Dmitry Dedukhin]

> если бы у меня были навыки C программиста
Имхо, здесь не нужны особые навыки.
В самом простейшем случае, когда у вас фиксированное число серверов, на которых хранятся картинки, вы можете в самой ссылке на картинку зашифровать сервер и путь, где она хранится, а также смещение и размер в файле. Написав простейший модуль к нгинксу, который будет расшифровывать эту информацию и добавлять заголовок Range к этому запросу, вы сможете читать отдельные картинки из комбо-файла.

[fallen]

Потому что любые фс очень плохо переваривают гигантские количества маленьких файлов. Тут речь не о 100к идет.

[Сергей]

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

[fallen]

Проблем, кроме времени доступа, может и не будет. Не зря они распинаются — www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/

Answer 7

[asm0dey]

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

Answer 8

[lalibu]

предположительно эта задача для couchDB

Comments

[amc]

+1
Парадигма NoSQL больше подходит под данную задачу, чем парадигма RDBMS.
Автор посмотрите en.wikipedia.org/wiki/Nosql#Taxonomy может будет проще.

Answer 9

[sevmax]

Посмотрите в сторону S3+CloudFront. И вам не надо будет заморачиваться с локальным хранением.

Answer 10

[pentarh]

MogileFS ливжурналом была изначально создана для этой цели.

Answer 11

[Shtirlits]

Может не совсем в тему, но вот тут sasgis.ru/forum/viewtopic.php?f=2&t=540 обсуждается схожая проблема, суть перенос сотен тысяч — миллионов тайлов от карт гугла и тп в программе сасгис, если кратко, то по крайней мере для переноса на флэш, пока 2 решения на уровне ФС, трукрипт с минимальным размером блока в контейнере(трукрипт по дефолту шифрует,… собака) и архивация tar\gzip, (который не запрашивает список файлов перед операцией архивирования, а сразу начинает архивировать т.е. скорость архивирования ~= скорости копирования).
может поможет

ээээх еслиб в винде можно было подключить таровсий архив как truecrypt или хотябы как iso…, потом одним архивом кидай куда хочешь…