Опыт построения и эксплуатации большого файлового хранилища / Даниил Подольский (Git in Sky)
Download as PPTX, PDF1 like1,688 views
Документ описывает опыт построения и эксплуатации большого файлового хранилища, включая проблемы с управлением файлами и их быстрым обновлением. Он выделяет важные моменты, такие как необходимость изменения бизнес-логики и использование различных технологий для управления большими объемами данных. В итоге представлена статистика, указывающая на масштаб хранилища и объем операций.
Опыт построения и эксплуатации большого файлового хранилища / Даниил Подольский (Git in Sky)
- 1. Опыт построения и эксплуатации большого файлового хранилища Даниил Подольский Git in Sky
- 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. Вопросы?