Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Спасение 6 миллионов файлов в условиях полного Хецнера   Или почему складывать файлы в   базу данных – не такая смешная  и...
Банальное окружение• 300,000 пользователей  – 6 миллионов файлов  – Статический контент  – Несколько идентичных серверов о...
Очевидные, но неожиданные            проблемы• 6 млн файлов распределены по 6 млн  директорий – видимо, ошибка в проекте и...
Неуправляемые данные• Дисковый кэш малоэффективен – слишком  велик объем• Обход дерева – 6 часов (кеширование все-  таки п...
Возможные решения• Индексированные директории  – За    • просто и традиционненько  – Против    • Необходимость менять логи...
Возможные решения• Распределенные файловые системы  – За    • Репликация происходит сама и сама поддерживает      свою акт...
Возможные решения• СУБД  – За:     • Проверенные временем технологии     • Простота идеи     • Гибкое индексирование  – Пр...
Два полюса в мире СУБД• Key-value  – Созданы как раз под нашу задачу  – Должны быть быстрыми• Реляционные  – Проверены вре...
Новое – значит падучее– HyperTable как представитель KV-баз– Быстр– Гибок– Но – падает на большом количестве мелких  встав...
Старый конь борозды не портит• PostgreSQL как достойный представитель  реляционных СУБД  – Важно: stream-интерфейс к large...
Что это нам дает?• Вся мета-информация, включая индексы –  2GB. Нет проблем с кэшем.• «обход дерева» - 2 минуты• Поиск нов...
И о производительности• При 1000 одновременных соединений• 1Gbps – загружен полностью• 1200 запросов в секунду• Потреблени...
Никому не интересно (siege results)Сервер: 16GB RAM, 3.4GHz CPU 8 cores, 2 SATA HDDs in software mirror, 1GB NIC.** SIEGE ...
Никому не интересно (siege results)На совсем мелких файликах** SIEGE 2.70** Preparing 1000 concurrent users for battle.The...
Выводы  (которые мы сделали для себя)• Планирование управления данными – это  важно• Технологии каменного века – все еще  ...
Upcoming SlideShare
Loading in …5
×

Спасение 6 млн файлов в условиях полного хецнера (Даниил Подольский, Дмитрий Симонов)

2,238 views

Published on

Спасение 6 млн файлов в условиях полного хецнера (Даниил Подольский, Дмитрий Симонов)

  1. 1. Спасение 6 миллионов файлов в условиях полного Хецнера Или почему складывать файлы в базу данных – не такая смешная идея, как кажется на первый взгляд
  2. 2. Банальное окружение• 300,000 пользователей – 6 миллионов файлов – Статический контент – Несколько идентичных серверов отдачи, обеспечивают отказоустойчивость и горизонтальное масштабирование – Файлы распределены по директориям для ускорения поиска при открытии
  3. 3. Очевидные, но неожиданные проблемы• 6 млн файлов распределены по 6 млн директорий – видимо, ошибка в проекте или даже в коде – Открытие каждой директории – одна операция ввода-вывода – Получение stat-информации о файле – еще одна – Обход дерева – 12 млн операций IO• Враг известен: иерархическая файловая система
  4. 4. Неуправляемые данные• Дисковый кэш малоэффективен – слишком велик объем• Обход дерева – 6 часов (кеширование все- таки помогает)• Синхронизация с помощью rsync – 20 часов• Невозможно поддерживать актуальность реплик традиционными средствами
  5. 5. Возможные решения• Индексированные директории – За • просто и традиционненько – Против • Необходимость менять логику приложения • Индексируются только имена
  6. 6. Возможные решения• Распределенные файловые системы – За • Репликация происходит сама и сама поддерживает свою актуальность – Против • Недостаточная производительность • Сложность настройки • Сложность добавления нод
  7. 7. Возможные решения• СУБД – За: • Проверенные временем технологии • Простота идеи • Гибкое индексирование – Против: • Нетрадиционный подход • Поведение на по настоящему больших объемах не изучено• То, что надо!
  8. 8. Два полюса в мире СУБД• Key-value – Созданы как раз под нашу задачу – Должны быть быстрыми• Реляционные – Проверены временем – Просты в настройке, управлении и отладке
  9. 9. Новое – значит падучее– HyperTable как представитель KV-баз– Быстр– Гибок– Но – падает на большом количестве мелких вставок, из-за проблем с фрагментацией памяти
  10. 10. Старый конь борозды не портит• PostgreSQL как достойный представитель реляционных СУБД – Важно: stream-интерфейс к large objects• Реализация прототипа – PostgreSQL – Apache+mod_perl – Сотня строк кода• А ведь оно работает!
  11. 11. Что это нам дает?• Вся мета-информация, включая индексы – 2GB. Нет проблем с кэшем.• «обход дерева» - 2 минуты• Поиск новых – от миллисекунд до секунд• Синхронизация – 100 в секунду. Чудес не бывает.• И кое-что задаром – Дедупликация – Версионность
  12. 12. И о производительности• При 1000 одновременных соединений• 1Gbps – загружен полностью• 1200 запросов в секунду• Потребление памяти – стабильное, предсказуемое и управляемое.• Загрузка CPU – 30%• Загрузка дисков – до 10%• Наработка на отказ – надоело тестировать раньше, чем сломалось
  13. 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 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
  14. 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 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
  15. 15. Выводы (которые мы сделали для себя)• Планирование управления данными – это важно• Технологии каменного века – все еще актуальны

×