Документ обсуждает различные стратегии масштабирования баз данных, включая партиционирование, репликацию и шардинг, а также различия между SQL и NoSQL решениями. Основное внимание уделяется необходимости масштабирования для обработки увеличивающихся нагрузок, примерам, таким как Instagram и YouTube, и преимущества и недостатки каждой стратегии. Также рассматриваются вызовы, связанные с управлением данными в условиях роста и требования к архитектуре приложений.

1. Масштабирование
Авдеев Андрей
Баз Данных

2. 1 Cуть, разновидности и стратегии масштабирования.
2 Партиционирование
3 Репликация
4 Шардинг
5 Sql и NoSQL решения

3. СУТЬ, РАЗНОВИДНОСТИ
И СТРАТЕГИИ МАСШТАБИРОВАНИЯ
Что это? Зачем? Когда?

4. МАСШТАБИРУЕМОСТЬ
Способность системы справляться с увеличивающимися
нагрузками (обычно — путем наращивания аппаратных
ресурсов)
(scalability)

5. МАСШТАБИРОВАНИЕ
вертикальное горизонтальное

6. ВЕРТИКАЛЬНОЕ МАСШТАБИРОВАНИЕ
увеличение производительности каждого компонента
системы с целью повышения общей производительности.
Vertical scaling

7. ГОРИЗОНТАЛЬНОЕ МАСШТАБИРОВАНИЕ
разбиение системы на более мелкие структурные компоненты и
разнесение их по отдельным физическим машинам, и увеличение
количества серверов, параллельно выполняющих одну и ту же
функцию.
Horizontal scaling

8. КОГДА МАСШТАБИРОВАТЬ?
Когда возникает вопрос повышения производительности
приложения.*
Проблемы масштабирования возникают не сразу – они появляются внезапно
и в определенный момент. Если вы к этому не готовы, то вас ждут большие
проблемы.
*

9. ЧТО ТАКОЕ “БОЛЬШОЙ” ПРОЕКТ?
Сотни тысяч, миллионы, десятки миллионов хитов*
Бесперебойная работа
Сложная структура: серверный парк, большое
количество кода
Большое количество данных
Хит — обращение к веб-странице, исключая запросы к файлам, содержащим
графические изображения, служебные запросы и т. д.
*

10. INSTAGRAM
Пример
*
Instagrám — бесплатное приложение обмена фотографиями и видеозаписями,
позволяющее пользователям снимать фотографии и видео, а также распространять
их через свой сервис и ряд других социальных сетей.
*
Начало:
• 1 сервер слабее Macbook Pro
• 25к регистраций в первый день
• 2 разработчика
2012г. :
• 40+ миллионов пользователей
• 100+ виртуальных серверов в EC2, в том числе:
• Проект куплен Facebook за 1 млрд. долл
• 1 миллион регистраций за 12 часов после запуска
Android-версии
• 5 разработчиков

11. YOUTUBE
Пример
*
YouTube — сервис, предоставляющий услуги видеохостинга.
*
• 4 млрд. просмотров страниц в день
• 60 часов видео загружается каждую минуту
• 350 миллионов устройств подключено к YouTube
• На февраль 2012 года в США по данным comScore:
• 147,4 млн. уникальных зрителей
• 16,7 млрд. просмотров видео (в октябре 2011 было
больше 20 млрд.)
• Каждый зритель посмотрел в среднем 7 часов видео
за месяц
• 1.1 млрд. просмотров видео рекламы, суммарной
длительностью в 10.8 млн. часов

12. СТРАТЕГИИ МАСШТАБИРОВАНИЯ
ПАРТИЦИОНИРОВАНИЕ
РЕПЛИКАЦИЯ
ШАРДИНГ

13. ПАРТИЦИОНИРОВАНИЕ

14. ПАРТИЦИОНИРОВАНИЕ
это разбиение больших таблиц на логические части по
выбранным критериям.
(partitioning)

15. ТИПЫ ПАРТИЦИОНИРОВАНИЯ
По диапазону
По списку значений
По хешу
По ключу
*
Типизация на примере СУБД MySQL ( версия >= 5.1 )
*

