Пошаговый алгоритм разработки высоконагруженной системы Олег Бунин oleg.bunin@ontico.ru. - презентация

1 Пошаговый алгоритм разработки высоконагруженной системы Олег Бунин

2 ПОДГОТОВКА Вспомним инструменты, которые мы будем использовать 2

3 Инструмент #1 Сервисно-ориентированная архитектура 3

4 Инструмент #2 Вертикальное масштабирование 4

5 Инструмент #3 Горизонтальное масштабирование: Не храним состояние; Отсутствие общих узлов; 5

6 Инструмент #4 Отложенные вычисления 6

7 Инструмент #5 Асинхронная обработка 7

8 Инструмент #6 Использование толстого клиента 8

9 Инструмент #7 Кеширование 9

10 Инструмент #8 Функциональное разделение 10

11 Инструмент #9 Шардинг 11

12 Инструмент #10 Виртуальные шарды 12

13 Инструмент #11 Центральный диспетчер 13

14 Инструмент #12 Репликация 14

15 Инструмент #13 Партиционирование 15

16 Инструмент #14 Денормализация 16

17 Инструмент #15 Введение избыточности 17

18 Инструмент #16 Параллельное выполнение 18

19 АЛГОРИТМ, ШАГ ПЕРВЫЙ Опишем бизнес-логику будущей системы, включая потенциальные пути развития системы 19

20 АЛГОРИТМ, ШАГ ВТОРОЙ Посчитаем объёмы хранимых данных и скорость их приращения. Выбираем критический путь – хранение, запись или чтение данных? 20

21 АЛГОРИТМ, ШАГ ТРЕТИЙ Определить допустимую деградацию функций системы 21

22 АЛГОРИТМ, ШАГ ЧЕТВЕРТЫЙ Построим схему движения данных и примем решение, какие из особенностей проектируемой системы мы будем использовать 22

23 АЛГОРИТМ, ШАГ ПЯТЫЙ Проектируем схему хранения данных 23

24 АЛГОРИТМ, ШАГ ШЕСТОЙ Ломаем систему и смотрим, что у нас получится 24

25 Примеры

26 ПРОФИЛИ НА САЙТЕ ЗНАКОМСТВ Спроектируем систему хранения пользователей на сайте знакомств 26

27 Сайт знакомств, профили / #1 1.Пользователь заполняет анкету; 2.Получает логин пароль для доступа к своему личному кабинету; 3.Пользователи могут смотреть профили друг друга; 27

28 Сайт знакомств, профили / #2 1.Пользователей 200 миллионов; 2.Каждая анкета занимает 10 килобайт, то есть всего гигабайт; 3.Хитов в день 5 миллиардов; 28

29 Сайт знакомств, профили / #3 1.Деградация недопустима; 29

30 Сайт знакомств, профили / #4 1.Данные часто читаются, но редко меняются; 2.Все анкеты примерно одного размера; 3.У анкеты есть уникальный идентификатор; 4.Нет ярко выраженных лидеров; 30

31 Сайт знакомств, профили / #5 Проектируем схему хранения данных 31

32 Сайт знакомств, профили / #5 Репликация? Вообще 140к чтений в секунду 32

33 Сайт знакомств, профили / #5 Шардирование? По какому ключу? Диспетчер? 33

34 Сайт знакомств, профили / #6 Виртуальные шарды 34

35 Сайт знакомств, профили / #6 Сгорает диск? 35

36 Сайт знакомств, пользователи / #6 Репликация 36

37 Сайт знакомств, профили / результат Разбиваем весь массив пользователей на виртуальные шарды; Маппим виртуальные шарды на реальные шарды; Внутри каждого шарда реплицируем информацию для отказоустойчивости 37

38 НОВОСТНОЙ САЙТ Большая и длинная лента новостей крупного СМИ 38

39 Новости / #1 Пользователь читает свежие новости; Пользователь читает архивные новости; Редактор публикует новости; 39

