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

1. Спасение 6 миллионов файлов
в условиях полного Хецнера
Или почему складывать файлы в
базу данных – не такая смешная
идея, как кажется на первый взгляд

2. Банальное окружение
• 300,000 пользователей
– 6 миллионов файлов
– Статический контент
– Несколько идентичных серверов отдачи,
обеспечивают отказоустойчивость и
горизонтальное масштабирование
– Файлы распределены по директориям для
ускорения поиска при открытии

3. Очевидные, но неожиданные
проблемы
• 6 млн файлов распределены по 6 млн
директорий – видимо, ошибка в проекте или
даже в коде
– Открытие каждой директории – одна операция
ввода-вывода
– Получение stat-информации о файле – еще одна
– Обход дерева – 12 млн операций IO
• Враг известен: иерархическая файловая
система

4. Неуправляемые данные
• Дисковый кэш малоэффективен – слишком
велик объем
• Обход дерева – 6 часов (кеширование все-
таки помогает)
• Синхронизация с помощью rsync – 20 часов
• Невозможно поддерживать актуальность
реплик традиционными средствами

5. Возможные решения
• Индексированные директории
– За
• просто и традиционненько
– Против
• Необходимость менять логику приложения
• Индексируются только имена

6. Возможные решения
• Распределенные файловые системы
– За
• Репликация происходит сама и сама поддерживает
свою актуальность
– Против
• Недостаточная производительность
• Сложность настройки
• Сложность добавления нод

7. Возможные решения
• СУБД
– За:
• Проверенные временем технологии
• Простота идеи
• Гибкое индексирование
– Против:
• Нетрадиционный подход
• Поведение на по настоящему больших объемах не
изучено
• То, что надо!

8. Два полюса в мире СУБД
• Key-value
– Созданы как раз под нашу задачу
– Должны быть быстрыми
• Реляционные
– Проверены временем
– Просты в настройке, управлении и отладке

9. Новое – значит падучее
– HyperTable как представитель KV-баз
– Быстр
– Гибок
– Но – падает на большом количестве мелких
вставок, из-за проблем с фрагментацией
памяти

10. Старый конь борозды не портит
• PostgreSQL как достойный представитель
реляционных СУБД
– Важно: stream-интерфейс к large objects
• Реализация прототипа
– PostgreSQL
– Apache+mod_perl
– Сотня строк кода
• А ведь оно работает!

11. Что это нам дает?
• Вся мета-информация, включая индексы –
2GB. Нет проблем с кэшем.
• «обход дерева» - 2 минуты
• Поиск новых – от миллисекунд до секунд
• Синхронизация – 100 в секунду. Чудес не
бывает.
• И кое-что задаром
– Дедупликация
– Версионность

12. И о производительности
• При 1000 одновременных соединений
• 1Gbps – загружен полностью
• 1200 запросов в секунду
• Потребление памяти – стабильное,
предсказуемое и управляемое.
• Загрузка CPU – 30%
• Загрузка дисков – до 10%
• Наработка на отказ – надоело тестировать
раньше, чем сломалось

13. Никому не интересно (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 hits
Availability: 100.00 %
Elapsed time: 300.02 secs
Data transferred: 31969.32 MB
Response time: 1.58 secs
Transaction rate: 478.91 trans/sec
Throughput: 106.56 MB/sec
Concurrency: 755.62
Successful transactions: 143683
Failed transactions: 0
Longest transaction: 14.00
Shortest transaction: 0.00

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

15. Выводы
(которые мы сделали для себя)
• Планирование управления данными – это
важно
• Технологии каменного века – все еще
актуальны