Спасение 6 миллионов файлов в условиях полного Хецнера

Спасение 6 миллионов файлов в условиях полного Хецнера

Или почему складывать файлы в базу данных – не такая смешная

идея, как кажется на первый взгляд

Банальное окружение

• 300,000 пользователей– 6 миллионов файлов– Статический контент– Несколько идентичных серверов отдачи,

обеспечивают отказоустойчивость и горизонтальное масштабирование

– Файлы распределены по директориям для ускорения поиска при открытии

Очевидные, но неожиданные проблемы

• 6 млн файлов распределены по 6 млн директорий – видимо, ошибка в проекте или даже в коде– Открытие каждой директории – одна операция

ввода-вывода– Получение stat-информации о файле – еще одна– Обход дерева – 12 млн операций IO

• Враг известен: иерархическая файловая система

Неуправляемые данные

• Дисковый кэш малоэффективен – слишком велик объем

• Обход дерева – 6 часов (кеширование все-таки помогает)

• Синхронизация с помощью rsync – 20 часов• Невозможно поддерживать актуальность

реплик традиционными средствами

Возможные решения

• Индексированные директории– За• просто и традиционненько

– Против• Необходимость менять логику приложения• Индексируются только имена

Возможные решения

• Распределенные файловые системы– За• Репликация происходит сама и сама поддерживает

свою актуальность– Против• Недостаточная производительность• Сложность настройки• Сложность добавления нод

Возможные решения

• СУБД– За:• Проверенные временем технологии• Простота идеи• Гибкое индексирование

– Против:• Нетрадиционный подход• Поведение на по настоящему больших объемах не

изучено

• То, что надо!

Два полюса в мире СУБД

• Key-value– Созданы как раз под нашу задачу– Должны быть быстрыми

• Реляционные– Проверены временем– Просты в настройке, управлении и отладке

Новое – значит падучее

– HyperTable как представитель KV-баз– Быстр– Гибок– Но – падает на большом количестве мелких

вставок, из-за проблем с фрагментацией памяти

Старый конь борозды не портит

• PostgreSQL как достойный представитель реляционных СУБД– Важно: stream-интерфейс к large objects

• Реализация прототипа– PostgreSQL– Apache+mod_perl– Сотня строк кода

• А ведь оно работает!

Что это нам дает?

• Вся мета-информация, включая индексы – 2GB. Нет проблем с кэшем.

• «обход дерева» - 2 минуты• Поиск новых – от миллисекунд до секунд• Синхронизация – 100 в секунду. Чудес не

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

И о производительности

• При 1000 одновременных соединений• 1Gbps – загружен полностью• 1200 запросов в секунду• Потребление памяти – стабильное,

предсказуемое и управляемое. • Загрузка CPU – 30%• Загрузка дисков – до 10%• Наработка на отказ – надоело тестировать

раньше, чем сломалось

Никому не интересно (siege results)Сервер: 16GB RAM, 3.4GHz CPU 8 cores, 2 SATA HDDs in software mirror, 1GB NIC.** SIEGE 2.70** Preparing 1000 concurrent users for battle.The server is now under siege...Lifting the server siege... done.Transactions: 143683 hitsAvailability: 100.00 %Elapsed time: 300.02 secsData transferred: 31969.32 MBResponse time: 1.58 secsTransaction rate: 478.91 trans/secThroughput: 106.56 MB/secConcurrency: 755.62Successful transactions: 143683Failed transactions: 0Longest transaction: 14.00Shortest transaction: 0.00

Никому не интересно (siege results)На совсем мелких файликах** SIEGE 2.70** Preparing 1000 concurrent users for battle.The server is now under siege...Lifting the server siege... done.Transactions: 590178 hitsAvailability: 100.00 %Elapsed time: 299.45 secsData transferred: 5392.50 MBResponse time: 0.01 secsTransaction rate: 1970.87 trans/secThroughput: 18.01 MB/secConcurrency: 12.07Successful transactions: 590178Failed transactions: 0Longest transaction: 1.01Shortest transaction: 0.00

Выводы(которые мы сделали для себя)

• Планирование управления данными – это важно

• Технологии каменного века – все еще актуальны