Про построение нагруженных систем
•Download as PPTX, PDF•
4 likes•622 views
Рассказывал в ФизТехе
Про построение нагруженных систем
- 1. Высоконагруженные веб- системы. Коротко о главном. Роман Ивлиев roman@ontico.ru
- 2. 2
- 11. Кеширование 11
- 12. Шардинг 12
- 15. Репликация 15
- 20. АЛГОРИТМ ПРОЕКТИРОВАНИЯ С какой стороны открывать бочку 20
- 23. АЛГОРИТМ, ШАГ ТРЕТИЙ Определить допустимую деградацию функций системы 23
- 24. АЛГОРИТМ, ШАГ ЧЕТВЕРТЫЙ Построим схему движения данных и примем решение, какие из особенностей проектируемой системы мы будем использовать 24
- 25. АЛГОРИТМ, ШАГ ПЯТЫЙ Проектируем схему хранения данных 25
- 26. АЛГОРИТМ, ШАГ ШЕСТОЙ Ломаем систему и смотрим, что у нас получится 26
- 27. Примеры
- 28. ПРОФИЛИ НА САЙТЕ ЗНАКОМСТВ Спроектируем систему хранения пользователей на сайте знакомств 28
- 29. Сайт знакомств, профили / #1 1. Пользователь заполняет анкету; 2. Получает логин пароль для доступа к своему личному кабинету; 3. Пользователи могут смотреть профили друг друга; 29
- 30. Сайт знакомств, профили / #2 1. Пользователей 200 миллионов; 2. Каждая анкета занимает 10 килобайт, то есть всего 2 000 гигабайт; 3. Хитов в день 5 миллиардов; 30
- 31. Сайт знакомств, профили / #3 1. Деградация недопустима; 31
- 32. Сайт знакомств, профили / #4 1. Данные часто читаются, но редко меняются; 2. Все анкеты примерно одного размера; 3. У анкеты есть уникальный идентификатор; 4. Нет ярко выраженных лидеров; 32
- 33. Сайт знакомств, профили / #5 Проектируем схему хранения данных 33
- 34. Сайт знакомств, профили / #5 Репликация? Вообще 140к чтений в секунду 34
- 35. Сайт знакомств, профили / #5 Шардирование? По какому ключу? Диспетчер? 35
- 36. Сайт знакомств, профили / #6 Виртуальные шарды 36
- 37. Сайт знакомств, профили / #6 Сгорает диск? 37
- 38. Сайт знакомств, пользователи / #6 Репликация 38
- 39. Сайт знакомств, профили / результат • Разбиваем весь массив пользователей на виртуальные шарды; • Маппим виртуальные шарды на реальные шарды; • Внутри каждого шарда реплицируем информацию для отказоустойчивости 39
- 40. НОВОСТНОЙ САЙТ Большая и длинная лента новостей крупного СМИ 40
- 41. Новости / #1 • Пользователь читает свежие новости; • Пользователь читает архивные новости; • Редактор публикует новости; 41
- 42. Новости / #2 • Каждая новость примерно 10 килобайт; • Мы вечно храним архив с даты основания СМИ – 2000 год; • В день публикуется около 10 тысяч различных региональных и федеральных новостей; • Итого в год 3 миллиона 500 тысяч новостей, в год 35 гигабайт, за 20 лет – 700 гигабайт; • Это крупнейшее СМИ, посещаемость – 10 миллионов человек в сутки; 42
- 43. Новости / #3 • Деградация недопустима; 43
- 44. Новости / #4 • Количество чтений на несколько порядков превышает количество записей; • 99% запросов касаются последнего дня; • 99,99% запросов касаются последней недели. 44
- 45. Новости / #5 Проектируем схему хранения данных 45
- 46. Новости / #5 Партиционирование По какому принципу? 46
- 47. Новости / #5 Как переносить данные из горячей БД в архив? 47
- 48. Новости / #5 Не надо ничего переносить! Вводим избыточность! 48
- 49. Новости / #5 Очень много запросов к горячим новостям! Что делать? 49
- 51. Новости / результат • Кеширование для горячих новостей; • Партиционирование новостей по дате – последние новости в быстрой таблице; • Избыточное хранение новостей – новость пишется сразу и в горячую таблицу и в архивную, горячая раз в какое-то время чистится; 51
- 52. ПРОСМОТР ФРЕНДЛЕНТЫ Просмотр френдлента в блогах 52
- 53. Просмотр френдленты / #1 • У пользователя может быть сколько угодно друзей; • Френдленту храним бесконечно долго; 53
- 54. Просмотр френдленты / #2 • В среднем у пользователя 100 друзей; • Каждый пользователь в среднем пишет 3 поста в день; • Каждый пост занимаем около 1 килобайта; • Пользователей – 10 миллионов в сутки, но каждый пользователь делает 100 хитов. Итого – миллиард запросов к френдленте в сутки; • В сутки генерируется 30 миллионов постов, 10 миллиардов записей в год; 54
- 55. Просмотр френдленты / #3 • Допустимо, что пользователь увидит запись своего друга не моментально, а с небольшой задержкой; • Допустимо, что порядок записей не будет строго совпадать с хронологическим; 55
- 56. Просмотр френдленты / #4 • 99% запросов приходятся на голову френдленты; • У нас есть пользователи, которые в друзьях у миллионов пользователей; 56
- 57. Просмотр френдленты / #5 Проектируем схему хранения данных 57
- 58. Просмотр френдленты / #5 Избыточность? Каждому пользователю свой список записей в его френдленте? Это же очень много – один триллион записей за год! 58
- 59. Просмотр френдленты / #5 Храним для каждого пользователя ленту идентификаторов постов! 59
- 60. Просмотр френдленты / #5 Шардирование? Чего? По какому принципу? 60
- 61. Просмотр френдленты / #5 Пользователь и его посты лежат рядом Сделайте составной идентификатор поста, пусть в него входит идентификатор пользователя 61
- 62. Просмотр френдленты / #5 Достали список идентификаторов постов Как собрать ленту? 62
- 63. Просмотр френдленты / #5 Толстый клиент! 63
- 64. Просмотр френдленты / #5 Если вы круты, то можете попробовать Параллельные вычисления 64
- 65. Просмотр френдленты / результаты • Пользователи шардируются, рядом с пользователями лежат его посты и его френдлента; • В френдленте пользователя уже записаны идентификаторы постов его друзей в порядке, близком к хронологическому; • В идентификатор поста зашит ID пользователя, по которому мы быстро определяем шард и забираем с него текст поста; • За текстом поста у нас будет ходить JS-машина, работающая на клиенте. 65
- 66. Запись френдленты / #5 А как посты попадают в френдленту? У нас ведь есть пользователи, которые в друзьях у миллионов? 66
- 67. Запись френдленты / #5 Используем очереди! 67
- 68. И ДАЛЕЕ ПО АНАЛОГИИ Алгоритм универсален! 68