Your SlideShare is downloading. ×
High load2007 scaling-web-applications-rus
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

High load2007 scaling-web-applications-rus

423
views

Published on

Highload 2007 for ling-web-applications-rus

Highload 2007 for ling-web-applications-rus


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
423
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Техники масштабирования Веб-приложений Петр Зайцев pz@mysqlperformanceblog.com
  • 2. Проблемы производительности• Время отклика – Страница долго грузится, даже для одного активного пользователя • Типично обрабатывается много данных• Пропускная способность (req/sec) – При большом числе активных пользователей время отклика растет и система не справляется• Пути решения могут быть разные 2
  • 3. В чем еще сложности?• Число запросов часто растет вместе с объемом данных – O(N) алгоритмы требуют O(N^2) ресурсов• Данные в памяти в 1000 раз быстрее чем на диске.• Блокировки на уровне приложения, базы данных, операционной системы 3
  • 4. Что масштабируем?• Динамический контент• Статический контент• Базу данных 4
  • 5. Динамический контент• Пропускная способность – Решается увеличением числа Web серверов – Для одной и той же задачи может использоваться в 10 раз больше железа – Оптимизация скорости важна для эффективности, но не жизни проекта• Время отклика – Изменение алгоритма – Оптимизация, например модули на C – Параллельные алгоритмы (на разных уровнях) 5
  • 6. Статический контент• Достаточность памяти и пропускной способности дисков• nginx/lighttpd легко отдают 20.000+ маленьких объектов в секунду на сервер• Типичная проблема – завязка на одну большую файловую систему – Разделить через proxy-rewrite – Или не иметь проблему изначально • Photobucket – Отдавать напрямую лучше, чем через NFS 6
  • 7. База данных• Обычно наиболее сложный для масштабирования компонент• Особенно сложно, если приложение создано без оглядки на масштабирование• Очень важно кэширование (как впрочем и на других уровнях) 7
  • 8. Пути масштабирования БД• Купить более мощный сервер – Хороший подход, если результаты нужны быстро, а никакой возможности изменить приложение нет – Часто не решает проблемы времени отклика – Возможности роста ограничены – Финансово неэффективно • Особенно учитывая, что нужен второй такой же сервер (для надежности) 8
  • 9. Репликация• Относительно простое решение – Не так много изменений в приложении• Достаточно большой предел для ряда приложений – YouTube еще год назад имела одну базу данных• Важно ограничить запись• Обеспечить данные в памяти• Репликация не параллельна в MySQL 9
  • 10. Потабличное разбиение• Выделяются компоненты и их таблицы располагаются на разных серверах – И часто реплицируются – Например “сервер регистрационных данных”, “форумы” итд• Относительная легкость изменения• Не всегда легко выделить малозависимые компоненты• Ограниченная масштабируемость 10
  • 11. “Шардинг” – разбиение данных• Данные распределены на много серверов – Которые обычно реплицируются• На одном сервере может быть больше, чем один “шард” – Легкость балансировки, меньше блокировки• Требует правильного разбиения данных• Может требоваться более одного разбиения 11
  • 12. Какой путь для вас?• Оцените требования приложения к росту• Объем базы данных• Интенсивность записи• Возможности кэширования• Навыки персонала• Временные рамки и бюжет разработки 12
  • 13. Как разбивать данные• Старые приложения – Так, чтобы минимизировать модификации • Часто схема полностью дублируется, включая имена баз данных, и добавляется логика определения нахождения объекта• Новые приложения – Для обеспечения лучшей производительности и сопровождаемости • Несколько баз данных на сервере с разными именами 13
  • 14. Критерий разбиения• Хэш разбиение для объектов – Четные на сервер 1, нечетные на сервер 2 – Просто, но очень негибко• Таблица привязки для каждого элемента – Требуется обращение к словарю – Гибко, удобно балансировать данные• Блочная структура – 1024 блока, которые приписаны к серверам – Гибко, но “блоки” можно переносить физически 14
  • 15. Кластеризация разбиения• Минимизация операций, требующих доступа ко многим (всем) группам• Зависит от приложения – типично пользователь, сайт – Или группа – регион, школа итд• Может требоваться несколько разбиений и дублирование данных – “Пользователь” и “Фильм”• Некоторые приложения допускают произвольное разбиение 15
  • 16. Проблемы с разбиением данных• JOIN с системными/глобальными таблицами – “ручной join” • Нередко это бывает даже быстрее – “репликация” системных/глобальных таблиц на все сервера • Хорошо, если данных мало и меняются нечасто – Federated Storage Engine • Иногда работает, обычно мееедленно • Сложности с обеспечением доступности при падении мастера 16
  • 17. Агрегация данных по всем разбиениям• Действительно ли этого не избежать? – Дублирование данных – Пре-генерация данных итд• Вручную пробегать все группы – Простое решение, работает для группировки• UNION ALL VIEW на Federated Tables – Хорошо работает, когда время получения ответа не важно 17
  • 18. Агрегация данных по всем разбиениям• Самописные системы параллельной агрегации – Особенно хорошо, когда групп ограниченное число • Technorati Web Services Layer • HiveDB (система для решения этой проблемы)• Sphinx – “Неожиданно” оказался полезным для глобальной агрегации далеко за пределами полнотекстового поиска 18
  • 19. А как же MySQL Cluster?• Зачем мучаться с разбиением данных вручную, давайте поставим MySQL Cluster и он все за нас сделает автоматически?• Хорошо в теории, но плохо работает на практике для многих задач – Сложности с выполнением сложных запросов (по меньшей мере пока) – Не работает с большими наборами данных, даже в версиях 5.1.x – Достаточно хорошо работает, например, для хранения сессий в Web приложениях 19
  • 20. Веб 2.0 мантра – кэшировать и еще раз кэшировать• Набор технологий для избежания тяжелой работы по генерации данных – Классическое кэширование – Прегенерация статических данных – Таблицы содержащие суммарные данные итд• Избежать работы лучше, чем ее оптимизировать! 20
  • 21. Кэширование на всех уровнях• “Железные” CPU Cache, RAID Cache• Память как кэш – Файловый кэш и внутренние кэши БД – Требуют аккуратной настройки для лучшей производительности – Часто определяют размер данных, с которыми сервер будет эффективно справлятся• MySQL Query Cache – Кэш результатов запросов (вместо исходных данных) 21
  • 22. Кэши уровня приложения• Кэширование результатов ф-ий, объектов, малоизменяемых данных – APC/eAccelerator/xcache как кэш данных • высокая скорость, малый объем, локальность • Могут быть проблемы с блокировками и фрагментацией – MemCache • Распределенный “сетевой” кэш – единая копия данных и больше объем. Медленно – Диск (локальный или разделенный) – “Обернутый диск” – например BDB с memcache интерфейсом 22
  • 23. HTTP и выше• Прегенеренные статические данные – Можно хитрить и генерить по 404 и стирать при инвалидации.• SQUID и аналоги – Распределенный. TTL или инвалидация• Кэш браузера – Правильно выставлять expires, etag – Если новой версии объекта давать новый URL, можно не беспокоится об инвалидации 23
  • 24. Политика кэширования• Как избежать позавчерашних новостей? – TTL – объект имеет ограниченное время жизни • Просто, но менее эффективно чем могло бы быть – Инвалидация обновленных данных • Более сложно, но эффективно и оперативно • Часто используется с TTL “на всякий случай” – “Контроль версий объектов” • Знаем, что версия пользователя равна 1000 – значит, считаем недействительными все более старые зависимые объекты 24
  • 25. Боремся с сетевыми задержками• Получить больше данных за одно обращение – Не считывать таблицу строку за строкой – Использовать multi_get в memcache итд• Делать запросы параллельно – Параллельная работа с внешними Web сервисами• Избегать ненужных обращений• “Отложенные операции” – Можно ли это сделать после того, как страница уже отдана? 25
  • 26. Вот и все, или немного рекламы• Percona Ltd – Мы занимаемся консалтингом в области MySQL, оптимизациями, дизайном архитектуры, обслуживанием MySQL• Приходите к нам работать – Интересная работа для активных экспертов в Web технологиях и MySQL• pz@mysqlperformanceblog.com• http://www.mysqlperformanceblog.com 26