Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•Download as PPTX, PDF•
•
Daniel Podolsky
Daniel Podolsky

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

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

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