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.
Upcoming SlideShare
язык программирования Go в жизни системного администратора
Next
Download to read offline and view in fullscreen.

Share

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

Download to read offline

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

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

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

Views

Total views

2,261

On Slideshare

0

From embeds

0

Number of embeds

51

Actions

Downloads

4

Shares

0

Comments

0

Likes

0

×