Download to read offline
Uploaded byDaniel Podolsky
Спасение 6 миллионов файлов в условиях полного Хецнера
Документ обсуждает проблемы хранения и управления 6 миллионами файлов для 300,000 пользователей, выявляя неэффективность традиционных иерархических файловых систем. Рассматриваются возможные решения, включая использование индексированных директорий, распределённых файловых систем и СУБД, с акцентом на PostgreSQL и его эффективность. Описание тестов на производительность показывает стабильные результаты при обработке больших объемов данных при использовании реляционных технологий.
More Related Content
Спасение 6 миллионов файлов в условиях полного Хецнера
- 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. Выводы (которые мы сделалидля себя) • Планирование управления данными – это важно • Технологии каменного века – все еще актуальны