40 Новости / #2 Каждая новость примерно 10 килобайт; Мы вечно храним архив с даты основания СМИ – 2000 год; В день публикуется около 10 тысяч различных региональных и федеральных новостей; Итого в год 3 миллиона 500 тысяч новостей, в год 35 гигабайт, за 20 лет – 700 гигабайт; Это крупнейшее СМИ, посещаемость – 10 миллионов человек в сутки; 40

41 Новости / #3 Деградация недопустима; 41

42 Новости / #4 Количество чтений на несколько порядков превышает количество записей; 99% запросов касаются последнего дня; 99,99% запросов касаются последней недели. 42

43 Новости / #5 Проектируем схему хранения данных 43

44 Новости / #5 Шардирование? Шард с последним днём будет умирать 44

45 Новости / #5 Партиционирование По какому принципу? 45

46 Новости / #5 Как переносить данные из горячей БД в архив? 46

47 Новости / #5 Не надо ничего переносить! Вводим избыточность! 47

48 Новости / #5 Очень много запросов к горячим новостям! Что делать? 48

49 Новости / #5 Кеширование! 49

50 Новости / результат Кеширование для горячих новостей; Партиционирование новостей по дате – последние новости в быстрой таблице; Избыточное хранение новостей – новость пишется сразу и в горячую таблицу и в архивную, горячая раз в какое-то время чистится; 50

51 ПРОСМОТР ФРЕНДЛЕНТЫ Просмотр френдлента в блогах 51

52 Просмотр френдленты / #1 У пользователя может быть сколько угодно друзей; Френдленту храним бесконечно долго; 52

53 Просмотр френдленты / #2 В среднем у пользователя 100 друзей; Каждый пользователь в среднем пишет 3 поста в день; Каждый пост занимаем около 1 килобайта; Пользователей – 10 миллионов в сутки, но каждый пользователь делает 100 хитов. Итого – миллиард запросов к френдленте в сутки; В сутки генерируется 30 миллионов постов, 10 миллиардов записей в год; 53

54 Просмотр френдленты / #3 Допустимо, что пользователь увидит запись своего друга не моментально, а с небольшой задержкой; Допустимо, что порядок записей не будет строго совпадать с хронологическим; 54

55 Просмотр френдленты / #4 99% запросов приходятся на голову френдленты; У нас есть пользователи, которые в друзьях у миллионов пользователей; 55

56 Просмотр френдленты / #5 Проектируем схему хранения данных 56

57 Просмотр френдленты / #5 Избыточность? Каждому пользователю свой список записей в его френдленте? Это же очень много – один триллион записей за год! 57

58 Просмотр френдленты / #5 Храним для каждого пользователя ленту идентификаторов постов! 58

59 Просмотр френдленты / #5 Шардирование? Чего? По какому принципу? 59

60 Просмотр френдленты / #5 Пользователь и его посты лежат рядом Сделайте составной идентификатор поста, пусть в него входит идентификатор пользователя 60

61 Просмотр френдленты / #5 Достали список идентификаторов постов Как собрать ленту? 61

62 Просмотр френдленты / #5 Толстый клиент! 62

63 Просмотр френдленты / #5 Если вы круты, то можете попробовать Параллельные вычисления 63

64 Просмотр френдленты / результаты Пользователи шардируются, рядом с пользователями лежат его посты и его френдлента; В френдленте пользователя уже записаны идентификаторы постов его друзей в порядке, близком к хронологическому; В идентификатор поста зашит ID пользователя, по которому мы быстро определяем шард и забираем с него текст поста; За текстом поста у нас будет ходить JS-машина, работающая на клиенте. 64

65 Запись френдленты / #5 А как посты попадают в френдленту? У нас ведь есть пользователи, которые в друзьях у миллионов? 65

66 Запись френдленты / #5 Используем очереди! 66

67 И ДАЛЕЕ ПО АНАЛОГИИ Алгоритм универсален! 67

68 Вопросы? facebook.com/oleg.bunin