16. ПО ДИАПАЗОНУ
каждая партиция содержит данные принадлежащие
указанному диапазону значений колонки.
PARTITION BY RANGE (store_id) (
PARTITION p0 VALUES LESS THAN (6),
PARTITION p1 VALUES LESS THAN (11),
PARTITION p2 VALUES LESS THAN (16),
PARTITION p3 VALUES LESS THAN (21)
);
Партиционирование

17. ПО СПИСКУ ЗНАЧЕНИЙ
каждая партиция содержит данные содержащие
определенное значение в колонке.
PARTITION BY LIST (store_id) (
PARTITION p0 VALUES IN (1,5,9,13),
PARTITION p1 VALUES IN (2,6,10,14),
PARTITION p2 VALUES IN (3,7,11,15),
PARTITION p3 VALUES IN (4,8,12,16)
);
Партиционирование

18. ПО ХЕШУ
Таблица разбивается по хешу значения некоторой колонки.
Партиционирование

19. ПО КЛЮЧУ
Таблица разбивается по хешу значения некоторой колонки.
Партиционирование

20. РЕПЛИКАЦИЯ

21. РЕПЛИКАЦИЯ
— это синхронное/асинхронное копирование данных с
ведущих серверов на ведомые (или возможно тоже
ведущие) сервера.
(replication)
— это наращиваемое решение. Если одного слейва не
хватает — ставится второй, третий и т.д.

22. Доминируют запросы на
получение информациии
Слабым местом является
операция чтения и именно
ее нужно масштабировать.
Кроме того, репликация используется для
географического распределения серверов
(например один сервер в Америке, другой в Европе).
КОГДА?

23. ПРИНЦИП РЕПЛИКАЦИИ
Мастер сервер при выполнении модификаций пишет все
сделанные изменения в лог, slave сервера с некоторой
периодичностью проверяют лог на предмет появления
новых данных и если они есть - выполняют аналогичные
действия со своими данными.

24. РЕПЛИКАЦИОННЫЕ СХЕМЫ
1 мастер, много слейвов
Цепочка мастер серверов
2 мастера, много слейвов

25. 1 МАСТЕР, МНОГО СЛЕЙВОВ
Схема обычно используется в приложениях с
доминирующими запросами на чтение - все запросы на
изменение базы направляются мастер серверу, тогда как
запросы на чтение распределяются между слейвами.
НЕДОСТАТОК
При выходе из строя мастер сервера, все
запросы на модификацию и добавление
данных не будут выполняться.

26. ЦЕПОЧКА МАСТЕР СЕРВЕРОВ
Очень удобна для географического распределения данных.
Например, ставим сервера в Европе, Азии и Америке,
настраиваем их в цепочку и учим приложение выбирать
сервер в зависимости от региона. Таким образом получаем
выигрыш за счет уменьшения пути путешествия запроса к
серверу.
НЕДОСТАТОК
Тот же, что и в предыдущей схеме.

27. 2 МАСТЕРА, МНОГО СЛЕЙВОВ
Схема является цепочкой из двух мастер серверов. Оба
мастера выполняют запросы на модификацию данных и
имеют равное количество слейвов. Таким образом при
выходе из строя одного мастера, приложение продолжит
работать со вторым и его слейвами.

28. ПРЕИМУЩЕСТВА / НЕДОСТАТКИ
+ Решает проблему нагрузки.
-
Усложнение программной архитектуры – например,
чтение данных с слейва, до которого не докатились
изменения.
При большом количестве слейвов усложняется схема
распространения изменений, которая в дальнейшем
становится узким местом.
-

29. ШАРДИНГ

30. ШАРДИНГ
— развитие партиционирования - разбиение данных на
группы и хранение каждой группы на отдельном сервере
(шарде). В данном случае группа не обязательно включает
одну таблицу, это может быть несколько таблиц
содержащих одно целое.

31. ШАРДИНГ
Вертикальный шардинг Горизонтальный шардинг

