1. Введение в проблематику: файловые хранилища, их классификация и ключевые характеристики - по версии докладчика. 1.1. Термины и определения: файл, хранилище, POSIX file system, документ-ориентированное хранилище, области применимости и условия эксплуатации. 1.2. Классификация по размеру: количество записей, количество байт, количество запросов, количество обновлений и сочетание этих параметров, позволяющее назвать хранилище “большим”. далее см. - http://rootconf.ru/2015/abstracts/1747

1. Опыт построения и
эксплуатации
большого файлового
хранилища
Даниил Подольский
Git in Sky

2. или
Ночью через лес

3. Файловое хранилище –
что это и зачем оно
• Файл: именованный кусок данных, слишком
большой для того, чтобы обращаться с ним, как
с одним куском
• Краеугольный камень здорового питания
современного обмена данными. Так уж
получилось.
• Файловое хранилище – место, где хранятся
файлы
• Файловое хранилище – место, откуда отдаются
файлы

4. Большое файловое
хранилище – пришла
беда откуда не ждали
• Много байтов? Нет.
• Много файлов? Нет.
• Много обновлений? Теплее...
• Проблема управления? Тепло!
• «Большое» - описание ситуации, а не сущности!

5. Парадокс файлового
хранилища
• Файловое хранилище не нужно. От слова
«совсем»
• В бизнес-требованиях не написано «хранить
файлы»
– Даже когда написано – это ошибка
• В бизнес требованиях написано «отдавать
файлы»
• Но отдать можно лишь то, что имеешь

6. 10 лет под кроватью
• Setup.Ru как источник
неограниченного количества
разнообразных файлов
• Картинки и разметка – что хранить,
а что генерировать
• Постоянные обновления – до 20М
файлов в сутки

7. 2012, начало:
rsync, обезьяны!
Как оно было
• Локальная EXT4
• До 6М файлов
• SSD для горячего контента
• HDD для объемного контента
Проблемы
• Eventual отказоустойчивость
• Никакой статистики

8. 2012, лето:
а они как ломанули!..
Как оно было
• 6.5М файлов
Проблемы
• 6 часов на обход дерева – контент менялся быстрее, чем
мы его синхронизировали
Решение
• Файлы – в базу!
• Большие файлы – в BLOB
• Самописная master-master репликация

9. 2103, весна:
поиски начала конца
Как оно было
• 25М файлов
Проблемы
• Длинные транзакции, автоинкремент и проблемы
синхронизации
• Контент меняется быстрее, чем мы его синхронизируем
Решение
• Меняем бизнес-логику для преодоления проблем
eventual consistency

10. 2103, осень:
кто съел процессор
Как оно было
• 50М файлов
Проблемы
• Долгий join
Решение
• Materialized views

11. 2014, весна:
нам некуда больше жать
Как оно было
• 120М файлов
Проблемы
• Контент перестал помещаться на диск
Решение
• Большие файлы были вынесены на leofs хранилище

12. 2015, начало:
все свободны, всем - спасибо
Как оно было
• 400М файлов
Проблемы
• Расширение кластера leofs привело к его разрушению
• Rakuten помощь оказать не смог
Решение
• Паниковать!
• Пробовать iSCSI квази-СХД.
• Паниковать!!!

13. 2015, весна:
бесконечность не предел
Как оно было
• 450М файлов
Проблемы
• На leofs заканчивается место. Расширение невозможно
• Rakuten помощь оказать не смог
• Индексы PostgreSQL перестали помещаться в память
Решение
• Разработать собственное хранилище на базе NoSQL
СУБД

14. Чему мы научились
• Отказоустойчивость – это «отдавать» и
«обновлять», но традиционные хранилища –
такие хранилища…
• «Ничто не заменит кубы», или файловый кеш
• Распределенные системы хранения – блеск и
нищета дешевого кластера
– Мерзость eventual consistency
– Ужас strong consistency
– Беспросветность ребалансинга
– А еще оно тормозит

15. Чему еще мы научились
• Хорошо, когда файлы мелкие – тогда
они не файлы.
• PostgreSQL BLOB – не делай так больше
• Материализация view – иногда без этого
никак
• Самописная репликация – road to hell
• Удалять файлы придется
• Java лучше, чем Erlang

16. Чему мы НЕ научились
• Большая отказоустойчивая СХД:
немного слишком дорого
• Распределенные POSIX-совместимые
файловые системы: созданы под
другие задачи

17. Нет у революции конца
• Кластерная NoSQL СУБД
• Самописный чанкинг
• Самописное версионирование
• Самописный dedup (rolling checksum)
• Самописные транзакции
• Ну и сжатие на уровне чанка
Это работает!

18. Немного цифр
• 1.5М сайтов
• 450М файлов
• 6Т данных – 18Т с избыточностью
• 1.5К запросов в секунду

19. Все-таки
Ночью через лес
• 2Т лимит, или почему не получился
бесшовный переезд
• 3 часа на рестарт ноды
• 60 часов на ребалансинг

20. Вопросы?