Спасение 6 миллионов файлов в условиях полного Хецнера
TRANSCRIPT
Спасение 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
Выводы(которые мы сделали для себя)
• Планирование управления данными – это важно
• Технологии каменного века – все еще актуальны