32. КРИТЕРИЙ ШАРДИНГА
— какой-то параметр, который позволит определять, на
каком именно сервере лежат те или иные данные.

33. КРИТЕРИИ ШАРДИНГА
ID поля таблицы
Хеш-таблица с соответствиями «пользователь=сервер»
(Тогда, при определении сервера, нужно будет выбрать сервер из этой таблицы. В этом случае
узкое место — это большая таблица соответсвия, которую нужно хранить в одном месте.)
Определять имя сервера с помощью числового
(буквенного) преобразования.
(Например, можно вычислять номер сервера, как остаток от деления на
определенное число (количество серверов, между которыми Вы делите
таблицу). В этом случае узкое место — это проблема добавления новых
серверов — Вам придется делать перераспределение данных между новым
количеством серверов.)

34. ПРЕИМУЩЕСТВА / НЕДОСТАТКИ
+ Решает проблему нагрузки.
- Ограничение в возможности выборок, которые требуют
пересмотра всей таблицы.
Приходится отказаться от триггеров, хранимых процедур.
+ Бесконечно масштабируем.
Принципиально невозможно без
изменения кода
-

35. SQL or NoSQL

36. SQL | MySQL
NDB Cluster – движок на основе синхронных репликаций и
автоматического разделения данных по нодам. Он ведет себя адекватно
для небольших наборов данных и простых запросов.

37. SQL | PostgreSQL
1.Slony-I – асинхронная (master to multiple slaves) репликация:
http://slony.info/.
2.Pgpool-II – синхронный мульти-мастер
репликации: http://pgfoundry.org/projects/pgpool/.
3.Pgcluster – синхронный мульти-мастер
репликации: http://pgfoundry.org/projects/pgcluster/.
4.PL/Proxy – прокси от компании Skype: http://pgfoundry.org/projects/plproxy/.
5.PgBouncer – менеджер соединений для
PostgreSQL: https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer.

38. NoSQL
Преимущества:
Эластичное масштабирование
NoSQL-системы разрабатываются с возможностью прозрачного
расширения с целью использования таких преимуществ, как
возможность добавления любого количества новых узлов.
Уменьшение объема администрирования
В общем случае базы данных типа NoSQL проектируются для поддержки
таких возможностей, как автоматическое исправление и более простая
модель данных, которые снижают потребности в администрировании и
настройке.

39. NoSQL
Преимущества:
Улучшение экономических показателей
Чтобы справиться с взрывным ростом объемов информации и
транзакций, базы данных типа NoSQL обычно используют кластеры
из недорогих массовых серверов.
Гибкие модели данных
Базы данных типа NoSQL имеют более слабые ограничения на модели
данных (или вообще не имеют ограничений), что позволяет более плавно
вносить изменения в приложения и в схемы базы данных.

40. NoSQL
Недостатки:
Управление транзакциями является одной из мощных функций
реляционных СУБД. Нынешняя – ограниченная или вообще
отсутствующая — поддержка понятия транзакции в NoSQL-системах
управления базами данных рассматривается как препятствие для
применения этих систем при реализации ответственных решений.
Поддержка транзакций
Модели программирования
Базы данных типа NoSQL предлагают не слишком много средств для
запросов и оперативного анализа. Даже простой запрос требует
значительной квалификации в области программирования.
Степень зрелости
Системы реляционных СУБД хорошо известны высокой стабильностью и
обширной функциональностью.

41. NoSQL
Недостатки:
Поддержка
Почти каждый разработчик NoSQL-системы действует в режиме обучения. Не
вызывает сомнения, что со временем эта ситуация изменится. Однако в
настоящее время гораздо легче найти опытных программистов или
администраторов по реляционным СУБД, чем специалистов по NoSQL.
Компетентность
Поставщики реляционных СУБД тратят много сил на то, чтобы обеспечить столь
высокий уровень поддержки. Многие NoSQL-системы, напротив, являются
проектами с открытым исходным кодом и не обеспечивают подобного уровня
поддержки.

42. NoSQL

44. Вопросы?